1 Raindrop

It Was Sposed to Be So Eaaasy

Earlier this year, I gave a talk with on Breaking Web Services with Brian Chess at RSA. We pointed out that adding security into Web services is an exercise left to the implementer, the standards bodies and vendors give you some primitives, but it is still up to you to figure out all of the items on the Web services security checklist should work together in a cohesive system. Needless to say, there are many ways to shoot yourself in the foot.

So during our talk, someone from Oracle stands up and says, "hey, you guys are making this stuff sound hard. Its not hard we support WS-Security..." etc. Again, the whole point of our presentation was *not* that there are not very interesting general purpose security capabilities in Web services, our point was that you need to figure out the architecture yourself, and then bend the tools to your will. Oh, and deliver on time.

So imagine my surprise, when I read this article "Digitally Signing and Verifying Messages in Web Services" which talks about using Oracle's WSM tools to sign Web service messages and verify signatures in Web service messages, but only addresses integrity - absolutely nowt on authenticity! Integrity is important, but there are lots of times when it is not enough. Many times your service needs to be concerned with replay attacks, authentication policies and so on. To deal with those things, we would typically add policies and capabilities for timestamps, nonces and other primitives into the signature block, but the article is silent on those things. (Rad Mark O'Neill's post on this as well)

Its not about _can_ the standards do something or other, I mean given the right resources the standards can put a monkey on the moon, its about what use cases have they engineered in and what is supported in the tools today. I firmly believe SAML has such great adoption across the industry because they have a use case centric view and so gave the vendors something to engineer and optimize for. I think we'll still get there in WS-Security and other areas as well, but the use cases are not built into the spec (as with SAML) and so its taking longer.

One of our points in the talk was - we want you vendors to do your job better and instead of shipping a box Legos, ship a Lego gas station, a Lego airport, and so on. Connect some dots for your customers. 

What I see in training on this topic, is sort of the following - 1) Do I need Web service security? 2) Oh ok, well can I get by with SSL? 3) Oh wait that doesn't actually protect my assets, can I just use WS-Security? 4) Oh wait, WS-Security isn't just a checkbox for security, I need to figure out timestamps, nonces, signatures, encryption policies and so on. And finally 5) How do I accomplish this?

Once we get to step 5 then the real work can begin. Its not easy to get a lot of developers through all of this, and again this is before the real work begins. Even once the lead developers and architects figure this out, there is still the little matter of transitioning it to the rest of the team.

I remember I was working with an enterprise architect several years ago, and he bought a Web service XML gateway like Vordel to add WS-Security support into his Web services apps, but he didn't even buy it as a runtime tool, he bought it as Security API, the runtime enforcement in his opinion was a bonus! He said in effect, well I know I need to do this, but I can't expose all these security primitives directly to my developers.

So yeah, I wish it was easier, but in my experience its not right now. Its not about raw capabilities its about use case realization. I think learning from what has worked well is the way to go. SAML's use case centric approach is one that has.

The Network Firewall is a Consensual Hallucination

James McGovern asks why we don't see enterprisey folks focusing on SOA *and* security? Well there are a lot of reasons here, but lets look at some facts. Most enterprisey folks look at security in binary terms - inside the firewall or outside the firewall. When a transaction is "inside the firewall" they can do silly things like load all their transaction on to something like MQ Series with no authentication, send it to the mainframe which runs their entire book of business, and in essence run their transactional backbone on anonymous ftp. Because its "inside the firewall"

Problem is - its just a Visio drawing, its not reality, its historical baggage. We were trained to think about things in these terms in the 90s

But the business and software worlds have changed a bit from the early 90s, even if security tooling hasn't

If you sent an alien from outer space to observe what an enterprise looks like today, and asked that alien to file an objective report as to the actual connections and message exchanges it wouldn't look like the idyllic, clear separation of good stuff from bad stuff, it would look like this

There is no firewall in any meaningful sense, there are links, federations, communities of interest, business units, integration points, outsourcing arrangements, business processes. In short, there is information and commerce in all its messy vitality. 

Inside the firewall and outside the firewall is not a security architecture, its historical cruft a Victorian, industrial age artifact that snuck into your Visio, not something that protects your businesses' applications and data.

