1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Times they are a changin

Well, it was not too long ago, all the security pundits were telling us how bad web services are for security, and some are still saying this right? Of course when someone tells you some technology is "bad" for security, the proper response is always: compared to what? So SOAP is somehow worse for security than DCOM or RMI-IIOP? Remind me all the great security tools that shipped with those protocols again?

Funny, but when all the big vendors and standards bodies have to sit down and work interop, they sometimes get something pretty nice. Rickard Oberg on SAML, XACML (emphasis added):

There are many other crucial technologies today, which are important for integrating webapps into a portal. It is curious to read forums where people bash things like portlets and WSRP and XACML and such. "Why would we want to run portlets in two servers? My Struts app works just fine on one Tomcat instance". Amazing. When you have been exposed to real-life DMZ environments a couple of times you start to wonder how the heck we get anything done *without* stuff like WSRP and security integration specifications like XACML and SAML. The conclusion appears to be that developers that don't get it simply aren't exposed to the realities of actually running the apps. For development it might make no sense to have several servers, or integration technologies like SAML and WSRP, but for real deployments they are essential. As long as application developers are in the dark with regard to these basic realities systems integrators are going to keep using hack upon hack in order to make house-of-cards type integration of apps.

Precisely the point, not only are Web Services not turning out to be "bad" for security, but the standards that they are generating - SAML, XACML, WS-* - are giving developers better security tools than they have ever had before.

March 24, 2006 in Computer Security, Deperimeterization, Identity Services, Risk Management, SAML, Security, Security Architecture, SOA, Software Architecture, SOS, Web Services | Permalink | Comments (0)

REST v SOAP debate impact on security services architecture

Mark O'Neill's RSA Presentation on Security for REST Web Services makes an important point for security architects who are dealing with developing security services for budding SOA initiatives - how will your security services (which rely on WS-* functions and SOAP) be able to deal in a RESTful web services paradigm? This is not a trivial question because while enterprise architects may design and purchase solutions that rely and mandate the former, developers can easily circumvent with a HTTP Get. Part of this gets back to a framework versus roll your own debate that I blogged awhile back.

Security architects cannot afford to take enterprise architect's whiteboard and Visios mandating a WS-* (or any technology) world at face value instead they must engage developers, BAs and other stakeholders to deal with the reality of runtime as opposed to policy and design time. XML in and XML out may be the design, but the runtime reality could well be HTTP Get in and XML Out under REST rendering the shiny new XML security based solution blind to large amounts of traffic.

Maximum flexibility to deal with different tactical deployment realities is an important property in security tools, not just compliance with Visio drawings. The ability to enable security protocols in integration scenarios composed of hetergeneous technologies and usage paradigms yields the widest risk management coverage. In this case it pays for security architects to be the fox not the hedgehog.

This is also why I think STS technology will be very successful, because the security protcols that STS and WS-Trust integrate: SAML, X.509, Kerberos, are generally putting arbitrary boundaries around technical domains while the business reality is the opposite - more integration not less. Protocols which continue to enforce isolation ultimately fail when their subjective, isolated concepts meets up with the integration objectives reality rendering the system as a whole less secure.

March 16, 2006 in Computer Security, Deperimeterization, REST, Risk Management, Security, Security Architecture, SOA, SOAP, Software Architecture, SOS, Web Services | Permalink | Comments (0)

SOA and Security

Gary McGraw, Jeremy Epstein, and Scott Matsumoto have posted their recent article on Software Security and SOA.The paper cuts through a lot of the SOA reality-distortion, and gets to some key points. First, and most important, security should look at SOA and Web Services as an opportunity for security improvement not solely a security problem. Schneier, et. al. had great fun at the onset of Web Services deriding SOAP's claim as a firewall-friendly protocol by saying that it is like saying we invented a "skull-friendly bullet." Good line, but misses the point. I posted this to Cryptogram in 02:

One thing that I have heard you mention before that I disagree with is that Web Services and things like SOAP are bad for security.

