The Utility of Security Control Frameworks
I have been thinking about the utility of control frameworks.
Security control frameworks (SCF) have become a key tool in a security consultant's arsenal. Typically a SCF consists of standards, guidelines, and best practices to manage cybersecurity-related risk. SCFs present a prioritized, flexible, and cost-effective approach to promoting the protection and resilience of information assets. Consequently, they have been largely adopted by the security industry, providing a key benchmark for 'what good looks like', facilitating maturity and risk assessments, and supporting gap analysis and remediation activities.
CSFs allow a complex cyber ecosystem to be broken down into more easily digestible chunks complete with a clear taxonomy. This reductionist approach is useful: it allows security professionals to quickly assess risk based on missing or weak controls, allowing organisations to identify areas for remediation and improvement, and to inform future security improvement plans and activities.
However, there is a fundamental issue with SCFs and how they are used by many organisations. The issue is that - unsurprisingly - SCF are control-focused. These controls are largely considered in isolation and seen as a checklist of general controls to have in place so that an organisation can demonstrate compliance. This approach is troubling as compliance is not synonymous with security:
- It does not reduce the cyber risk faced by the organisation, and;
- It does not seek to assess the cyber ecosystem holistically;
The failure of SCF to assess environments holistically makes it difficult to understand the effectiveness of the defence in depth, and how people and processes interact with these controls. This increases the risk of a successful attack as single points of failure may go unnoticed and remediated, and/or important nuances in how people/processes interact with these controls/information may be overlooked.
Despite the obvious need for and advantages of assessing cyber security ecosystems holistically, there is no prescribed model or approach in any of the most popular SCFs (ISO 27001, NIST, SANS etc.) for doing so.
Enter Security Architecture. Security Architecture frameworks - such as the Open Security Architecture Framework - help organisations to:
- Simplify the management of the increasingly complex cyber-ecosystem
- Integrate threats, vulnerabilities, risks, services, assets, and technologies and document the relationship between them
- Provide solutions (patterns) to solve standard problems
- Abstract solutions so that they are appropriate for stakeholders at different levels within the organisation
- Provide traceability of business requirements through to system implementation and operation
with the ultimate goal of making security effective. Security Architecture process aims to achieve this by creating a linkage and alignment between layers:
- Organisational context & security drivers (I.E Compliance, Threats, Business Requirements, Business Opportunities)
- Management of the security programme (I.E Gap Analysis and specifying business requirements)
- Security technology architecture (I.E conceptual framework, logical architecture, design and development)
- Security Operations (I.E Services, devices and applications)
As each 'layer' informs the next it ensures that the architectural components mutually support and complement one another. As each layer is informed by analysis performed at the layer above, an architectural approach provides an improved mechanism for specifying security requirements in a proportional and cost effective manner when compared to a traditional SCF approach.
Security Architecture also supports risk management, governance, and compliance activities. For example, it is possible to map back key architectural artifacts and deliverables to SCF in order to demonstrate compliance.
SCF therefore still have there place, but they should be considered as a component in a larger enterprise security architecture programme. Not a panacea for your information security issues. Remember, if your aim is to be compliant, you’re probably not secure; if you’re secure, you’re always going to be compliant.