As important as information security is, it seems to be one aspect of SOA that is too often overlooked. Without a well-thought out security plan, a SOA project will introduce critical vulnerabilities to the enterprise, it may require a large amount of time and resources in order to “retrofit” security later, and it may never be deployed at all due to accreditation failure when there are unmet needs related to mandatory security rules and privacy laws. On the other hand, an overzealous, over-engineered but short-sighted SOA security plan can be just as damaging as it will introduce tight coupling and performance bottlenecks, making the enterprise architecture brittle and inflexible and bringing the enterprise performance to a crawl. What is needed is both an intelligent and practical SOA security strategy that fits and embraces the data-focused SOA model. This article provides high-level guidance in creating such a strategy, getting your project off on the right foot.
Before we provide this guidance, it is important to understand what not to do – and in this section we will briefly explore anti-patterns that can be avoided by making certain decisions early on. As many well-intentioned organizations begin to transition to a service-oriented methodology or begin new projects, the unfortunate projects fall into three anti-patterns I like to call “Shock and Paralysis”, “Security of the Last Minute”, and “Death by Security”. These anti-patterns are described below:
- The “Shock and Paralysis” Anti-Pattern – In this anti-pattern, the organization finds their security requirements so daunting and the current standards so complex that they see security as a barrier to SOA adoption, and either do not do any security or do not proceed with SOA adoption. It must be said that yes, there are certainly challenges. First of all, it can be easy for anyone to be overwhelmed when looking at an organization’s security and privacy requirements. Combine these requirements with the learning curve of basic information security principles and the plethora of security standards from OASIS and the W3C, and it is enough to make anyone go cross-eyed. But it is important not to fall into this trap of “giving up” – my experience is that planning a security solution for any project is doable.
- The “Security of the Last Minute” Anti-Pattern – As surprising as this may be, this is a common trap that is easy to fall into, where your organization’s security requirements are ignored until the last minute. Unfortunately, this anti-pattern typically produces a funding dilemma – addressing security at the end of a project may require intensive architecture and design change, and it commonly requires a large amount of resources (time and money) to retrofit what should have been planned from the beginning. The result is that organizations may have to double or triple their budget to make these retrofit changes, or the SOA is never deployed due to security concerns.
- The “Death by Security” Anti-Pattern – In this pitfall, the architects over-engineer their security solutions, sometimes providing more cryptography or security network checkpoints than necessary (which affects performance and scalability), or they actually make security a barrier to interoperability by tightly coupling security mechanisms to services and components of the entire enterprise. Even if the security mechanisms implemented are necessary, not planning for performance, scalability, and reliability can doom the project. The results of such an anti-pattern can render your SOA useless, making the security of the enterprise a barrier to usability.
These three anti-patterns have one thing in common – lack of strong security planning from the beginning of the project. Certainly, the first two (“Shock and Paralysis” and “Security of the Last Minute”) result in no plan at the beginning of the project, and the third shows a lack of common sense planning.
An organization’s security requirements demand a well-thought out plan from the beginning that can be accomplished only by understanding foundational principles of information security and an understanding of the nature of SOA. Based on this knowledge, it is important to architect a security strategy for your projects early on. Crucial to the success of deployed systems, a smart SOA security strategy allows business applications to meet the needs of organizations and their business partners by incorporating the classical security goals of authentication, authorization, integrity, confidentiality, non-repudiation, auditing, and availability. In the book Applied SOA: Architecture and Design Strategies that I recently co-authored with Mike Rosen, Boris Lublinsky, and Marc Balcer, we provide a comprehensive guide to SOA Security focusing on the technical security challenges, but we also provide a practical, common sense strategy for the SOA architect, highlighted by four simple planning steps for any project:
- Plan from the Beginning, Focusing on Requirements. Focusing on security from the beginning is essential, and the plan needs to be based on the requirements of the organization(s) involved in the project. This typically means that basic project management planning and requirements analysis is needed in order to determine these security requirements, looking at such factors as security infrastructure with which to integrate, as well as understanding policies for authentication, authorization, confidentiality, integrity, non-repudiation, auditing, and availability. Find out who will be levying security requirements, ask them specific questions, and determine the true requirements together. Once you discover the true requirements of your SOA, you can then begin planning and you can determine the approaches that you will take in order to satisfy your security goals. Finally, once you have developed your security architecture, walk the affected organization through it (before anything is developed), showing how it satisfies their security goals.
- Hire SOA Security Professionals. As I mentioned before in the anti-patterns section, SOA security can be overwhelming because there are learning curves associated with information security, SOA, and current standards and technologies. For this reason, it is important to have professionals on hand who understand both the foundational principles of information security and the current XML and Web Services security standards from OASIS. Using accepted standards is a must for interoperability purposes, but each standard has different options, each with security and performance implications. For this reason, it is crucial to have team members with strong knowledge of SOA and information security. These professionals will develop the security architecture and roadmap for the project at the beginning, based on the security requirements gathered in the requirements analysis process of your project.
- Crawl and Walk Before Running. As we mentioned before, it is often a temptation by overzealous engineers to want to “boil the ocean.” Ignore that temptation, because this could cause your project to spiral into chaos (leading to the “Shock and Paralysis” anti-pattern. Start small, and try to keep it simple, separating out each security requirement from the requirements analysis phase at the beginning of the project. It may be wise to take a phased approach for adding security functionality, using a divide-and-conquer strategy that results in a security roadmap that leads you to achieving all of your security goals by the project delivery date.
- Understand the Impact of Security on Performance. When developing the security architecture for your SOA, remember that security always has an impact on the performance of service consumers and providers in your enterprise. Network calls made to authenticate subjects, retrieve authorization credentials, and obtain policy information have an effect on bandwidth as well as performance. The file I/O and bandwidth associated with auditing to local and remote filesystems will have an impact on system performance. When cryptography is used in secure messaging, there is always an impact on performance, because cryptography uses computationally-expensive operations. What this means is that you should be conscious of your security decisions – only use certain cryptographic mechanisms if they are absolutely necessary to satisfy your security requirements, and think about your use of network calls to achieve your security goals. Many times, for example, a delegated (and not centralized) security model for access control policy enforcement can enhance performance while still adhering to security policy. As you proceed in your project, investigate hardware appliances for XML, cryptographic, and security processing. Explore run-time management and governance solutions for when the project is deployed in order to manage and meet run-time expectations for performance and availability.
Certainly, this article only scrapes the surface of SOA security planning, but the steps I have provided are practical, common sense steps that can help you avoid the common anti-patterns that I have seen in so many SOA projects. More in-depth coverage of this and other SOA topics can be found in the book Applied SOA: Architecture and Design Strategies.
