Security Architecture Build Phase: Planning and building a defendable architecture

In the previous article about threat intelligence driven defendable architecture, we talked about the process of defining a set of defensive controls through threat modelling and risk analysis. Now, let’s assume that this process has been conducted and we can present a set of defined capabilities along with their presumed effectiveness. Since there is no such thing as a free lunch – or budgets for that matter – this applies to security in the same way as it does to every other type of investment; security controls need to be implemented over time with a set target in mind and a roadmap to get there according to each individual organisation’s budget. We are also going to look at how the implementation of these controls can be executed in a staged manner when conducting strategic technology modernisation investments to ensure that security is embedded in all technology projects and that the required investments are distributed more evenly.

Read the first article in this series about Defendable architecture: Telenor’s Technical Security uplift

As a sample for how to implement a set of security controls for an IT or telco data center infrastructure, we will look at 14 defensive capabilities that have been defined and grouped into three main areas. These 14 capabilities have in turn defined three “implementation-levels”. This will in turn make them more effective in mitigating threats, and investments can spread out over time.

Read the second article in this series about Defendable architecture: Security Architecture Design Phase

Note that the defined security controls as described here apply to the technology dimension of the infrastructure only. The equally important areas of people, processes, and vendor management are not covered in this article, yet this also needs to be considered when building a defendable architecture. The maturity of processes and the level of competency directly affect the effectiveness of a capability. After all, what’s the value of a vulnerability scanner if there doesn’t exist a process that handles the discoveries? Or, if we lack competent engineers to patch operating systems and update all the different software components, for that matter?

The defined controls implemented in the defendable architecture centre around three key areas following major controls from CIS20.

The first area is prevention. This is about limiting the possibilities for the threat actors to break into the infrastructure. The process includes building a strong outer perimeter as well as multiple internal boundaries and putting critical data in the internal parts of the infrastructure. The second purpose of an infrastructure focusing on prevention is to have proper mechanisms for resource isolation to make any lateral movement by threat actors inside the infrastructure as difficult as possible.

The second area of a defendable architecture, and equally important to preventive capabilities is detection. If a threat actor manages to breach the network perimeter and gain a foothold, detection is paramount. This enables a proper incident response, with the aim of evicting the threat actor from the infrastructure. Since all components used are software with billions of lines of code collectively in them, all with the possibility of a flaw, it’s a certainty that a threat actor will be able to eventually breach the system. While the preventive capabilities will keep out the lower tiers of threat actors, the more advanced threat actors will sooner or later find their way in – and when they do, be evicted. The successful incident response depends on the ability to rapidly detect the attack.

The third key area is access to the infrastructure. Operators need to be allowed legal access in a secure way to perform their daily tasks. You must also ensure that resources they are accessing are based on least privilege and need to know basis. As infrastructure operations increasingly become outsourced, the requirement for well-developed capabilities for access is also growing.

Defined Capabilities:

• Preventive

  • Platform Security Boundaries, internal

  • Perimeter Security Boundaries, external

  • Infrastructure support services

  • Software Security

  • Vulnerability Scanning

• Detection

  • Flow Based Monitoring with AI

  • On-demand network tapping

  • Logging and auditing

  • Endpoint Security, Detection and response

  • IDS/IPS Sensors

• Access

  • Operator Remote access

  • Use of Privileged Access Workstations

  • Identity and Access Management

To further build on the different defensive controls to both improve their mitigation abilities and to make them easier to build up over time to gradually improve the security posture implementation, sub-levels have been attached to each of them. These sub-levels are defined as basic, intermediate, and advanced for each control. They describe either additional functionality added to a control or by expanding its degree of coverage. As an example, let’s look at one of the defined controls in the form of logging and auditing.

At its basic level, a centralised log platform is deployed to collect all information from the infrastructure and stores in a single place. On the intermediate level, the log platform has been upgraded to a security incident and event monitoring platform (SIEM). It can now provide analytics and recognise patterns in the collected data. At the advanced level, the analytics are enriched by an external threat intelligence feed and have added capabilities to trigger an automated response when analysis of the collected data indicates an ongoing security incident.

The effectiveness of the defined controls above also needs to be measured, since they not only need to be effective but also require proof of their effectiveness, which needs to be obtained in an objective manner. The table below gives a mathematical approach to defining what is defined as effective.

Based on the assessment above, a series of security controls can be defined. The controls have criticality levels attached to them and are then measured for their ability to mitigate risks originating from different levels of threat actors based on the measurement of mitigation as described in the table above. Threat actor mitigation level (TAML) efficiency ratings are based on the ability to suppress and mitigate the different threat actors’ ability to exploit attack vectors and vulnerabilities as identified when using attack trees to simulate threats.

In the figure above, a sample capability is green when assumed to be effective or mostly effective in mitigating a threat, orange when of partial effectiveness, and red when it is considered to not be effective at mitigating a threat. This is based on the assumption that more advanced threat actors are able to circumvent more basic controls, and additional and more advanced features are required for those.

To illustrate the concept, the mapping of the 14 security capabilities below shows the assumed ability to mitigate the different levels of threat actors. This is based on their techniques, tools, and capabilities matched against the attack surface and possible attack vectors of the organisation’s critical assets. The assumed effectiveness may vary from organisation to organisation. It depends on differences in the assets themselves and the components that they are composed as well as the availability of process maturity, the availability of competent (or not competent) operations and security staff, and supportive management.

With the overall mitigation goal set and security capabilities defined through the risk assessment and threat modelling, the next step is to create an implementation roadmap. The roadmap should take into account existing capabilities and controls to identify the largest gaps. Further, it should pinpoint where the security posture can be increased the most in the shortest time by closing those gaps. Again, this is governed by the target to address the assets that have been defined as critical in the previous rounds of threat modelling.