sapienti sat: Making SOA Ready for the Enterprise

This will be the last [at least for a while] post in the SOA Security Series, and I want to conclude by sharing my vision and some recommendations and best practices (most of them fairly common sense) that I have noticed, stole and otherwise accumulated while working in this field. But before we start, I would like to fill the gap that I left in my earlier postings by never providing a

Definition of Secure SOA

Secure SOA is an approach to implement SOA which by design ensures trust throughout the SOA ecosystem (including services, consumers, composite applications and infrastructure) by addressing some or all of the following security aspects:

• Authentication
• Authorization
• Integrity
• Confidentiality
• Accountability (monitoring, logging, audit, non-repudiation)
• Identity (federation, provisioning, trust brokering)
• Security Policies

It is also worth mentioning that I firmly believe that Secure SOA is best viewed as a specific case of Governed SOA.

Common SOA Security Requirements

I have a dream that all SOA Security platforms, implementations and mechanisms will be:

• Agile – able to change at business speeds
• Policy-driven – giving all stakeholders freedom to change their mind
• Not client- or service-bound – applicable outside the individual domains of control
• Usage- and context-sensitive – allowing service providers and their agents the freedom to have different security for different circumstances
• Granularly applicable – not forcing the adopters to deal with the all-or-nothing dilemma
• Brownfield-friendly – can be retrofitted into existing environments without requiring heroic efforts or causing unnecessary disruptions
• Centrally controlled
• Ubiquitous – not limited to a single technology, platform, protocol, transport or product
• Extendable – affording everyone the freedom to add
  • new mechanisms
  • new Aspects (censorship, throttling, privacy)
  • new providers
  • new kinds of relationships (federations, aggregations, delegation, trust, etc.)
  • support of new standards and specifications
  • defense against new threats
  • ... and utilize new capabilities (HSM, accelerators)

Recommendations for Building Secure SOA

• Enterprise-grade SOA Security can not be bought – it has to be architected, implemented and maintained. Do not confuse Software Security with Security Software.
• Do not address SOA Security in isolation as a point solution, but try to address it as one of the aspects of a comprehensive governance solution in conjunction with QoS, versioning, lease and other governance aspects.
• Avoid redundancy and duplication – look for a solution that can delegate governance functionality to your existing infrastructure and governance solutions (e.g. security and identity packages).
• Do not look for easy fixes (like applying security at the perimeter or relying on transport layer security) and magic bullet solutions – real security takes work.
• SOA ≠ Web Services so do not settle for a solution which artificially limits the scope of security and governance to that technology.
• To ensure wide adoption of SOA across your enterprise, do not make service consumers and producers bear most of the compliance burden – your solution should be able to take care of most things.
• Do not let your security solution undo the main benefit of SOA by re-coupling service consumers and producers to each other, policies, etc.
• Vendors are involved in an arms race of standard compliance. Do not be fooled by a lengthy checklist of supported standards – it does not guarantee better interoperability or security. And standards will change. Look for a solution which gives you freedom to choose which standards to support and when to support them – seek a solution which gives you freedom to change your mind!
• Do not delay implementing security until “phase 2”
• Beware of those (clients, colleagues, partners, etc.) who believe they are secure
• Do not assume it is someone else's job
• Do not forget that SOA Security is still a kind of security, so all the regular principles apply:
  • Defense in depth
  • Threat analysis
  • Assumption vulnerabilities
  • Weakest point
  • All traditional threats still exist
• And never forget that common sense!

Please bookmark with social media, your votes are noticed and appreciated:

This is the second installment of yesterday’s post introducing a Formal SOA Security Model. Let’s drill further down into each of the dimensions of the model.

Security Aspects

Authentication

Authentication is the cornerstone of every security model and implementation. In most cases it involves establishing principal’s identity with a specified level of confidence. From security point of view, principal is any entity, such as human, process, component or external system, which is requesting access to secured resources. Identity by definition is unique, as in Highlander: there can be only one! However sometimes it is not necessary to narrow down the set of possible principles to a single one and it might be enough to narrow it down to a certain class, such as Platinum Members or Employees.

Authorization

Authorization usually happens after and in the context of authentication. It involves determining, by evaluating applicable access control information, whether a subject is allowed to have the specified types of access to a particular resource. Once a subject is authenticated, it may be authorized to perform different types of access.