First off, any technology will have some security issues and Web Services are no different, but this does not mean that they are "bad," because you have to look at what they are replacing. If I am writing a distributed app today that needs to traverse the firewall or WAN my choices are RMI-IIOP (J2EE or CORBA) or DCOM (Microsoft) or some type of proprietary messaging system.

As you have often said, complexity is the enemy of security...well...Web Services represent a much more simplistic approach to distributed app development. For one thing I can use SOAP in either a J2EE or .Net app, so the security team only needs to understand this one protocol to be useful to either style of development team (for the distributed programming part of the project).

For another thing, Web Services and SOAP are a shift away from code and towards semantic meaning (as Don Box says) and this also aids the understanding of a complex system. Given a good architect, development, and security team, a Web Services-based system has a better chance at being secure in development and production than RMI-IIOP- or DCOM-based apps.

So I would say that Web Services and SOAP are an imperfect yet incremental improvement over the current situation.

Additionally, the payloads in SOA and Web Services are typically XML which you have half a chance at parsing and running detection and integrity checks on. Anybody seen any good IDS tools for RMI-IIOP and DCOM lately?

Back to our friends- McGraw, Epstein, and Matsumoto. The paper lists 13 security snares, the theme of which is that security must roll up their sleeves and work to build security in, e.g. don't wait to get started, don't blithely ascribe all solutions to things like SSL, and don't assume the vendor will do it for you. Timing is important. SOA and Web Services are what is being built right now, this means the lava has not hardened and security cna get involved before it does. I have some specific guidance on security architecture for SOA and Web Services here and here. Security needs to get out of the ivory tower and into the source and data.

The last part of the article describes some keys to security in SOA:

strong security involvement in architecture
or design,
• good software engineering practices,
• security-focused quality assurance
(QA),
• penetration testing,
• automated vulnerability testing,
• manual or automated source code
analysis,
• defect density prediction,
• developers trained in software
security,
• a development methodology,as the touchpoints, that helps identify
security problems before they
occur,1 and
• other third-party reviews.

This is a very good list, but one thing that is missing from the document is the impact of new security standards. One of the things that makes SOA and Web Services exciting from a security standpoint is the emerging security standards that address age-old security problems like interoperability, portability, and data level security. These are a large part of the enhanced security that comes with SOA and should form an important part of the architecture and design part of building security in.

February 22, 2006 in Deperimeterization, Security, Security Architecture, SOA, Software Architecture, SOS, Web Security | Permalink | Comments (0)

Web App Firewalls in (In)SecureMag

Ivan Ristic has the cover story in this issue of (In)Secure magazine, the article details Web Applications and how they are used. Ivan describes four main ways WAFs are used:


  • Audit device
  • Access Control device
  • Architectural/Network design tool
  • Web Application hardening tool

WAFs provide a chokepoint for security controls. BuildSecurityIn has a paper on WAFs as well. The BSI paper illustrates some of the tradeoffs in using a WAF.

January 26, 2006 in Deperimeterization, Risk Management, Security, Security Architecture, Software Architecture, SOS | Permalink | Comments (0)

Web Services and XML Security Training at OWASP Europe (Belgium)

I will be teaching a one day course on Web Services and XML Security at the OWASP Europe conference. I enjoy the OWASP conferences, there is a good mix of security folks, developers, and architects, plus it is vendor neutral, many different industries are represented, and usually in a nice location.

The focus areas of my class are:

  • Web Services attack patterns
  • Common XML attack patterns
  • Data and XML security using WS-Security, SAML, XML Encryption and XML Digital Signature
  • Identity services and federation with SAML and Liberty
  • Hardening Web Services servers
  • Input validation for Web Services
  • Integrating Web Services securely with backend resources and applications using WS-Trust
  • Secure Exception handling in Web Services

The class explores standard secure coding and application security issues and looks at new risks and countermeasures that are present in Web Services, SOA, and XML paradigms.

