We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Does SOA Increase Security Risks?

Vote 0 Votes

Companies need to be extra vigilant about their security profiles in these difficult times, and the last thing they need is for their SOA solution to increase their security risks. So the question is: does it, and if so, what can you do about it?

13 Replies

| Add a Reply
  • The other day I was exploring the spectacular new renovation of the Art Gallery of Ontario, done by the noted architect Frank Gehry. It’s definitely worth a visit next time you are in Toronto. Question: does Frank Gehry’s very distinctive architecture increase security risk? It certainly courts controversy, but not really security risk. In fact, good architecture—whether building or system—encourages evaluation of all the facets of the environment, security being an important one. Gehry’s team didn’t just think about fir beams, glass, and titanium—they also worked on motion detectors, flow of people, and emergency exits. Similarly, SOA doesn’t create or solve security problems; however, it is certainly the time to evaluate and address these. I always maintain that SOA is actually a security opportunity. Rather than dealing with security as an afterthought, SOA projects recognize that security is a principle goal.

  • Scott makes a terrific case for better architecture leading to better security. People worry about services and data being exposed to the Web. But the vision behind SOA is to provide enterprise-level security mechanisms that supports all apps and services within a domain -- versus the old model of separate security plugs for each and every system and application. Also, probably the greatest security risk in any organization stems from lax management commitment. There need to be guidelines, for example, against sending live production data unencrypted to testing sites or business partners. An SOA framework can facilitate services that mitigate such risks.

  • agree--if you use a mediation layer and prevent any direct binding of services, you have thus removed potentially dozens of possible threats going through dozens of possible ports.

    So by using something like Layer7 or other XML firewall system and forcing service connections through this layer, you dramatically simplify security and therefore unify it. Combined with a policy management system like Centrasite allows you to establish federation security policy that can traverse organizational boundaries and manage provider consumer relationships and service onboarding/lifecycle.

  • I agree with Scott and Joe - a new architecture does certainly create new opportunities. I don't think SOA creates new or greater security risks, just different ones that what have been commonly seen.

    Whichever technique you employ in your security policy, what is key is that you probably need to do things differently than you have been. If you're expecting a little puppy to jump in your lap, and instead you get a snarling Doberman - chances are your reactions are going to be a bit different!

  • Yes. SOA does increase your security risk – at times significantly. The main reason is because SOA relies on a greater number of third parties applications to work. Even if these third parties are trustworthy there still could be situations when they unknowingly exchange or send you malware or other harmful code. Fortunately there are commercial products available to help address these and other related SOA security concerns and it is only prudent that a SOA infrastructure protect itself by deploying these tools.

  • In my opinion, there are 3 main reasons why SOA based systems might be more insecure compared to their non-SOA brethren:

    1. The first reason is what I call "SOA Security Proximate Cause Syndrome". Proximate cause is a legal term that allows one to link the effect of one action as the cause of another action. Although, there is no written rule that states that SOA systems must be distributed, the fact remains that SOA is the preferred architectural style for complex systems and complex systems tend to be distributed. Distributed systems in turn tend to have a higher "surface area". The more surface area of a system, the more vulnerable it becomes. Thus, the distributed nature of SOA systems becomes the proximate cause of their potential higher insecurity.

    2. The second reason is what I call the "SOA Security Paradox". An SOA is by its very nature designed to be highly flexible, extensible, and maintainable. Now, think about the classic principle of security “Security through Obscurity". There in lies the paradox -- a conflict between the inherent goal of SOA and the implication of this goal on security.

    3. The third reason is poor SOA governance. In the absence of strict governance (design and runtime) SOA systems tend to suffer from service proliferation similar to a virus spreading through its host. These unchecked services often open previously unthought-of of security loopholes. As an example, consider a service that is always called by a client on the extranet through an authentication service. A new "rogue" i.e. "ungoverned" service on the intranet calls this same service without the use of the authentication service. Now, consider what happens if this new "rogue" services is called by the extranet client. Oops! Did we just bypass the authentication service? This simplistic example plays out more often than one might think.

    So, is an SOA system inherently insecure? In principle it shouldn't be but our experience in practice has proven otherwise.

  • SOA, as a reference methodology rather than a specific implementation, in and of itself doesn’t increase security risks. However, attention must be paid (up front) when developing any implementation schema to ensure that appropriate security elements are considered. I’ve come in to more than one organization where SOA implementations had gone horribly wrong, and we had to help them “re-start and fix?, but for the most part, effective planning and good governance goes a long way toward mitigating such risks.

  • Yes, there are a number of security issues that have to be tackled when adopting SOA as an architectural style. ObjectSecurity has recently carried out an in-depth SOA security concerns analysis, which surfaced over 30 different security concerns. You can find information at www.secure-soa.info or at www.objectsecurity.com. The two top issues consistently identified by several sources(CyberSecurity KTN, ISSA, SecurityNetwork, US Navy) were 1) gaps in SOA security policy management, and 2) gaps in assurance accreditation for agile SOA. Model-driven security (www.modeldrivensecurity.org) has been advocated as a part-solution. Hope this helps.

  • I think that we should start by defining what we mean by security risk. When it comes to data security, I find that a well architected SOA rather reduces the security risk since it isolates databases and fragments data sources. When it comes to Service Level assurance (which is what I think Samuel Li refers to), there is certainly a greater risk if an application relies on third party services.

    My bottom line, though, is that SOA enables higher security, but as many other IT technologies it is subject to and perhaps amplifies GIGA (garbage in, garbage out…).

  • Okay, I need to break out my soapbox again on classifications of SOA.

    For Enterprise SOA - there are no inherent security risks created through this architectural approach

    For Infrastructure SOA (e.g. IaaS) - the security risks are embedded in the infrastructure offering. For example, if there's a security flaw in your load balancer.

    For Application SOA - there is significant increased security risk. I've witnessed this first hand. Web Services unmask data that has been protected using mature security mechanisms, e.g. RACF, and made too easily available without first implementing a secure means of locking down these services. It's typically an afterthought. Moreover, even if you did think to lay down the security layer first, we're still in the infancy of these mechanisms and they will be tested in the coming years.

  • I'm not sure whether I understand JP here on Enterprise SOA and Application SOA. As most architect address Enterprise SOA as Application SOA not as Infrastructure SOA.

  • I agree with Anthony Gold – SOA a an architectural style does not bring more security risks that technology used to implement SOA had already. The major difference in SOA implementation security is in re-positioning, re-allocation of security risks and related security controls.

    I cannot rely on the ObjectSecurity results because I do not know what they mean by SOA implementation. If it is about Web Services, then, again and again, it does not relate to SOA. If some Mr. Oversimplifier is dummy enough to take an object and exposes its state via XML in the Web Service message, I swear – he has no clue about service orientation and SOA (to JP Morgenthal).

    We have to stop treating security as just IT thing. IT security is the basis for Business Trust – the fundamental element of all business activities; it is the Business issue. SOA does not bring any new technology and, respectfully, no new security concerns that we did not know about. However, we tended to ignore them.

    Just a couple years ago, and even now, several organisations still protect their ‘perimeter’ while it is known for 5-7 years that 75-80% of security beaches are coming from inside the company. I even read about a portrait of typical internal business intruder... When we construction SOA business service, we have to understand that its interface(s) is for communication purpose only, i.e. only communication security concerns play here. All other security concerns relate to the service body (implementation). However, since implementation should be invisible to the consumers, we drop our attention on it while nobody removed our responsibility to the consumer in providing business functionality in the way that would not compromise this consumer in any way.

    The only sin of SOA implementation is that it highlighted security negligence previously hidden in applications. SOA is not about new security risks, it is about the security risks, in clear, in front of your consumers. Certainly, XML firewall can help but a little only (to Miko Matsumura)

  • user-pic

    I am new to this and working on SOA Testing.
    Wondering if SOA suffers security risks at the Application end or the Service Binding end.
    My organisation provides SaaS for its own products. We have a Message Queue hand-shake mechanism between SaaS Client [ Software]and the web-interface [ Service ]

Add a Reply

Recently Commented On

Monthly Archives