How to evolve from a security blueprint towards a security architecture
Axel Buecker 270000KUKR AXELB@US.IBM.COM |
0 Comments | 3,311 Visits
By Stefaan Van daele, Senior Security Architect, CISSP®, IBM and Open Group Certified Architect, IBM Security Solutions.
In my role as Security Architect for the European Region I meet customers from different industries around Europe on a regular base. Most of the people I encounter are responsible for the information security of their organization and, consequently, involved with the definition of the enterprise security strategy and the realization of this strategy. Sometimes people, like my colleague Axel, present me with their "strategies" on a few hand-scribbled notes.
Often, an enterprise security strategy is summarized on a number of slides, and sometimes documented in great detail over more than 50 pages. Independent of the industry, the corresponding regulations to comply with, and the preferred information security best practices or applied standards, all organizations are looking for ways to describe the required security capabilities in a way that it can be understood by the management and the lines of business. This is exactly one of the purposes of the IBM Security Blueprint, which was published the first time about four years ago. It provides a holistic approach to describe the security capabilities and a common taxonomy to facilitate the communication between the different stakeholders.
Once a security strategy has been properly described, the next step needs to look at how to deploy the capabilities that have been selected from the IBM Security Blueprint throughout the organization, how to maintain them, and how to measure their effectiveness over time. Because these tasks are beyond the scope the IBM Security Blueprint we looked for security architecture models we could possibly leverage for this purpose. After a short study, we selected the Open Enterprise Security Architecture (O-ESA) from the Open Group and used it in chapter four of our new IBM Redbooks publication as an approach to evolve from a blueprint to an architecture. Of course, other architecture models can be used as well, but the IBM Security Blueprint and O-ESA are both policy driven, so the alignment between these two models worked out quite well.
Here is one of the first attempts on whiteboard to visualize the alignment:
It is not my intention to explain the complete O-ESA model in this blog, I'd rather refer you to the Open Group publication or our IBM Redbooks publication. Let me focus on one of the cornerstones: the policy driven conceptual architecture. O-ESA extends the policy driven concepts beyond access management to include configuration of other security services. Similar to the XACML model, this conceptual architecture leverages Policy Enforcement Points (PEP) to realize the security controls. It does this not only for access management but also other controls, like encryption, configuration management, or border controls to name a few.
Where the IBM Security Blueprint defines the necessary capabilities as sub-components of the Security Foundation Services, O-ESA provides an architectural approach to define their realization in the IT infrastructure. The picture below shows how the security policies are specified, stored in a repository, and leveraged by the Policy Decision Point PDP for the Threat and Vulnerability Management Foundation Service. Note that the diagram describes a conceptual layer; in the technical realization the PDP might be embedded with the PEP. At the different layers of the IT infrastructure the PEP enforces the policies. For example, the Vulnerability Discovery sub-component can be realized by dedicated PEPs at the different layers: application, database, operating system, and network.
The set of PEPs that are deployed for this purpose are considered the security service, and you have to define the scope of the service, who will maintain this service, and how to report on it. In other words, detailed security operations procedures must be defined for each security service. In our IBM Redbooks publication we provide more details about the required steps because security operations procedures are important to establish and maintain the organization's required security level.
Finally, to make it all come together we have devised a practical example in our book. We leverage the approach described in the O-ESA chapter to develop a security architecture for the usage of mobile devices in a healthcare context. This approach plays out to be very flexible, and it can be leveraged both to develop an enterprise security architecture as well as a specific security architecture for one application. Take some time to study our book and consider where you could leverage the approach in your organization.
Make sure to download this third edition of our IBM Security Framework and IBM Security Blueprint Redbooks publication, which was just published on April 12th, 2013. More than 23,000 people have already done so since 2010.
Feel free to leave a comment if you have ever used the IBM Security Blueprint alone or in combination with any other architecture methods in your enterprise security environment? We are always looking for ways to extend and enhance our current methodology.