January 24, 2006 in Deperimeterization, Federation, OWASP, Risk Management, SAML, SDLC, Security, Security Architecture, SOA, Software Architecture, SOS, STS, Web Security, Web Services, XML | Permalink | Comments (0)

Service Oriented Security Architecture

My paper on Service Oriented Security Architecture from the Nov. issue of ISB is now online. The paper describes an approach to dealing security design and architecture issues in developing Web Services and SOA software.

The primary goals are to illustrate a set of key analytical areas, and a way to synthesize these relationships. As Kruchten and others observed separation of concerns is an useful technique in software architecture. In security architecture, it is useful as well, and in addition separation of assets yields a more robust risk management model. In the case of this paper, the assets are separated as Identity, Message, Service, Deployment Environment, and Transaction. This way the risks and countermeasures can be understood and the elements and constraints dealt with in their own domain to the extent possible.

January 19, 2006 in Deperimeterization, Federation, Identity Services, SDLC, Security, Security Architecture, Separation of Assets, SOA, Software Architecture, SOS, Use Cases | Permalink | Comments (0)

Long live the cardboard box

New standards always cause some friction, I have spent my fair share of time debugging XML issues where I was not certain of the value add of XML in that instance, esp. when the system's in question functioned fine in the past without XML. However, I think this misses the point. Peter Weill said at Web 2.0:

XML is like cardboard. It is a very useful packing material because it is malleable and self-describing. Cardboard is itself a large worldwide industry because it is so useful. Often the cardboard used in packaging is heavier than the actual contents of the package. So we should not really be complaining about the “angle brackets” because that’s really not the point.

Structured data is better than unstructured data. I continue to be mystified by the "web services are bad for security" position when I have yet to see application firewalls that deal with unstructured data anywhere near as effectively as XML security gateways and firewalls.

January 05, 2006 in Security, Security Architecture, SOA, Software Architecture, SOS, Web Services, XML | Permalink | Comments (0)

Proportion of Security Applied to "dumb" part of system

Richard Bejtlich blogs

One of the strengths of the Internet has been the fact that it inverted the telecom model, where the network was smart and the end device (the phone) was dumb. The traditional Internet featured a relatively dumb network whose main job was to get traffic from point A to point B. The intelligence was found in those end points. This Internet model simplified troubleshooting and allowed a plethora of protocols to be carried from point A to point B.

With so-called "intelligent networking," points A and B have to be sure that the network will transmit their conversation, and not block, modify, or otherwise interfere with that exchange to the detriment of the end hosts. As a security person I am obviously in favor of efforts to enforce security policies, but I am not in favor of adding another layer of complexity on top of existing infrastructures if it can be avoided.

Now network security mechanisms are great. And networks are a great place to deploy some securiyt mechanisms, because they have the potential for visibility and scalability at a system level. But what about the "smart" part of the system? Shouldn't they have security, too? What is the proportion of your organization's IT security spend on security for the network versus the other areas of the system?  When you focus on securing the network you are improving assurance of your dialtone, but what about payloads, logic, behavior?

It is much more difficult to map security onto the apps, databases, hosts, et. al. in some cases, this is why we have not seen a huge vendor presence in this space, and vendors drive a lot of the security market. But that does not mean we should not do it, after all that is the solution space. Bruce Sterling wrote in Tomorrow Now that our current healthcare and medicine models are obsessed with hygiene, but in reality hygiene is just admitting that we are clueless about microbes, and the immune system -- you know -- the stuff that actually keeps us alive. Hey, I am not against hacking away and using things like network security and hygiene, I even use them both myself, but let's not think that these are the end goals in and of themselves.

December 22, 2005 in Deperimeterization, Identity Services, Risk Management, Security, Security Architecture, Software Architecture, SOS | Permalink | Comments (0)

Assurance Techniques Review

