Security Architecture is superior to Control Frameworks — here's why

January 2018

Adapting a security control framework is a common response for an organisation when cyber security is a concern. This may be driven by an operational security function, a risk & governance function or a regulatory directive. I presume the readers of this article are familiar with abbreviations such as ISO, NIST, PCI, SANS, CIS, ISF, etc. These are the well-known organisations that published cyber security control frameworks (along with many other good things). They all provide good reference to build and organize security controls in a structure, facilitate maturity and risk assessments, and support gap analysis and remediation works as per a benchmark.

Some run these programs with internal resources, some bring external consultants to transfer the know-how from unbiased eyes. Regardless of the source of workforce, the control framework is the handbook of a security professional as the complex cyber security ecosystem can now be broken into simpler components with a clear taxonomy. This reductionist approach takes one piece of the problem (i.e. the control domain) at a time and isolates external factors so that it could be worked within the domain and results could be obtained quickly. Such an exercise typically reveals gaps for security controls or their effectiveness, usually obtained from qualitative interviews with domain stakeholders and evidence hunted thru information repositories. This is valuable work without doubt as organisations are able to evaluate and plan changes accordingly for remediation and improvement.

The fundamental issue with control frameworks is the challenge to compile and present all control domains together for a holistic view of security. As the metaphor suggests, a chain is only as strong as its weakest link. The teams carrying out control assessments usually lack systems context and make blind queries for existence and effectiveness of controls. As they work on one component (domain) at a time, interactions within and between systems and components will be incomplete. While the need for a holistic view is apparent, building this view relies on the capabilities of the individual team as there is no such model prescribed in any of the control frameworks.

Furthermore, control assessments will need to be repeated regularly due to the dynamic nature of today’s cyber ecosystem where uncertain behaviours emerge over time and any change of a component may lead to unintended consequences in the whole system. The whole exercise will need to start again soon as solution views are not created that could have been accumulated, compiled and consumed in subsequent iterations.

Security Architecture is superior to control assessments in this context as it develops solution views (i.e. architecture descriptions) with a holistic and balanced approach, bringing and presenting disconnected pieces together. Reductionist thinking of control assessments is complemented by systems thinking here as methodological viewpoints are created to manage complexity and reduce uncertainty. Layering and abstraction techniques deliver the right level of detail to stakeholders, and modelling techniques describe and present solution views and blueprints in modular blocks, all organised and managed consistently within a structure.

The organised solution views build the Architecture Repository that can be incrementally developed in subsequent iterations. Architecture descriptions are traceable end-to-end from business requirements to technology components (i.e. vertical consistency). Stakeholders are better aligned and engaged in this hierarchy as each layer presents the right level of detail to the relevant group. The critical success factors here include integrity of security design, consistent decision making, and resolution of conflicting priorities and objectives.

A successful Security Architecture practice will also support compliance directives, risk and governance activities of the organisation as controls can be correlated with the security services of the Architecture Repository.  Control assessments will take less time and effort as credible evidence is constantly available and maintained. Absence of any security control should be discovered easily and architecture designs will integrate control requirements accordingly, ensuring compliance for the next iteration.

For those who want to know how all above is possible in practice, I propose a model for Security Architecture here, with a Reference Model that delivers a taxonomy of concepts and a common vocabulary for security services, and a Content Model that describes abstraction layers in reference to key stakeholder groups (i.e. business, conceptual, service integration), all connected and traceable end-to-end. Organisations may tailor this Reference Model and start building their own Architecture Repository. Benefits should appear in near time and I would love to hear observations and thoughts to make this better.