If you want to let the world access your maifnrame, SAP, Siebel, or whatever so they can buy things from you, that is probably a really good idea. But don't assume that RACF or what have you came down on stone tablets from Moses. Just because your transaction is "inside the firewall" doesnt mean that your security model can only focus on resources and objects in isolation. It has to focus on how your business just broke everything apart and then re-connected everything. The subjects are different, the sessions are different, and the transactions are different. Just because the objects and resources are the same and are "inside the firewall" means little when all the context and all the relationships are different.

The world is not firewalled, its federated. Just because its convenient for enterprisey folks to buy into the same hallucination doesn't make it reality.

Next week, I am speaking at Ping's SSO Summit on Web Services SSO basically everything that happens after you press "SUBMIT" on a website. Your data has a journey as dangerous as Frodo Baggins' travels through Mordor. The talk traces the path from the website through the perils that lurk in the enterprise and legacy systems, we will look at ways to get Frodo and Sam home safely and we won't rely on Visio firewalls where Mithril is required.

(Note - Thanks for reminding me of the analogy Jim)

More on Fallacy #4

Steve Jones on Rest and Distributed Computing Fallacies

One of the objections I've had about REST for a while is that it appears to ignore Deutsch's fallacies of network computing

1. The network is reliable.

2. Latency is zero.

3. Bandwidth is infinite.

4. The network is secure.

5. Topology doesn't change.

6. There is one administrator.

7. Transport cost is zero.

8. The network is homogeneous.

Now REST specifies 8, assumes 1, 2 and 3 and takes 4 to mean HTTP/S with Basic Authentication. Now to be clear I've seen people doing Web Services who believe in pretty much all 8 of these fallacies and they create crap systems. But with things like WS-RM and WS-Security at least there are answers to a few elements.