Earlier, I blogged about an excellent paper by Brian Snow of the NSA called "We Need Assurance!" Brian Snow explores several techniques we can use to increase assurance in our systems: operating systems, software modules, hardware features, systems engineering, third party testing, and legal constraints. From a security architecture point of view this breadth is useful since none of these mechanisms alone is sufficient, but together may create a greater level of assurance.

Snow on Operating systems:

Even if operating systems are not truly secure, they can remain at least benign (not actively malicious) if they would simply enforce a digital signature check on every critical module prior to each execution. Years ago, NSA's research organization wrote test code for a UNIX systems that did exactly that. The performance degraded about three percent. This is something that is doable!

Operating systems should be self-protective and enforce (at a minimum) separation, least-privilege, process-isolation, and type enforcement.

They should be aware of and enforce security policies!Policies drive requirements. Recall that Robert Morris, a prior chief scientist for the National Computer Security Center once said: "Systems built without requirements cannot fail; they merely offer surprises - usually unpleasant!"

In the section on Operating Systems, Snow goes onto call them the Black Hole of security. The current state of operating system quality is far from where it needs to be in terms of achieving Snow's pragmatic goal of not achieving security only remaining benign. As with all of the techniques Snow discusses in the paper, we have techniques currently today to improve the situation.Thinking architecturally, with an actively mailicious operating system mediating application, data, and network activity we are building on a "foundation" made of plywood and termites. RBAC systems, digital signatures, MLS systems, and diversification all have potential to improve what we have out there today.

Snow on Software modules:

Software modules should be well documented, written in certified development environments...,and fully stress-tested at their interfaces for boundary-condition behavior, invalid inputs, and proper command in improper sequences.

In addition to the usual quality control concerns, bounds checking and input scrubbing require special attention.
...
A good security design process requires review teams as well as design teams, and no designer should serve on the review team. They cannot be critical enough of their own work.

BuildSecurityIn has many techniques for improving assurance in software. As do books by Gary McGraw, Mike Howard, Ken van Wyk, and others. Source code analysis and binary analysis tools, again, are tools we can work with *today* to ensure our code is not as vulnerable as what is currently in production. Collaboration by security in the separate disciplines of requirements, architecture, design, development, and testing is absolutely critical. The security team should align its participation to how software development is done. In turn, software development teams must build security into their processes. Architects, in particular, bear responsibility here. Architects own the non-functional requirements (of which security is one) and they have a horizontal view of the system, they need to collaborate with security team to generate the appropriate involvement and plaement of security system-wide. The paradigm of blaming the business ("they did not give me enough time to write secure code") or blaming the developer ("gee- why didnt they just write it securely") is a non-starter. Architects need to synthesize concerns in harmony with the risk management decisions from the security team.

Snow on Hardware Features:

Consider the use of smartcards, smart badges, or other critical functions. Although more costly than software, when properly implemented the assurance gain is great. The form factor is not as important as the existence of an isolated processor and address space for assured operations - an "Island of Security" if you will.

I blogged yesterday that smartcards have a ton of promise here. The economics of hardware and advances in software security (like PSTS) are really increasing the practicality of deploying these solutions. Having a VM (jvm or clr), a XML parser, STS, some security mechanisms, and an IP will make smartcards a primary security tool that is cost effective to deploy now and/or in the very near future.

Snow on Software systems engineering:

How do we get high assurance in commercial gear?
a) How can we trust, or
b) If we cannot trust, how can we safely use, security gear of unknown quality?
Note the difference in the two characterizations above: how we phrase the question may be important.

This is a fundamental software architecture question. In a SOA world it is even more relevant because we cannot "trust" the system. The smartcard example from above allows us to gain traction on solutions that can help answer "the safely use" challenge. Security in Use Case Modeling can help to show the actual use of the system and what assurance concerns need to be addressed.

More on Software systems engineering:

Synergy, where the strength of the whole is greater than the sum of the strength of the parts, is highly desirable but not likely. We must avoid at all costs the all-too-common result where the system strength is less than the strength offered by the strongest component, and in some worst cases less than the weakest component present. Security is fragile under composition; in fact, secure composition of components is a major research area today.

