Monthly Archives: August 2009

SOA Security Can Be Simple

I wrote earlier in the week about Randy Hefner’s article that characterized the present state of SOA security as “good enough and getting better”. If you design your security architecture well, you can iterate on it and implement more sophisticated security models as you need them. This is something I agree with completely–in fact, this is the guiding principle behind how we build the SecureSpan Gateway product line here at Layer 7. But I’m a vendor; of course I’m going to say that. Instead, let me prove it using some real examples.

Suppose we have a simple warehouse application we want to make available to our field staff. The application resides deep inside our corporate network, and our field staff need to use the public Internet to access it. The good news is that this application publishes a service composed of four simple operations:

Warehouse Service

  • listProduct()
  • getProductDetails()
  • placeOrder()
  • currentOrders()

This will make it easy to build clients that can access it. The bad news is that it has no security protecting it in any way, as it’s been assumed to be in a secure environment.

We’ll use a SecureSpan Gateway in front of the application to be the secure “front door” to these services. The Gateway will provide policy-based security, that can be easily administered by a dedicated security professional–not the developers who wrote the original warehouse app. This is what Randy and Forrester recommend as a best practice. Here’s how it looks:

A simple, edge-of-network deployment of a SecureSpan Gateway as a border guard for internal services.

A simple, edge-of-network deployment of a SecureSpan Gateway as a border guard for internal services.

Scenario #1: Simple SSL

Randy suggested that given the right architecture, you can begin with a simple security model and evolve it. That’s what I’ll do here.  I’ll begin with a very simple, uniform security policy governing access to the service:

Policy #1

  1. Incoming connection must use SSL
  2. Send the request content to the internal warehouse service.

I’ll admit that this isn’t much of a security model–it has no authentication, authorization, or audit. But it does illustrate how you can layer on some simple policy to the internal service: here, by only accepting connections that are using SSL. Thus, we’ve put a constraint on the system that between the external client and the SecureSpan Gateway we must have confidentiality and integrity.

Policies are created in the SecureSpan Manager, which is the administration console for single gateways or clusters (a logical grouping of gateways that shares policies and critical state info and is administered as a whole). The SecureSpan Manager has a useful wizard that allows you to compose basic security policies using only the WSDL description of a service as input. I won’t demonstrate it here, but instead skip to the wizard output, which is an executable policy:

basic SSL reverse proxy

This policy will be executed automatically whenever the Gateway receives a message destined for the warehouse service. It’s composed of just two assertions that implement the policy requirements we listed above. In SecureSpan, assertions are strung together into algorithms that describe how the gateway should process a stream of XML content. SecureSpan ships about 100 standard assertions. These can be used to do everything from authentication, transformation, SLAs, routing to different transports, audit, logical flow control, orchestration, etc. There’s also a pluggable model for building your own custom assertions, which you can use to solve those unusual problems that can’t be overcome with basic components. It’s a lot like the shell scripting philosophy in Unix: give people a kit of basic sharp tools and there’s no limit to what they can build.

Scenario #2: Add Client-side Certificate Authentication and Authorization

Suppose we want to add client authentication to the policy. There are dozens of different authentication modes in the Web services standards, and a number of informal ones we see regularily in the field. We support virtually all of these. In this example, let’s use client-side certificates, and let’s add an authorization component to only permit people in the sales group to access  the warehouse service:

Policy #2:

  1. Incoming connection must use SSL
  2. Client must be challenged for a certificate, and this certificate must be valid, and be issued by an authority we trust
  3. Client must be in the sales group, as defined in the gateway internal identity provider
  4. Send the request content to the internal warehouse service (as before).

Think about what you would have to accomplish to implement this on the application server you host your services on. Now think about getting this consistent across a farm of servers. Finally, consider how you would maintain this consistently across different systems, like Microsoft .NET and WebSphere. It’s a big challenge. In contrast, here’s what it looks like in SecureSpan:

ssl authN

Notice the first assertion now declares that it will challenge the client to authenticate itself using the client-side certificate authentication protocol built into SSL. This is configured by adjusting the assertion details, which are accessible by double-clicking the assertion:

ssl detail

