TOGAF Integration with SABSA Layers
powers-old-account 270000NC1K Visits (2836)
The Open Group recently published a white paper describing the integration between The Open Group Architecture Framework (TOGAF) and the Sherwood Applied Business Security Architecture (SABSA). Both of these standards are large, mature, standards for their domains and it’s no small challenge to bring these two together. While the Open Group has fostered several security standards in the past, it doesn’t seem to me that it has ever taken the comprehensive look at security architecture to the same degree that SABSA has. So the announcement of the integration paper is a huge step forward for both TOGAF and SABSA.
SABSA model divides security concerns into 6 layers:
The SABSA model codifies something that is easy to say and difficult to do for security architects. It provides a method for documenting the actual information security risks that exist in the business that occur due to the nature of the business and its operations. And every aspect of security, down to every ACL on every file permission must ultimately be derived from those documented business risks.
The huge benefit of this approach is that it gets security architects out of the mode of wanting to include every security control they’ve ever heard of or read about in the business’ IT environment. While a good security practitioner will alwys be thinking “outside the box” looking for potential security vulnerabilities, they can quickly get unrealistic. Sometimes security experts will focus on highly theoretical inter-process cross memory attacks while not noticing that the process for granting access to the data “through the front door” of the application is so lax that employees who have been off the payroll for three months can still log in. The SABSA approach, starting from the business level, helps keep the security activities justified and rationalized.
The danger I see in models like SABSA is that they are described as a method that starts from the business level discussion and proceeds toward more and more levels of detailed refinement. It is essentially a “top down” approach, at least on paper. On paper it makes sense. But there’s an implicit assumption that the business level discussion can capture all the risks in enough detail that all the necessary security controls can be identified. I don’t know any experienced security practitioner that can agree with that assumption. A very large percentage (30% or so) of security vulnerabilities exist because of poor patch management and poor change control processes. So it’s the operational aspects of the business that introduce a lot of the security issues, not the nature of the business domain.
These issues can only be “discovered” and documented at the lower layers of the model and need to be reflected back up into the upper layers of the models. For example, the nature of the business may depend on a highly mobile sales force which relies on having an advantage in quick delivery times after a sale. Therefore it’s a hard requirement that the sales team be able to enter orders from mobile devices, probably their phones. That’s a perfectly reasonable requirement. And taking the top down approach it’s easy to identify a security requirement to protect any data stored on the phone. But it’s not so easy, from a top down perspective, to identify the dangers of using open wifi access points by the sales team. Until the sales force actually start using their phones in real world environments, you’re not likely to see these kinds of dangers.
It’s the combination of the security practitioners’ experience, knowledge of common infrastructure vulnerabilities, and the understanding of the business domain that keeps the security architecture on track, efficient, and aligned with business. The SBSA model takes a very reasonable approach by separating security discussion into the layers it does. We just need to remember that the lower layer discussions affect the upper layers just as much as the upper layers drive the lower layers.