Integrity

Integrity is the property that data has not been modified. In the context of a single message it means that the content is exactly the same as was sent by the originator, this is typically achived through digital signatures. In the context of message exchange it also means that all the messages were received exactly once in the same order as they were sent, which would require a assurances of relible messaging in addition to signatures.

Confidentiality

Confidentiality is the property that data is not made available to unauthorized individuals, entities, or processes. Typically confidentiality is achieved through encryption, however there are other options including steganography and winnowing.

Accountability

Accountability is the ability to associate historical actions and events with principals. It is the only aspect that happens after the event took place. Various applications requre different degrees of accountability including: simple recording of events that can be used for billing or data mining, auditing that would allow to prove that certain events took place to an internal party, and nonrepudiation when a transaction and its origin can be proven to an independent third party.

Identity Management

Identity Management deals with provisioning, reconciliation and federation of principal’s identities and security attributes across multiple security domains. It is also closely related with trust.

Security Policies

In this context a Policy is a set of externalized business rules that govern behavior of a computer system. Policies can define all other security aspects and can be attached to all SOA participants, including clients, services, and infrastructure. Policies are used to describe a broad range of service requirements and capabilities.

Security Facets

Transport Security

Transport-level security addresses protection of information while in transit between two interacting parties. It is the easiest to achieve: the industry has a set of existing and widely accepted transport-layer security mechanisms, such as SSL (Secure Sockets Layer), TLS (Transport Layer Security).

Message Security

Message-level security addresses protection of individual requests as they are routed between service consumers, intermediaries, and providers. Message-level security for SOAP based communication is defined in the emerging WS-Security standard.

Application Security

Application-level security includes all security mechanisms that are coupled directly with the application logic. It is the most versatile security facet that is needed to handle application-specific security constraints, such as “a director can approve purchase orders up to $50,000 and higher amounts require a VP approval.”
A key difference between application security versus transport and message level security is that the latter can be provided by the infrastructure transparently to the application, while the former has to be coded into it. However infrastructure can provide means, such as easy access to the security context and policies, to facilitate implementation of application-level security.

Asset (Data) Security

Asset-level security refers to protecting any assets used by and encapsulated in the service. The most common asset that requires protection is application data, but other types of assets such as devices and capabilities should also be taken into consideration when building a comprehensive security solution.

Knowledge Security

Knowledge security refers to protecting information describing your services, applications and other sensitive assets. The types of information that require protection include: service WSDLs and schemas, end points, binding and protocol specifications, service descriptions and taxonomies, policy repositories, etc.

Control Security

Control security includes all security mechanisms that are in place to protect the governance solution itself. These include protection against tampering with the governance data, bypassing workflows, attacks on the governance infrastructure and exploitation of service management capabilities.

Support Levels

	Provides: solution provides this functionality, transparently or with minimal support from service consumers and providers.
	Supports: solution facilitates the implementation of this functionality by service consumers and providers.
	Allows: solution does not prevent or hinder the implementation of this functionality by service consumers and providers.
	Does not address: this functionality is outside of the scope of the solution.

Another example

And this is how the model describes the capabilities of SGF delegating security enforcement to Sun Access Manager.

Why formal Model?

The best way to capture SOA Security requirements, define and compare alternative architectural solutions and security capabilities of the existing products and in general talk about SOA Security is in the context of a comprehensive formal model. I could not find anything of like this as I was preparing for a SOA Security talk at the last year’s Horizons conference so I decided to come up with one.

Only after I have defined mine, I stumbled across a somewhat similar approach that was adopted by the NSTISSC which stands for National Security Telecommunications and Information Systems Security Committee – something that has the word “Security” twice in its name has got to be a serious joint. Actually as it turned out when I was checking the links for this post, it has been since renamed to something less conspicuous: Committee on National Security Systems (CNSS).

However if you bother to compare the two you would kind some key differences:

1. My model is specifically designed to address the SOA Security domain.
2. My model has many additional dimensions. 
3. My model uses graphical notation to facilitate analysis and comparison.

Description

This is a three-dimensional model which represents the SOA security domain as a matrix of seven Security Aspects (or different manifestations of system security):