That basic auth is bypassable has been known for some time, thanks to Amit Klein. It would be nice to Restafarians move the conversation towards better security models like SAML and WS-Security. The current state for Rest is both disappointing and weak. The response side is pretty solveable using XML Signature and XML Encryption to sign and encrypt the responses (of course someone will need to tell the "you just leverage the existing infrastructure types" that we'll need to be deploying keys and certs to all the endpoints but at least the primitives are there on the response side), the request side remains problematic.

More on the Fallacies by Arnon Rotem-Gal-Oz, who incidentally if you are interested in building a secure service has an interesting Service Firewall pattern, which I refer to as a TIDE firewall - dealing with Tampering, Information Disclosure, Denial of Service, and Elevation of Privilege threats at the edge. I understand why Arnon left Spoofing off his list, but would like to see him add audit logging to deal with Dispute.

SOA Security Roundtable Webinar

Next Wednesday on February 27 at 12 (Eastern), I am doing a Webinar roundtable hosted by Mike Rothman on SOA Security. Mike listed these topics for the discussion

* New attack vectors introduced by SOA
* The best place to implement SOA Security
* Strategies to build secure SOA applications
* Leverage with existing identity and access management

Should be fun.

**

Web Services Security training, NYC, March 10-11

Security in SOA - It's the Car, Not the Garage

I have an article on SOA Security in the latest issue of Thomas Erl's SOA Magazine. The article is called Security in SOA - It's the Car, Not the Garage, abstract:

Interoperable software architecture requires interoperable security mechanisms. Security is frequently looked at as a black art, but in reality the core concepts of security - knowing your assets and designing for failure - are just good engineering practices. This article focuses on applying those practices to service-oriented solution design with an emphasis on considerations raised by authentication, authorization, auditing, and assurance.

The introduction:

When I park my car in the garage, I lock it. Why? Well, although I would hate for someone to steal my snow shovel and hockey sticks, my car is much more valuable to me. Security is about managing risk, specifically protecting valuable assets like my car. I have a higher level of protection on my car than on my garage. In dollar terms, the contents of my garage are orders of magnitude less valuable than my car. I could spend a lot of money fortifying my garage, and that would add some security to my car while it is parked there, but it is not a cost-effective investment. First, my car is the asset of value, and second the garage - no matter how well protected it is - doesn't move.

Car manufacturers know this, insurance companies know this, consumers know this. Even media publishers know, yet in the common enterprise, programmers and architects seem to roam in ignorance. Your average download of a Michael Bolton song carries a far higher level of security than valuable user data, like passwords, social security numbers, and credit card details. Why do we keep protecting critical data with point-to-point security solutions (like SSL) that protect the transmission channel, but leave the valuable assets being transported wide open everywhere else? This is a critical question that needs to be answered in order to successfully add an effective layer of security to an SOA.

The article looks at security architecture considerations for authentication, authorization, auditing and assurance in SOA.

**

Web Services Security training, NYC, March 10-11

Claims, Assertions, and Roles

James McGovern looks at Cardspace and asks:

It seems as if CardSpace can support claims-based security checks which is a little different than role-based security checks. Are there thoughts from the security community such as Gunnar Peterson on this?

Claims based access control (CBAC...or ABAC assertion based access control if you prefer) definitely differs from RBAC. A classic RBAC model maps subjects to roles to entitlements for certain objects. This sounds a lot easier than it is in practice. Many organizations look at the model and say "hey I know that if you are a DBA then you are in this role and you should get this type of functionality, and if you are a sales person you are the sales role and get only these functions." The problem is that mapping, while not always trivial, is by far the easier. Mapping all the object to entitlements and roles is very difficult in a distributed system.

Basically you have all of the problems that the O/R mapping people have and almost no tool support. As a side note, we know that O/R mapping is the Vietnam of computer science, keep sending troops and resources, but good luck solving the problem. How RBAC is typically practiced in distributed system often quickly devolves into a game distributed impedance mismatch. Roles can still play an important part in the overall access control model, but they are not generally sufficient alone.

Enter CBAC/ABAC.

Instead of end to end mapping subjects and objects across multiple layers, we'd rather focus on the claim (as WS-* would have it) or assertion (as SAML would have it). In this space we are less concerned about the object-entitlement-role hierarchy and more concerned about the token(s) and the policy. The object (data, component, whatever) is still in play obviously and it is protected by a Policy Enforcement Point (PEP). The PEP has the advantage of being able to form fit to what it is protecting. If it is a Java object then it may be an interceptor pattern, if it is J2EE then it may be the container. In true loosely coupled fashion, you create a relationship between the PEP (and its own internal policies, rules, etc.) and the object, but do not have to hard wire the subject -role-entitlement-object together.

The PEP then is responsible for token validation, session validation, associating the object/rule/policy stack with token and the session, and coming to some sort of go/nogo decision (PDP). The PEP may never see a group or role or anything of this nature (these may be used for convenience), and instead enforce the policy on the token and the policies wrt granting access to the object. From a service provider view, the PEP structure looks like this:

Internal to the PEP there are a set of workflow pipelines that fire the policy rules, it should be noted that these are not typically object oriented designs in nature, but can be hidden from the rest of the app in an interceptor pattern. I will exlpore some internal PEP workflows in a future post.

So the net result is that the PEP is form fit to that which it protects *not* to the subject. This in turn allows us to form fit the token to a variety of subjects and request types - CardSpace being a good example, but there are lots of others - smart cards, otp, oath, and so on. Then optimization can occur both on the PEP side and improve usability and strength on the subject's token side. The only thing binding these two (is not binary runtimes) but the request message, which points again, to why message level security is sine qua non going forward in security.

Architectures open up security holes when they cannot use strong authentication to generate tokens, cannot protect the tokens in transit using crypto and signatures, and cannot ensure that the request and tokens are bound together correctly.

Update: Read the thrilling conclusion in Of Claims and Coins (or For a Few Dollars More)

Risk Management and Security in SOA Seminar

I am speaking at a breakfast seminar in Minnesota on April 24, it is part of an Integration seminar series:

Risk Management and Security in SOA
Enterprises are utilizing SOA and Web Services to integrate and decentralize systems as never before. But, classic IT “castle and moat” style security architectures don’t work well in these environments. This session describes a business risk management approach to building security into a SOA strategy. We review architectural approaches, key risk management decisions, personnel, and metrics that allow security services to enable growth and interoperability.

When: Tuesday, April 24, 2007, 7:30AM - 9:00AM
Where: Charter Solutions Headquarters Conference Room A
3033 Campus Drive, Plymouth, MN 55441
763.230.6100

To reserve a seat, please reply to this e-mail with the name, title, company, and phone number of the attendee, or forward to [email protected], or please call 763.230.6100. Seating is limited, so to assure your attendance, please RSVP immediately. A continental breakfast will be provided.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

Practical SOA - Service Firewall pattern

Arnon Rotem-Gal-Oz published a draft chapter from his book on SOA patterns. SOA runs on a network, we know from Joy, Gosling, and Deutsch that the fourth fallacy of distributed computing is "the network is secure". Since distributed apps, whether REST, SOA, Ajax, whatever, cannot assume a secure network, we need some other ways to deal with this.

One of my issues with common practice of enterprise architecture is that they frequently do not deep dive into security issues, instead focusing scalability, detailed software design, and so on. But here is the thing - the security people don't know enough about software design, and the software people don't know enough about security to really help out. Add to this the reality that many security mechanisms cannot make a business case as a one off project, but need to be part of core infrastructure to be economic, and wel, you get the situation we have today. The architects define the "what", and unless security is one of those whats, it is not feasible to make the case for many specialized security services at a project by project level. This is why, enterprise architects that enable increased integration within and across enterprises, must also invest time and resources in revamping security services that enable this to be done in a reliable fashion.

The security architecture needs to be backed by runtime patterns, so it is nice to see SOA security patterns working their way into enterprise architecture work such as Arnon Rotem-Gl-Oz's Practical SOA book. Basically, he uses a TIDE (subset of STRIDE) threat model for the Service Firewall. The Service firewall brokers the request from unauthorized service requesters and protects against some tampering, information disclosure, denial of service, and elevation of privilege threats. Spoofing is not covered, and this should not be an edge service anyhow. Repudiation is not covered, which also should not be an edge service, in my opinion.

We can all argue about the best places to locate these services and the nature of their implementation, but the overall encouraging sign is to see that these patterns become part of how we build the system and not a one off.

Lastly, he is on the right track in noticing that messages travel in a no man's land. And as such, this highlights the importance for a message level security model.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

On the road to delegation - learning from QMail

Kim Cameron has been en fuego recently on one of my favorite topics - how to propagate security tokens in a distributed system? Wrong headed impersonation:

I’m going to make a categorical statement.  No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present.  Ever.

How would this work in Cardspace, Kim continues

CardSpace is built on this principle.  A delegated authority coupon is just a set of claims.  CardSpace facilitates the exchange of any claims you want - including delegation claims.  So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate - as itself - presenting delegation tokens whenever appropriate.

This is, of course, one of the major advantages to WS-Security and WS-Trust approach instead of bundling everything into a single context. Kim also expands on this issue of separation:

CardSpace is built on top of WS-Trust, though it also supports simple HTTP posts.

One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens. 

There are use cases where impersonation, delegation, federation, and other approaches are valid, the question is which framework gives you the best flexibility to handle a wide variety of these use cases? (note - the best overview of apporaches I have seen in open literature is Security Design Patterns)

One of the best areas to look for guidance is widely distributed systems that are in production with a good security track record. Rest people frequently point to SSL, which is fine for point to point confidentiality, but we also know Rest struggles to deal with authentication at all, much less stapling together mutiple claims. So a better example for 2007 is QMail. One of the things that makes QMail's security model more robust is that there is a "clear separation between addresses, files, and programs." In web services I tend to look at this as separating identity, service, message, transactional and deployment concerns. The thing that WS-Security and WS-Trust give you is the ability to build this separation into your apps and messages instead of conflating everything into one token or request. A checkpoint process in QMail should not be dependent on the exact same security model for the request and the content, the security checks  that QMail performs against the address are not subject to the same concerns as the checks against the body. This also reflects a design goal of QMail which separates functions into mutually untrusting programs. In Web services world, we may have a XML Security gateway perform some functions such as auditing, and service authentication, but process confidential data farther on down the line. So Cardspace, WS-Security, and WS-Trust all help to build such an architecture.

SOA, Web Services, and XML Security in NYC

I will be teaching a public one day class in NYC on SOA, Web Services, and XML security. The training date is April 19. The training is focused on identity, message, service, deployment, and transaction security in SOA & Web Services systems. The class is designed for people who are building SOA & Web Services and want to build security into the system from the design and development stages; collaborating with software architects and developers.

As Warren Buffet says "risk comes from not knowing what you are doing", risks in information security frequently result from security not knowing enough about the decisions the software developers take, and from the software developers lacking knowledge about security mechanisms. This class aims to address this issue with practical guidance for SOA, Web services security.

The focus is on the real risks in SOA and Web Services, what security standards and protocols are there to help, how to use them, and finally where you still need to code and configure to address security issues. I also gave versions of this class at OWASP conferences and on-site for a variety of clients across the globe. The content is primarily aimed at security and software practitioners, developers, and architects. Security services are mapped to real risks with actionable patterns you can take to build more secure web services.