It sounds almost trite, but the only practical approach to developing a security architecture for an organisation is to start at the most abstract level and consider what the business drivers and requirements are. This is fundamental to any approach for developing an organisation-wide strategy.
If you don’t know what the business drivers and requirements are for something then how are you ever going to deliver a solution that meets its needs to the required standard and at a cost that is appropriate? In the context of security, it comes down to understanding what needs to be protected and why. However, it may not always be obvious.
For many businesses it is their reputation that is the most critical asset for them to protect. Without their reputation, they will lose their existing customers and won’t attract new ones, at which point it doesn’t matter whether they have the most wonderful technological solutions in place or something really basic.
Financial considerations typically feature fairly high on the list too – PCI compliance is a fact of life for many companies and if not properly addressed can result in large fines if their customer’s cardholder data is compromised. However PCI compliance does not mean that all a businesses security requirements have been addressed. While its strong focus on securing card data may provide adequate protection for other assets, it does not ensure that all relevant assets are protected to a level commensurate with their value.
For others what is important is agility – how easy is it to integrate new businesses they acquire (without compromising the security of the existing or the new business), or remove ones they divest.
I have had conversations a number of times with people who can’t, or are not willing to, understand that an Enterprise Architecture cannot be fully developed without considering the businesses drivers and requirements for security. There appears to be a feeling that although an Enterprise Architecture is fundamental to medium to large sized organisations and needs to be addressed in order to provide a consistent and supportable framework for new application development projects, security can be tackled at a project level. “We have our network and firewall – we’ll just plug into it like the others systems do.”
The SABSA framework provides a structured approach that considers all aspects of the business in the same way as the Zachman, TOGAF or other similar frameworks approach Enterprise Architecture. Because it is closely aligned with Enterprise Architecture approaches, SABSA works well beside them. The ability to trace requirements through to deployed solution and from deployed technology back to business requirements is fundamental to ensuring that actual security requirements are delivered and that nothing is delivered that doesn’t have documented requirement. This provides a framework against which the performance of business security solutions can be measured and evaluated in terms of a return on investment proposition. It also ensures a consistent approach to security, managing the risk landscape while avoiding reinventing the wheel for each new initiative that comes along.