I’ve added a new assertion that adds authorization (or entitlements) by imposing group membership requirements. I simply dragged it in from our palette and dropped it into the policy. Here, I’m leveraging group definitions that were defined using our internal identity provider. This is a localized directory shared across SecureSpan Gateway clusters. Administrators create identities here, define groupings, and issue certificates using the Gateway’s integrated Certificate Authority (CA) capability. These features are convenient because they allows you to work with identity-centric policies without being forced to call out to an external LDAP, Identity and Access Management (IAM) system, or PKI authority. (Of course, if you want to go external, we have connectors into, well, pretty much all of them.) The internal identity provider is very useful for testing or development–and demonstrations like this where we are trying to keep things simple.

Scenario #3: OASIS Web Services Security WS-S Message-based Security

Now let’s make a really radical change to our security model. We’ll move from transport-level, SSL security to a more sophisticated message-based security model. This supports different transports–such as going over a JMS Message-Oriented Middleware (MOM) provider like MQSeries, or transfer of XML content as a file over FTP. It can handle asynchronous, and non point-to-point messaging, which are difficult or impossible to achieve using connection-based SSL.  Here’s the new policy:

Policy #3:

  1. Authenticate identity using the OASIS WS-Security Kerberos Token Profile
  2. Ensure that the message contains valid, digitally signed time stamps. These could be used to add uniqueness in the message as a means to defeat replay attacks (there are various other strategies to achieve this as well).
  3. If the operation requested is placeOrder(), decrypt the order contents elements in the message using the AES-192 cipher, a symmetric key encryption mechanism. Do this in compliance with the OASIS WS-Security standard.
  4. Regardless of the operation, ensure that there is a valid signature spanning the body of the message to ensure that nothing was altered in transit. This also establishes a binding between the content and the identity we validated in step #1.
  5. Client must be in the sales group, as defined in the internal identity provider (as before).
  6. Send the request content to the internal warehouse service (as before).

Our security model is becoming fairly complex, and it’s important to note that it is by no means complete. We haven’t even begun to address how the response from the service should be handled (right now it’s just relayed unaltered from the service); however to keep things simple in the example we’ll confine ourselves to this, knowing that it is incomplete.

Here’s what this policy looks like in the SecureSpan Manager. Note that it’s simple to read and understand, which is important when designing security implementations. Complexity increases the chances of errors going undetected:

wss 1

To write this I simply deleted the SSL assertion and dragged in four new ones. To configure the encryption on a particular element, I opened the detail pane of the encrypt request element assertion:


This pane reflects on the schema bound to the original WSDL that describe the warehouse service. It allows me to just point at the elements I expect to find encrypted (or signed). The gateway takes care of the heavy lifting of XML decryption at run time using our acceleration technology. This panel provides a standard message stereotype to work with, or I can load a sample message to describe an even more realistic scenario.

The time spent converting from SSL-based security model to the much more sophisticated WS-Security policy was all of about 30 seconds. So what we’ve done here is shown how you can start simple, and grow your security model over time with very little effort or risk.

Simple SOA Security

When I was young my Dad was tough on tools. I quite clearly remember him stating “if your tools don’t work for you, get different tools”. This was usually followed by the offending tool being tossed into the garbage because it didn’t serve its intended purpose. A better one–one that solved the problem it was designed for–inevitably showed up soon after. Somehow, this has always stuck with me.

SOA tools need to work just as hard, and if they aren’t useful, they need to face a similar fate. SecureSpan Gateways need to offer flexibility, because the truth is, everyone has different integration challenges in the SOA world. But SecureSpan also needs to be simple enough to resist misconfiguration by virtue of the complexity of SOA security standards (more on this topic in a future post). These are actually two opposing forces, and it’s not trivial to find a useful balance between the two. SecureSpan has achieved that balance. When we do find case where it fails, our judgment is as unequivocal as my Dad’s around the chisels and wrenches in my his toolbox: replace it with something that works for you.


eBizQ Forum Question: What are your questions?

Peter Schooff, who moderates the eBizQ forum, turns the tables on the participants and asks what are the burning questions that they have about SOA? The participants provide a good measurement of the state of SOA in the minds of its thought leaders.

Avoiding the Toll Road into the Cloud

I have a new article I co-wrote with Andrew Finall and Jay Thorne now published on GigaOm. It’s about leased lines to the cloud, an especially timely topic given yesterday’s announcement from Amazon about its Virtual Private Cloud service (more on this in an upcoming post).