• Authentication
• Authorization
• Integrity
• Confidentiality
• Accountability
• Identity Management
• Security Policies

versus six Security Facets (or application layers where security can be implemented)

• Transport Security 
• Message Security 
• Application Security 
• Asset (Data) Security
• Knowledge Security 
• Control Security

The third dimension represents a Capability (or Support Level provided by a solution to a particular combination of a Facet and an Aspect). The model uses an intuitive graphical notation that facilitates human compression and comparison of different models. I plan to describe Aspects, Facets and Capabilities in-depth in a separate posting, but to give you the look and feel for the end product I provided the model for an ad-hoc SOA running in a typical application server:

Please bookmark with social media, your votes are noticed and appreciated:

Part of the solution or the problem? Probably both…

In my last post I mentioned standards as one of the challenges faced by those trying to build secure SOAs. Don’t get me wrong – I am not against standards as such, they can be very useful and often provide a keystone for interoperability. They also sometimes bring elements of democracy into the industry which is traditionally gravitates towards oligarchy. However in the case of SOA the situation with standards seems to be really bad: there are at the same time too many and too few standards. There are competing standards, some of which were introduced purely for political purposes. There are things which look like standards, but are in fact private specifications backed by one or two companies. There are standards which have no adoption and are unlikely to ever get any because they have not had any activity for three or more years. The same is true for SOA Security standards, yet unfortunately platform vendors have been engaged in a kind of arms race around standards compliance – the longer the list the better [presumably] is the product. Wrong! Standards are important, however, it is imperative to understand that by itself compliance to security standards guarantees neither interoperability nor security. Let me give a simple example.

Once there was a platform vendor in the SOA space, who only supported proprietary or very rudimentary (HTTP Basic, SSL) security mechanisms. They decided that this is not good, and in the next release introduced support of a number of standards including WS-Security, SAML, etc. The resulting solution worked like this: when a service was configured to require security, the platform upon receiving a SOAP message performed the following actions:

1. Look for WS-Security header – check
2. Verify that the header is well formed – check
3. Look for SAML token in it – check
4. Verify that the token is well formed – check
5. Determine the issuing authority – check
6. Present the token to the authority and ask if it is legitimate – check
7. Proceed with the processing of the request.

For those not intimately familiar with how SOA Security works this is basically the right way to implement these standards, however they missed the federation/trust establishment steps that are covered in other standards. As a result anyone willing to compromise such security had to create themselves an identity provider (Sun’s own Access Manager will be a great choice, and I think it is even available for download), issue themselves a token and use it to hack away at the protected services. Needles to say that this resulted in lowered, not increased security compared to old-style HTTP Basic over SSL so in the next maintenance (..1) release the feature quietly disappeared. As far as the interoperability goes, when I am talking about SOA Security I like to ask the audience a question:
Imagine that there were two technical teams of the highest caliber, located at the opposite ends of the world. Both teams read the entire WS-Security specs with all the profiles and supporting documents, understood and implemented them in their entirety and 100% bug-free. And then they tried to interoperate without ever talking to each other [which is exactly the original vision behind SOA that made it so popular in the first place] – and you have to bet on the outcome. What odds would you give them of actually interoperating successfully?
Usually the more person knows about the subject, the longer odd they would give – my current guess is around 15%.

The point I was trying to make is that Standards checklists do not provide a sufficient basis for comparison for products or solutions and are poor predictors of how secure, interoperable and future-proof they would end up being.

Instead of a conclusion, have a look at the laundry list of SOA Security standards compiled by a leading industry analyst and their take on their degree of maturity:

SOA Security Specifications

• WS-Security: SOAP Message Security 1.1
• WS-Security: SAML Token Profile 1.1
• WS-Security: X.509 Token Profile 1.1
• WS-Security: Username Token Profile 1.1
• WS-I Basic Security Profile 1.0
• WS-I Basic Security - SAML Token Profile
• WS-I Basic Security - X.509 Cert Token Profile
• WS-I Basic Security - Username Token Profile
• SAML 1.1
• XML Encryption
• XML Signature
• WS-I Basic Security - Kerberos Token Profile
• WS-Security: Kerberos Token Profile 1.1
• WS-Security: SOAP with Attachments Profile 1.1
• SAML 2.0
• WS Federation
• WS-I Reliable Secure Profile
• WS-SecureExchange
  • WS-Trust 1.3
  • WS-SecurityPolicy 1.2
  • WS-SecureConversation 1.3
