Gaps in the IBM SOA Security Reference Architecture- Part I
Recently,in the context of a client request, I had a chance to look at the IBM SOA Security Reference Architecture, described in this redbook. I found some critical gaps in the reference Architecture. I will highlight these gaps in this and subsequent blogs. The first gap is that the SOA Security Reference Architecture, does not consider supporting an Independent Chain of Command for managing Security Policy. The second gap is that it does not explore the use of right architectural building blocks to enable externalization of Security policies outside of applications, portals, databases, data services, service components and; Business Processes, The third gap is that it does not recommend the right set of tools with which enterprise grade SOA Security, based on the the two principles mentioned above can be implemented. With these gaps in place, demonstrating and maintaining compliance with regulations and laws will be difficult. In this blog, I will describe the concept of Independent Chain of Command in detail, I will describe the other gaps in the next two entries.
Traditionally, IT security has been handled by IT, because of the technical skills required in granting and revoking privileges to enterprise users. Often, the IT staff who are providing application or database level support, are also responsible for administering security. Sometimes, business users are responsible for administering security. Very often, IT staff whose performance assessment and bonus depends on business users they serve, are responsible for enforcing and administering security. Sometimes, the organization is designed so that IT staff report to the same person as the business user, possibly in a dotted line relationship, or in a matrix organization. This creates a clear conflict of interest, and potential for abuse.
I have heard of some small hedge-funds where the IT person administering security is highly motivated to give excellent customer service to hedge fund traders, with a bonus that may be up to 150% of his salary. This is highly desirable from an organizational perspective, except from a security perspective, this scenario is a security breach waiting to happen. This may be an extreme example, but conflicts of interest are common when security is not being handled with an Independent Chain of Command. The best practice there is to implement an "Independent Chain of Command" for security. In this paradigm, the Security Policy Administration, is handled by a group that reports neither to business, nor to IT- but to an independent senior level executive, such as Chief Financial Office, Comptroller or Chief Corporate Counsel. This prevents conflicts of interest from compromising security. This is depicted in the diagram below. The diagram illustrates the Independent Chain of Command best practice, essential for strong security and SOX compliance. Please click on the diagram to see a larger version in a different window.
The key points of this best practice overlooked in IBM SOA Security redbook, are in light blue in the diagram. The highlight of the diagram is: Primary Security Authority is with Security Policy Group. The Security Policy Group can delegate appropriate authority to Business and IT groups. SOA can allow rapid creation of services and composite applications, but these composite applications may be in breach of various organizational policies. In a SOA Security model, therefore, security policies cannot be opaque and embedded deep inside application code, or in obscure stored procedures. Achieving this may seem difficult, but numerous tools, standards and best practices can make this a lot simpler. They will be outlined in subsequent entries.
Comments
Kevin
Thanks for sharing your practical insights. Though focused on SOA dimension, I guess the points you reference on policies and practices also apply to the broader Technology stack too!
I will look forward to continuation of this thread
Posted by: Mohan | August 5, 2008 05:30 AM
Read through your blog and found some interesting observations that raises a few questions..
@"The first gap is that the SOA Security Reference Architecture, does not consider an Independent Chain of Command for managing Security Policy."
First and foremost is the question as to what entails a Reference Architecture (Perhaps a subject for another blog :-))? And secondly should SOA Governance be considered as part of the SOA Security Reference Architecture...
IMO, Security Reference Architecture should not delve into the org. aspects of SOA Governance but should rather focus on the capabilities that enable the Governance like Policy Management, Audit, etc. which the Redbook does address albeit not to the level of detail one would have expected. The notion of "Independent Chain of Command" and other org. aspects of Governance in the security realm is largely dependent upon the business model and the regulatory environment of the industry & geography. Hence it is better dealt with as part of the Business Architecture in the larger EA space.
Again, let me re-emphasise here the level of abstraction I believe we should be dealing with while discussing Security "Reference Architecture" as compared to the solution for IT Security.
Your concluding statement ...
@"In a SOA Security model, therefore, security policies cannot be opaque and embedded deep inside application code, or in obscure stored procedures."
states nicely the importance of NOT having security policies instrumented into the code but rather configured in the security infrastructure thereby externalizing the Management of Security policies to a centralized authority. Having said that, we also need to bear in mind that the enforcement of the security policies would still be distributed across the enterprise in the security infrastructure of applications within the diff. trust domains.
Posted by: Chidambaram | August 6, 2008 08:30 AM
An Independent chain of command for security is a very common architectural requirement. The SOA Security Architecture described in the redbook "does not consider" Independent Chain of Command for Security. Even if the current organizational practice does not require this, it is likely to become a requirement in future. The point is to have the Architectural Building Blocks to support this best practice. In SOA Composite applications cutting across multiple applications, IT silos and organizational units. Security accountability will be lost without the ability to centralize authority and then delegate this authority. More on this in Part II
Posted by: Kevin | August 8, 2008 03:22 PM