Recently I had an opportunity to work on an SOA project—specifically, a security implementation for a large-scale automatic control system. I read as many books on the subject as I could; I studied the matter online, and even sent e-mail messages to former colleagues and friends I had worked with in the past. To my surprise, no roadmap provided the step-by-step process I needed to accomplish my goal of securing a large-scale SOA application.
In the end, I had to create my own. I developed the simple, 10-step process that this article presents.
Moving large-scale, critical infrastructure applications to an SOA is daunting. Securing them is even harder and often requires an entirely new mindset—maybe even an entirely new set of security people. Most security teams have little training in SOA or even in programming. The customary approach from security tsars is to issue encyclicals from afar and hope that the organization complies. So, step 1—and this is often the hardest part—is to make sure that you have the right team.
The team should have a leader who is knowledgeable about both security and software architecture, preferably SOA. Much like an enterprise architect, the security enterprise architect (SEA) will be responsible for creating the overall SOA security model that will serve to integrate all the differing security requirements at every level of granularity. The SEA will serve on the SOA governance board, work with the enterprise architect (EA) to ensure that all SOA implementations are compliant with security requirements, and lead a team of security business analysts (SBAs) and security systems engineers (SSEs) who are responsible for authoring artifacts needed throughout the process. The SEA will also be responsible for working with programmers who have to code security services and security system testers who can put the system through a testing phase before it is deployed.
Step 2. Create a detailed project plan
Step 2, for large SOA systems, requires that upper management understands that it will not be able to retrofit the new SOA into the old security model: Doing so simply will not work. If from the beginning the focus is on traditional security mechanisms (such as firewalls, intrusion-detection systems, and security monitors), this will miss the whole point of an SOA security implementation. You're responsible for making sure that everyone "gets this" by creating detailed project plans and budgets that make clear and reflect exactly what an SOA security implementation entails.
You must communicate that any conversion to an SOA model involves an inherent security paradox: The more SOA your systems are, the less secure they are. The process of converting current systems into an SOA through service-oriented modeling and analysis techniques requires documentation of the business design. Using a formal language that serves to correlate the business design and information systems often reveals just how contradictory, inefficient, and complex non-SOA systems can be. This complexity, however, can hide a multitude of sins and makes it difficult for someone looking to harm an enterprise system to figure it out. After you disentangle these systems and enable SOA, malicious users have a simpler architecture that is easier to compromise.
SOA adherents might disagree, but those responsible for securing systems know that Web-enabled, open systems with centralized points of control are intrinsically less secure and require a more reactive and flexible approach. There is just no way around this, and project planners (who often have a modest set of tasks assigned to SOA security) must remember that SOA security requires detailed project plans and budgets that allow security teams the time necessary to analyze and understand the new challenges that the SOA implementation poses.
Step 3. Maintain an SOA enablement security decision matrix
Formally document the high-level SOA security dynamics by creating an SOA enablement security decision matrix. In this matrix, business stakeholders divide applications into three categories, including those that:
- Will be SOA enabled
- Must interact with SOA-enabled applications
- Will not be SOA enabled and will not have to interact with SOA-enabled applications
Color-coding these separate categories works well. For example, I color items in the first category red, items in the second category orange, and those in the third category yellow.
The security team then further divides the applications into security categories, such as high, medium, and low. For example, applications or services handling market and classified information would be in the highest security category, whereas applications or services that are only accessing publicly available data could be in the lowest.
Table 1 shows an example of an SOA enablement security decision matrix.
Table 1. SOA enablement security decision matrix
| Security (high) | Security (med) | Security (low) | |
|---|---|---|---|
| Red | 36 | 12 | 11 |
| Orange | 12 | 5 | 3 |
| Yellow | 6 | 0 | 6 |
Here, you can see that 12 applications will not be SOA enabled (the yellow applications); therefore, this effort will require a heterogeneous security model—that is, one that will provide security for the SOA-centric portion of the system and one that will provide security for the non-SOA-centric areas. Typically, non-SOA-centric models rely on what is referred to as perimeter-based security, whereby information assets are secured behind layers of firewalls.
For SOA-centric security, begin by creating a risk-management framework as described in step 4.
Step 4. Create a preliminary draft using a risk-management framework approach
Step 4 refers to using a "security from within" approach. Security from within means that security considerations are coincidental to all the activities within an SOA implementation. You must look at how an SOA implementation will work by reviewing design documentation, noting at which point you must make security decisions, and identifying security control points at which these decisions are enforced.
You use mechanisms to apply these security policies and enforce them by assigning responsibility for those policies to applications, SOA security services, and SOA components as needed. You must look to encapsulate or decompose security requirements into a set of security services that will act pervasively throughout the SOA implementation. So, for example, you can assign the task of authenticating users to an Authentication Security Service that all applications have access to and interact with. In contrast, you can configure the enterprise service bus (ESB) to limit access to certain messages on an application-by-application basis. (More details about this in Part 2.)
SOA security services must follow the same set of general SOA principles for loose coupling, modularity, encapsulation, reuse, and composability that will yield the flexibility necessary for ensuring that the information system is able to keep up with the rate of change demanded in the business design and to become a leading driver of change to achieve more overall security for the organization. This requires that you move from traditional, static security models to dynamic models that can keep up with the accelerated rate of change in an SOA architecture.
Besides the security from within approach, you must simultaneously maintain an approach that is risk-management based: From step 3, you will see that some data must be more secure than others, some applications are more open than others, and so on. Therefore, don't treat all messages and applications the same; otherwise, there is an unnecessary security tax levied on the overall system that affects performance and overall system usability. Balancing the security needs with the overall usability of the system must be part of an overall risk-management strategy.
Gary McGraw's very useful book (see Resources) details a five-part process to assist in creating a risk-management framework, or RMF. Essentially, you must:
- Understand the business context.
- Identify the business and technical risks.
- Synthesize and rank the risks.
- Define the risk-mitigation strategy.
- Carry out fixes and validate.
Understanding the business context, for example, reveals that for a vendor bidding system, although each vendor should be able to access its own information, it would not be appropriate for vendors to see each other's data. This data can only be classified within a business context and can't be classified using a simple hierarchical model, as shown in step 3.
Step 5. Define internal and external stakeholders
When you understand these approaches, it's time for step 5. In step 5 the SOA security team identifies and separates the SOA security stakeholders. The stakeholders are divided into two groups: external and internal. External policy makers and governing boards such as the North American Electric Reliability Corporation (NERC) may have specific cybersecurity standards, such as Critical Infrastructure Protection (CIP) requirements, that have broad security implications.
CIP covers areas as diverse as Security Management Controls (CIP-003-1), Electronic Security Perimeter(s) (CIP-005-1), Physical Security of Critical Cyber Assets (CIP-006-1), Systems Security Management (CIP-007-1), Incident Reporting and Response Planning (CIP-008-1), and Recovery Plans for Critical Cyber Assets (CIP-009-1). All these standards generate their own set of specific requirements that affect the overall SOA security implementation.
Furthermore, internal security requirements, often written as Security Standard Operating Procedures (SOPs), answer the who, what, where, when, and how security questions. Who has access to what, when and where, and how and for how long? For many organizations, this information has evolved organically over time and is disorganized and inconsistent; an SOA implementation often requires considerable effort to come up with a systematic document that accurately reflects the organization's security policies.
Step 6. Identify and use the right tools for requirement gathering
In step 6, before you begin gathering requirements, it's critical that you select the right tools that will allow the team to collaborate and easily document the SOA security requirements and create and SOA security model. The right requirements and analysis tools will help the team to understand the problem space, capture and manage evolving requirements, model user interactions, incorporate stakeholder feedback throughout the project life cycle, and—most important—to collaborate.
Good security requirements and analysis practices will significantly reduce system security risk. IBM® Rational® requirements and analysis tools work well for understanding and representing stakeholder needs, leading and coordinating the collection and verification of customer and business needs, documenting and organizing the requirements for a system, and communicating requirements to an entire team. I have used and recommend IBM Rational RequisitePro®, WebSphere® Business Modeler, and Rational Software Architect.
Step 7. Follow an SDLC process for an SOA security implementation
Given the vast amount of information that you must gather, the number of architectural artifacts that must be written, and the specific SOA security services that will be constructed, the SOA security team should follow the standard steps of the Software Development Life Cycle (SDLC):
- Identifying security needs and constraints
- Eliciting and collecting security requirements
- Creating a secure architecture design
- Documenting a detailed secure SOA design
- Implementing the SOA (including SOA governance)
- Testing
- Deployment
- Maintenance
At first, these steps may seem obvious, but security teams rarely go through an SDLC process. They are not accustomed to sitting in rooms with white boards and writing out detailed requirements; designing security high-level designs; and, creating exhaustive test cases that prove that systems are reliably secure. (High-level designs and test cases are covered in Parts 2 and 3 of this series.)
Before the team begins designing solutions, it must gather requirements. For security implementations there are both explicit and implicit requirements. For explicit requirements, a good place to start is to gather the requirements of each stakeholder as listed in step 5. For implicit security requirements, it is helpful to use security frameworks, such as the confidentiality, integrity, and accountability (CIA) triad, whereby you list the specific needs of all security systems. The CIA triad is a widely used information assurance (IA) model that identifies confidentiality, integrity, and availability as the fundamental security characteristics of all information systems.
The team should consider how this SOA implementation will ensure system confidentiality (that is, data privacy), and construct clear process maps that provide details about how messages in transit will be accessed only by the intended and authorized recipients, individuals, processes, or devices. Disclosure to unauthorized entities—for example, malicious users employing unauthorized network sniffing—is a confidentiality violation, and SOA implementations must specify where and when cryptography (that is, the art and science of storing and transmitting confidential data) will be used throughout the system.
Likewise, SOA security models require the integrity or assurance of message non-alteration. SOA security is responsible for ensuring that the information has not been altered in transmission, from origin to reception (data integrity); for providing assurance that the sender of that information is who it is supposed to be (source integrity); and that the recipient is who it is supposed to be (recipient integrity). Data integrity can be compromised when information is corrupted or altered, willfully or accidentally, before its intended recipient reads it. Source integrity is compromised when an agent spoofs its identity and supplies incorrect information to a recipient. Digital signatures and hash algorithms are mechanisms used to provide data integrity.
Moreover, the timely and reliable access to data services for authorized users (availability) is also an SOA security requirement: SOA implementations must ensure that information or resources are available when required, which means that the resources are available at a rate that is fast enough for the wider system to perform its task as intended. It is certainly possible that confidentiality and integrity are protected, but an attacker could still cause resources to be less available than required or not available at all. Particularly when SOA system components such as ESB are responsible for "brokering messages," you must detail high-availability protocols, fully redundant network architectures, and system hardware without any single points of failure in the SOA security requirements documentation to ensure system reliability and robustness. The SOA security team is responsible for exhaustively identifying all these areas and ensuring that appropriate use cases are documented and can illustrate the specific requirements.
Step 8. Find and learn from existing models
After the SOA security requirements team has spent some time hashing out all the requirements, team members will realize that no third-party tools can fulfill all their requirements. They must program SOA security services that will address specific needs. Much better than reinventing the wheel, it's useful to look at some existing models and see what has been developed before the team moves on to the high-level design phase. In this, step 8, I recommend looking at the following model from Intelligrid (see Resources). Here, you can see a list and description of common security utility services that you will probably need to provide in an SOA security implementation. I'll go into greater details about these services in the next article, but I list them here for your convenience:
- Audit Common Service
- Authorization Service for Access Control
- Confidentiality Service
- Credential Conversion Service
- Credential Renewal Service
- Delegation Service
- Firewall Traversal Service
- Identity Establishment Service
- Identity Mapping Service
- Information Integrity Service
- Inter-Domain Security Service
- Non-repudiation Service
- Path Routing and QoS Service
- Security Policy Service
- Policy Exchange Service
- Privacy Service
- Profile Service (User Profile Service)
- Quality of Identity Service
- Security Against Denial of Service (DoS)
- Security Assurance Management Service
- Security Protocol Mapping Service
- Security Service Availability Discovery Service
- Single Sign-on Service
- Trust Establishment Service
You probably won't need all of these services. The SOA security team must go through a process of mapping requirements to each service, then create an SOA security model of all the services they will need to meet all the requirements identified in step 7.
Step 9. Get familiar with the WS-Security standards
When this process is complete, enough information has been gathered to proceed to step 9, which is to review the WS-Security standards and figure out which will apply for your particular SOA security implementation. Figure 1 provides a quick diagram of all the WS-Security standards that you should review.
Figure 1. WS-Security standards
As more detailed models emerge, you must become familiar with the extensive SOA security standards that make up the WS-Security and see how they relate to each other and to the SOA security model requirements. These security standards will be used to construct secure messages throughout an SOA implementation.
Step 10. Develop standards for third-party vendors
Finally, in step 10, the SOA security team is responsible for creating a set of standards and application program interfaces (APIs) for third-party vendors. One of the major selling points of SOA is that systems will be able to leverage their openness by accessing services that third-party vendors supply. Each vendor must be familiar with the SOA implementations security standards and have a clear picture in terms of how its services will interact with the SOA implementation's security services.
Throughout the process, a very detailed security glossary must be maintained to ensure that all the documents produced share the same terms and definitions. I recommend starting with the Oasis Security Services TC Glossary. This glossary should be shared with all vendors to ensure that everyone is on the same page.
In this article, you learned about the 10 steps of creating an SOA security roadmap:
- Pick the right team.
- Create a detailed project plan.
- Maintain an SOA enablement security decision matrix.
- Create a preliminary draft using a "security from within" and risk-management framework approach.
- Define internal and external stakeholders.
- Identify and use the right tools for requirement gathering.
- Follow an SDLC process for an SOA security implementation.
- Find and learn from existing models.
- Familiarize yourself with the WS-Security standards.
- Develop standards for third-party vendors.
If you follow all these steps, you're off to a good start in terms of SOA security.
Stay tuned for more installments in this three-part series, which provides the main items an SOA security team needs for a successful SOA security implementation: a roadmap (Part 1); a high-level design (Part 2); and test cases (Part 3).
Learn
- Find more information about the
Intelligrid model.
- Find more information about the
Oasis
Security Services TC Glossary (PDF).
- Check out Gary McGraw's very useful book,
Software
Security: Building Security In (Addison-Wesley, 2006).
- Wikipedia provides a good overview of
CIP.
- Read the NERC
standards (PDFs):
-
Read more about governance in "A case for SOA governance," and "Avoiding common pitfalls in SOA adoption," both by Tilak Mitra
(developerWorks, Aug 2005 and Jun 2006 respectively)
-
Get "Top ten tips for writing great IT project
proposals" and more in Tilak Mitra's Architecture in practice column (developerWorks, 2007).
-
Learn how to "Obtain approval for your process change
recommendations," by S.E. Slack (developerWorks, Apr 2007).
Get products and technologies
- Download a
trial version of Rational RequisitePro now.
- Download a
trial version of WebSphere Business Modeler now.
- Download a
trial version of Rational Software Architect now.
- Download additional
IBM
product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli®, and WebSphere.
- See whether
Rational RequisitePro
is right for your SOA implementation.
-
Find out why WebSphere
Business Modeler
is a valuable tool for mapping and documenting your business practices.
-
Find out more about Rational
Software Architect, a model-driven software-development tool from IBM.
Discuss
- Check out
developerWorks blogs and
get involved in the
developerWorks
community.
Comments (Undergoing maintenance)
Table of contents
- Step 1. Pick the right team
- Step 2. Create a detailed project plan
- Step 3. Maintain an SOA enablement security decision matrix
- Step 4. Create a preliminary draft using a risk-management framework approach
- Step 5. Define internal and external stakeholders
- Step 6. Identify and use the right tools for requirement gathering
- Step 7. Follow an SDLC process for an SOA security implementation
- Step 8. Find and learn from existing models
- Step 9. Get familiar with the WS-Security standards
- Step 10. Develop standards for third-party vendors
- Summary
- Resources
- About the author
- Comments
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