Randy Hefner on the State of SOA Security

Randy Hefner wrote an encouraging piece recently in ComputerWorld titled SOA Security: Good Enough and Getting Better. I say encouraging because from his perspective—which is broad and well-informed by virtue of his role as a Forrester analyst—most organizations now understand the importance of SOA security, and they are implementing the basics today. The more advanced pieces, particularly around complex identity-centric use cases such as single sign-on and federation, remain elusive; but at least there is a solid baseline to work from. Randy maintains:

“Thus it is important, even if you start with a simple SOA security solution, to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows.”

This is something I definitely agree with. Security can begin with the basics, as long as you put the time and energy into your basic policy and security architecture upfront. If you design it for growth, you can easily add in support for scenarios like non-repudiation later on. Security should always be an iterative process. It’s something you never finish, and you need to keep this in mind as you are designing your security architecture. You don’t want your tools and infrastructure to let you down at some point in the future.

But Randy’s real gem is here:

“Forrester strongly recommends that you design a solution that does not require application developers to do security-related coding. Even with strong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing future flexibility and enhancement of application security.”

Bravo Randy—and Forrester by extension. This is the critical insight that so many people miss. Here at Layer 7, we’ve been evangelizing for years that developers need to be taken out of the equation when it comes to securing the communications that make up a secure SOA application. SOA security is a complex discipline, and it’s risky to assume that each of your development teams will implement it consistently and correctly. You need to dedicate an expert to the problem and make this person (or persons) responsible for implementing a security model across all of your SOA apps.

The fundamental associated risk with standards like WS-Security (WS-S) is their complexity. This is a very broad specification, one that relies on a host of other specifications as its core. By design, it is not prescriptive about how you should use it; rather, it is a framework for securing SOAP transactions to your business needs.

I was (am still am) an editor of the WS-I Basic Security Profile (BSP), along with colleagues from IBM, from Nortel, and from Microsoft (a number of other companies also contributed to the specification as participants in the working group). I’ve worked alongside the best SOA security minds on the planet, and I learned first hand how easy it is to inadvertently create WS-S (or, for that matter, BSP)-compliant security models that are riddled with holes. OASIS and WS-I, through the standards and profiles they produce, do not have a mandate to offer formulas for securing SOA apps. They are in the business of providing frameworks for experts to implement secure solutions, or to promote interoperability.

This is why it’s so important that security for SOA be placed in the hands of dedicated experts, and that the tools to support an overall governance strategy—such as Layer 7 SecureSpan Gateway line—allow security policies to be enacted simply and comprehensively. I’ve always said that the soul of good security is consistency. Your tools need to support this.

In a forthcoming blog entry, I’ll demonstrate how simple it is to implement SOA security using Layer 7’s SecureSpan Gateways, and thus deliver on Randy’s assertion that we must take application developers out of the SOA security process.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.

SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.

SQL Attack and the Largest Data Breach in US History

CNET’s Elinor Mills wrote an article today about the indictment of three men in the largest US data breach on record. Her article details how three system crackers, two Russians and a man from Florida,  allegedly stole data relating to 130m credit and debit cards and conspired to sell these to others. The story has also been picked up by BBC News.

The hack involved using SQL injection, a technique that was pioneered back in the PowerBuilder client/server days. Many people believe that the attack reached its zenith back then, and is of little real threat today. Clearly, this is not the case.

Indeed, in the services world, SQL injection remains a powerful and often used exploit. Here at Layer 7 we developed technology to defeat this many years ago. We use the acceleration technology in SecureSpan Gateways to scan for SQL attack signatures in messages, blocking transactions that test positive for SQL attacks.

Good security should be simple to apply. If it’s easy to implement, people will use it. Here’s what a policy with SQL injection protection looks like in the SecureSpan Gateway:


It doesn’t get much simpler than this–and that’s the point. Good security must be simple to comprehend, comprehensive, and broadly applicable.

Now, if you click on the SQL attack protection assertion, you can configure for particular attacks. This is important, because databases respond differently to certain signatures:


Can a single programmer write similar protections into his or her code? Absolutely. But do they? Well, Elinor has drawn our attention to the potential cost of not doing so. This kind of security is best applied consistently across all applications.  It’s just not realistic to assume developers will always do this correctly (or at all). Governance of services needs to be done by a dedicated security officer, one who understands the problems, and is disconnected enough from the application development process to be impartial. You separate development and QA for a good reason; sometimes you need to separate development and run time security enforcement for similar reasons.

If more organizations realized there were strong technical solutions like SecureSpan that augment their overall security and governance programs, then maybe we would hear less about massive breaches in privacy and trust like the one above.

The last word from the ever-brilliant xkcd:

Cloud Use Cases

Where does Layer 7 play in the cloud?

Here are the three basic scenarios we see all the time here at Layer 7 with our cloud customers:

1. Governing Access to External Cloud Apps

Problem: Employees can access cloud services with only a credit card and a browser

Solution: Use Layer 7 SecureSpan Gateway clusters to enforce policy and provide a consistent on-ramp to cloud services.

  • Control employee access
  • Maintain authoritative usage records
  • Provide simple on ramp for cloud services (apply cloud-specific security decorations, etc)

Deployment: Physical appliances for extremely high performance (featuring accelerated cryptography, hardware key management (HSM),  and XML processing), software installation on existing server infrastructure, or virtual appliances deployed on commodity hardware. Deploy in clusters for policy synchronization and ease of administration.

Scenario 1

2. Governing Cloud Apps That Need Access to Internal Resources

Problem: Cloud applications (such as need access to internal resources (like directories, legacy data bases, mainframes, etc).

Solution: Use Layer 7 SecureSpan Gateway clusters in the DMZ to ensure than only authorized external services (and identities) are permitted access to mission-critical internal systems.

  • Authentication
  • Fine-grained authorization
  • Identity mapping
  • Threat detection
  • SLA enforcement (for example, throttling access rate to servers)
  • Automated internal failover

Deployment: Deploy SecureSpan Gateways in the DMZ to provide secure, managed access to internal network resources. Use hardware appliances for extremely high performance (featuring accelerated cryptography, hardware key management (HSM),  and XML processing), software installation on existing server infrastructure, or virtual appliances deployed on commodity hardware. Deploy in clusters for policy synchronization and ease of administration.

Scenario 2

3. Cloud Application Security and Monitoring

Problem: How do you protect cloud applications?

Solution: Use Layer 7 SecureSpan Virtual Appliances to secure and manage all communications in or out of cloud applications.

  • Resident in-cloud
  • Automatic policy synchronization between other gateways
  • Rapid re-deployment and mapping of policy dependencies (IP addresses, etc) within cloud provider, or between cloud providers
  • Fine-grained service isolation
    • Secure container model or standalone gateway.

Deployment: Hardened and optimized virtual appliances deployed in the cloud. Appliances can be bound to individual machine images, or share responsibility for multiple image instances. Specific virtualized instances for VMWare or Xen-based clouds, or Amazon EC2.

Scenario 3

Why Choose Layer 7?

  • Experience in Cloud Technology: Layer 7 isn’t just another company jumping on the cloud bandwagon; we’ve been  shipping fully supported, productized virtual appliances (not one-offs, nor proof-of-concepts) for over 2 1/2 years. Since the company’s founding in 2002, we have leveraged virtualization technologies. We draw on years of internal expertise in optimizing virtualized images and hardening base operating systems to create a trustworthy application base. SecureSpan is used as the security basis for countless military and intelligence applications. SecureSpan Gateways form the fundamental security infrastructure for the largest cloud project on the planet, which is run by the department of defense.
  • True Clustering Solution: Management of outgoing communications cannot become a bottleneck or a single point of failure. Layer 7 is the only vendor in this space that has a real clustering solution for scalability, fault tolerance, and ease of administration.
  • Multiple Deployment Options: Hardware appliance, software install, or virtual appliance. Choose what works best for your environment. Mix and match solutions at will.
  • Dynamic Policy Download: Layer 7 SecureSpan Gateways can automatically load policies from trusted downstream gateways or central repositories. We pioneered this use case between branch offices and home office, and it extends identically to the cloud

More on this in a following post, including some actual customer deployment scenarios with SaaS providers like

eBizQ Forum Question: Is SOA Something Small to Medium-Size Businesses Can Work With?

My thoughts are here.