• XACML 1.1
• XACML 2.0
• WS-I Basic Security - REL Token Profile
• WS-Security: REL Token Profile 1.1
• SPML 2 (Service Provisioning Markup Language)

Key: proven, ready, contender, risky.

And if you think the list is too long, they have omitted almost a dozen:

• WS-Privacy
• WS-Policy
• WS-Policy Attachment
• WS-Reliable Messaging
• WS-Authorization
• XKMS
• X-KISS
• X-KRSS
• WS-Policy Assertions

Isn’t life interesting?

Please bookmark with social media, your votes are noticed and appreciated:

The top 10 in no particular order.

Nowadays SOA Security is the most asked about aspect of SOA, and is becoming the decisive factor in selection of SOA platforms and strategy. It is important. How important? According to Forrester at the end of 2006 86% of SOA infrastructure vendors have firm commitments to support SOA Security and more then 50% of the SOA users are actively looking to implement it. Less then 4% of the users have made a decision not to implement SOA Security [I wonder what their reasons might be]. More importantly, it will be the determining factor in success or failure of SOA implementations undertaken today. Another anecdotal evidence why the time to talk SOA Security is now comes from the meme trend analysis:

As you can see the S-Curve has clearly taken of in the last 10 months yet the inflection point has not been reached. The next picture illustrates a brief idea behind this fascinating analysis tool, and I highly recommend to check out more:

Ok, now we are hopefully in agreement that SOA Security is important, but it is also difficult [to do right that is]. And here are top ten reasons why:

1. SOA relies on ubiquitous unsecured technologies. No more [false] comfort in security through obscurity.
2. SOA Security implementations have to reconcile and interoperate between multiple security models and mechanisms in real time. And there is never a perfect match between them. And where there is some mismatch between interoperating entities, cracks tend to open. And we all know what can get into cracks…
3. SOA opens new vulnerabilities by breaking up and exposing formerly monolithic and hidden applications. The more integration points (some people call them reuse opportunities) your applications have, the more attack surface they present.
4. SOA heavily relies on advertising services, formats and access points. In the past businesses tried to hide those things, lest someone figures vulnerability they have missed. Now you have to publish them and open to external parties or even the entire world.
5. The ROI fallacy: it is likely that the most important business functions will be SOA-fied first, when some of the technologies that you will use are still young and your experience with them is minimal. The rational way is to do things in reverse and start with the least important capabilities, but we all know the power of the dreaded ROI.
6. SOA supports service composition, orchestrations, etc. and, most importantly, facilitates automation of business processes, hence removing existing human oversight and controls. And (at least for now) only humans have the ability to notice things that they were not expecting to see. Just remember what happened with the Barings Bank back in 1995.
7. SOA expands the ranks (e.g. business partners) and kinds (humans, systems, processes) of service consumers, so the security mechanisms have to cope with a menagerie of principals, while being able to tie back every action to a specific human being (because they do not send computers to prison – at least not yet).
8. SOA breaks the traditional notion of a single easily identifiable consumer: once you start composing and orchestrating services and processes it is at time very hard to figure out whom to authenticate and authorize – the immediate requestor, the ultimate one or perhaps both of them. For example: a client calls a bank employee and asks to wire money to a numbered offshore account – the client is responsible. The same client calls a stock broker and instructs to take a risky short position on an exchange, the broker is responsible before the exchange and has to settle with the client separately. A doctor asks an assistant to access confidential patient information – both need to be cleared to do that. And there can be more then two parties…
9. By enabling flexibility, SOA accelerates changes of everything, including: business, IT, technologies, processes, participants, and even change itself. And these changes will be opening new vulnerabilities which were not there even a short time ago.
10. SOA replaces compartmentalized security, with a uniform one thus creating a high value target. In the days of siloed applications one needed to compromise a lot of systems in order to be able to achieve anything of value and cover their tracks. Now if they can get around the SOA Security mechanisms you put in place – they are in!
11. Standards, but that is a subject for a whole separate discussion.

Please bookmark with social media, your votes are noticed and appreciated: