Menu
Cybersecurity can be difficult to manage effectively due to its massively broad range of potential concerns, risks, and threats. Bringing effective and focused management to cybersecurity often relies on aligning with one or more “best practice” standards or compliance initiatives to ensure that coverage is holistic. These standards can include ISO/IEC 27001:2013, ISO/IEC 27032, the NIST CSF (Cyber Security Framework), the UK government’s Cyber Essentials scheme, or the British Standard’s “PAS 555” specification. However, these standards can be sprawling in nature and difficult to distil down into an essential security programme summary. Gaining clarity at the strategic level by adopting and aligning clearly with a simple security model allows organisations to both gain clarity and focus as to their objectives. It also ensures that they apply a consistent approach across their entire cybersecurity programme via the application of a few key principles in all key decision making. One such model or approach is the so-called “security onion” model.
In this blog post, we look at what the “security onion” model encompasses, how it can be applied, and what value this provides to an organisation’s cybersecurity programme and initiatives.
Cybersecurity practitioners and security teams do not operate in a bubble. In order to be effective, information security has to be incorporated into a company’s overall strategy and incorporated at decisions up to board level. This means that those in cybersecurity teams can often be required to explain security principles to those not familiar with – or often interested in – the technical details. This can include ensuring widespread security awareness by delivering simple explanations of essential security principles and concerns to those in non-technical teams such as warehouse, sales, or production through to senior management. Information security awareness messaging therefore often needs to be adapted to fit the understanding of a wide cross-section of people and teams. Simple models and metaphors can help to deliver this messaging and highlight essential concerns.
Having a security model helps to abstract away from the technical details of a given suite of security tools and provides a vendor-neutral description of the approach that can then be assessed on the merits of its principles rather than any technical or implementation details. Security models can be specific to certain security concerns, such as the Bell-LaPadula, Biba and Clarke-Wilson security models that are frequently referenced in relation to access control in relation to data confidentiality and integrity. The security onion model in particular however is more abstract than these academic models and offers a paradigm outlining an overall approach to cybersecurity.
Adopting and aligning with a security model can help to delivery clarity and focus even with security teams. Retaining a simple model of security that is both explicitly outlined in documented strategy, as well as referred to internally as a mental model or aide memoire can help ensure that everyone is working under the same over-arching direction of effort and governing principles. In can ensure that the same concerns are brought to bear uniformly in every management or procurement decision, as well as providing a clarity of purpose and a simple referential check, letting teams “see the forest for the trees” and not lose the overall picture while engaged in any given task.
Cybersecurity is essentially defensive in nature. It focuses on preserving the existing confidentiality, integrity and availability of an organisation’s operated systems, services, and data. As with any defensive system, there is therefore a mixture of elements that need protection (known as assets), as well as elements providing the protection: in cybersecurity the latter are termed “security controls”. The standard use of security controls involves the installation and operation of both safeguards and countermeasures. Safeguards are the collective use of processes, policies, procedures, applications, items of hardware or configuration items that mitigate against a security risk. Countermeasures are the actions taken to patch a vulnerability or secure a system against an attack and can include altering access controls, reconfiguring security settings as part of hardening efforts, installing new security devices or mechanisms, or adding or removing services.
The security onion approach is a model of the best pattern by which to deploy controls in order to protect cybersecurity assets. The model uses the visual analogy of an onion, in that controls are applied in multiple, ringed layers of defence around the asset they are protecting.
The security onion model can be applied strategically in providing multiple layers of controls protecting an organisation’s core assets or network; it can also be implemented tactically by being used as a repeated pattern applied to the protection of each individual asset at the local level.
The security onion model aligns very closely with the concept of “defense in depth”, a security paradigm in which defense is applied concentrically in multiple redundant layers rather than in a single hardened perimeter. In the security onion model, each security control provides redundancy in protection in that a failure of a single component or layer does not leave the entire system vulnerable. It also typically incorporates an element of diversity, such as the use of firewalls from multiple, different vendors at various layers so that a vulnerability in one device is not fatal to the overall security protection afforded. This same strategy was used in medieval castles to provide multiple layers of defense to resist lengthy sieges. In addition to multiple layers of walls (perimeters), a medieval castle used an array of protection mechanisms, which often complemented each other (such as a moat, a drawbridge, bastion towers, an outer courtyard, an inner court, and an inner keep).
Paradigms such as “assume breach” put emphasis on the fact that no single layer of security or control is entirely infallible, so applying multiple concentric layers of security can help to tackle this: each partially blunts the effectiveness of any given attack in an aggregating manner such that they cumulatively thwart or substantially stall any attack. Even if an attack is not therefore impossible, security assurance may be achieved by becoming too “expensive” a target for attackers: attackers are in it for the money and making a system disproportionately hard to exploit compared to the effort involved can be enough to make attackers looks elsewhere for an easier or “softer” target. Its like the old joke about outrunning a bear: you don’t need to run faster than the bear, only faster than the guy next to you…
At the strategic level, because the metaphor of security as an “onion” is so loose that the model is often applied in different ways depending on the specific challenges a given organisation faces or the particular approach it wishes to highlight. All are aimed at ensuring that a security programme is holistic in terms of coverage, but this coverage can be defined in various ways: the “layers” can be temporal for example, in defining all the stages that security should be applied at (from initial culture and training, through preventative measures and threat management to post-breach containment); they can also be categorical, in defining the different control forms that should be stacked (technical administrative and physical controls); or by purpose, in defining controls via their type (often listed as preventative ,detective, corrective, compensatory, deterrent and recovery).
The commonality in all forms is that onion model is used to ensure that the organisational cybersecurity programme is “full stack” in terms of incorporating controls at all layers of operation and that all activities of the organisation are performed securely. It can often be the case that security is considered a separate and dedicated security function that is someone else’s concern: that security exclusively relates to the use of dedicated tooling such as firewalls and antivirus software and that nothing beyond this is required. The security onion model challenges this by showing that security should be considered across all business activities, regardless of the type.
The most common interpretation of the security onion model at the strategic level is one that defines the scope of the security programme in terms the different areas of concern that the security programme should incorporate:
On the tactical layer of an individual system or data set, the security model can also be applied as a model of the multiple layers of protection afforded by specific individual controls. For example, a key web application service may be defined as having a holistic range of protection under the security onion model:
As with all models, the security onion model is far from perfect and has its fair degree of critics. The list below outlines some of the more frequently levelled objections to the model: whether the model is useful to you will depend an awful lot on your organisational context, but the below points are certainly worth at least bearing in mind if looking to adopt the model:
Because the model is somewhat imprecise and nebulous, a common criticism is that it is too ambiguous to be useful. It does not list exact measures for any single layer and is subject to very subjective interpretation and implementation. Because of this, it is sometimes argued that the model isn’t really a security model at all, but simply a metaphor. If this criticism is accepted, then the concept may still be useful as a conceptual model to present for illustration as a principle during training but may lack any further usefulness.
Security teams are often looking for simple “checklists” to cover off concerns in a given area or field, as illustrated by the runaway popularity of the “OWASP Top 10” web application security risks published by the Open Web application Security Project. Because the security onion model is descriptive only and does not contain an exact list of measures that can be followed as simple, prescriptive guidance it can lack appeal for teams simply looking to benchmark their efforts against a checklist and ensure that their security programme is providing appropriate coverage.
The security onion model is based upon the basic principle of redundancy in operated controls, with multiple controls being deployed to protect the entire estate, or any given asset. This fairly typically means that it is a relatively expensive model to implement.
Multiply redundant and potentially overlapping controls can also lead to a significant increase in complexity, both in implementation as well as ongoing management. The complexity of applying and managing a broader suite of controls can prove to be excessively burdensome – especially in a small team. Increased complexity can also lead to greater uncertainty and (perhaps ironically) a greater chance of there being “holes” in security coverage, with teams struggling to stay on top of an increasingly complex security control suite.
Complexity and cognitive overload have a cost beyond the financial and so-called “cognitive overload” is one of those costs, leading to issues such as increased time to deliver on tasks, increased risk of mistakes in design or operation, uneven performance, and a loss of visibility or control of the overall picture.
The security onion model can sometimes be (perhaps unfairly) criticized as a “throw everything at the wall and see what sticks” approach. It is sometimes argued that the security onion model can misdirect teams from an approach in which they only apply the most appropriate and proven-effective controls against specific threats based on a risk management programme. Approaches that align with threat modelling and formal risk management may argue that some assets simply do not merit comprehensive or holistic control coverage, based on a minimal threat and a cost-benefit analysis. Since controls are only meant to mitigate risk, it does not make sense to apply additional controls to protect an asset in situations where the overall cost of control implementation exceeds the asset value.
While the concept of defense-in-depth and security onion is intuitive and easy to grasp, it may not best lend itself to modern cybersecurity topographies. The security model is concentric and best applied to model the protection of highly centralised topographies with highly sensitive assets at the core and facing persistent external threats through a relatively hardened perimeter.
In contrast, modern systems and networks can be highly complex and with much more diverse attack vectors. Incorporating distributed architectures such as “borderless networks”, highly inter-active systems, and growing insider threats means that alternative security paradigms have increased in popularity. In comparison, the security onion model seems a poor conceptual fit. Alternatives such as the “security artichoke” – involving multiple partially overlapping but not entirely redundant controls – are sometimes offered as more flexible models.
The security onion model typically focuses on layers of defense: that is, on the provision of primarily defensive or “preventative” controls aimed at avoiding a breach. Whilst this may seem entirely appropriate on first pass, recent years have seen an increasing emphasis on what is known as the “assume breach” mentality. This approach incorporates explicitly allows that security attacks and exploits are bound to occur and seeks to de-emphasis what it sees as an over-reliance on preventative controls.
Arguing that a kill chain can be disrupted at any point from initial reconnaissance through to data exfiltration, the assume breach model does allow for preventative measures still but provides much greater emphasis upon additional provision of controls that provide for the kill chain to be disrupted at other often later stages even after a breach has begun. These include controls that increase the ability to provide detection of an attack, corrective action in response to it and, ultimately, the rapid recovery of services following an attack. The newer security models emphasize speed of recovery in particular over defense, based upon the ability to recover data and data services quickly.
Whilst imperfect, the security onion model still provides a useful conceptual model that highlights the need for defense in depth in a simple, illustrative way. It is perhaps best used descriptively and as a simple model for training purposes than attempting to adapt it as a prescriptive approach.
As with all security models, simply considering the model can help broaden your understanding of security concerns and highlight different potential approaches, adding extra “tools” to your toolkit that can be drawn upon as needed, rather than which you are forced to apply in every situation: having a screwdriver in your toolkit is essential, but it doesn’t mean that you have to use it when you need to hammer in a nail.
AppCheck can help you with providing assurance in your entire organisation’s security footprint, by detecting vulnerabilities and enabling organizations to remediate them before hackers are able to exploit them. AppCheck performs comprehensive checks for a massive range of web application and infrastructure vulnerabilities – including missing security patches, exposed network services and default or insecure authentication in place in infrastructure devices.
External vulnerability scanning secures the perimeter of your network from external threats, such as cyber criminals seeking to exploit or disrupt your internet facing infrastructure. Our state-of-the-art external vulnerability scanner can assist in strengthening and bolstering your external networks, which are most-prone to attack due to their ease of access.
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
