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 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. ]]>