Good system security design today is an art, not a science. Nevertheless, there are good practitioners out there that cna do it. For instance, some of your prior distinguished practitioners fit the bill.

This area of "safe use of inadequate" is one of our hardest problems, but an area where I expect some of the greatest payoffs in the future and where I invite you to spend effort.

I have written about Collaboration in Software Development (2, 3) too often system design which is essentially an exercise in tradeoff analysis is attempted to be dealt with by dualistic notions of "secure" and trusted. In many cases the word security creates more harm than good.Specificity of the assurance goals at a granular level from requirements to architecture, design, coding, and testing is a big part of the way forward. Again, we do not need to wait for a magical security tool to do this, we can begin today.

The last two areas discussed are 3rd party testing which reinforces the integrity of separation of duties at design and construction time, and market/legal/regulatory constraints. These groups and forces can be powerful allies in gaining empowerment for architects wishing to create more assurance in their system. One of the challenges for technical people when they deal with these sorts of individuals is an effective translation of geekspeak to something that is understandable by the wider audience. In particular, the ability to quantify risk is a very effective way to show what the impact could be for the enterprise. The Ponemon Institute has some excellent data on this, and more is coming all the time, quantifiable risk data says in black and white business terms what the business needs to deal with.

Last thought, Brian Snow:

It is not adequate to have the techniques; we must use them!

We have our work cut out for us; let's go do it.

December 22, 2005 in Deperimeterization, Identity Services, Risk Management, Security, Security Metrics, SOA, Software Architecture, SOS, STS | Permalink | Comments (1)

Splendid Isolation: Smart Card Security

Was down in Austin yesterday, and got to spend some time with Kapil Sachdeva at AxAlto. Kapil has blogged about his work on PSTS, and how smart cards fit in federated identity. The meeting was good, but the best part was talking with Kapil about where things are going. Like I blogged earlier in The Road to Assurance, Brian Snow points out that one of the vastly underutilized elements for improving our collective security is hardware features. Smart cards have excellent utility as the "Island of security" that Brian advocates for. Like I blogged in another post about Thinking in Layers, many of the smartest people in the last 100 years have come to realize "A problem cannot be properly resolved at the same logical level that it was created." The smart card is so killer because it not only provides a level of indirection (with which we can solve anything, right?), but it also takes us out of the physical stack and all its dependent defense in depth layers. So when we think about increasing the security in a system, sometimes the most cost effective answers are not about cramming more stuff into the box we are trying to protect, but using composition of separate physical elements to achieve our aim. I believe this is part of what Brian Snow is after when he asks the question:

How do we get high assurance in commercial gear?

a) How can we trust or,
b) If we cannot trust, how can we safely use, security gear of unknown quality?

As Bob Blakley says: "Trust is for suckers", and this really needs to guide our design thinking. It is not about blithely assigning "trust" to some network, app, host, or physical element. It is about considering all of the options at all layers (Physical, Identity, Network, Host, App, Data) to compose a system where the controls can collectively achieve higher assurance.

December 21, 2005 in Deperimeterization, Identity Services, Risk Management, Security, Smart Card, SOA, Software Architecture, SOS, STS | Permalink | Comments (0)

»
My Photo

SOS: Service Oriented Security

  • The Curious Case of API Security
  • Getting OWASP Top Ten Right with Dynamic Authorization
  • Top 10 API Security Considerations
  • Mobile AppSec Triathlon
  • Measure Your Margin of Safety
  • Top 10 Security Considerations for Internet of Things
  • Security Checklists
  • Cloud Security: The Federated Identity Factor
  • Dark Reading IAM
  • API Gateway Secuirty
  • Directions in Incident Detection and Response
  • Security > 140
  • Open Group Security Architecture
  • Reference Monitor for the Internet of Things
  • Don't Trust. And Verify.

Archives

  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

More...

Subscribe to this blog's feed