Security Architecture Build Phase: Planning and building a defendable architecture

By following the principles of defendable architecture, you will come a long way towards securing critical services.

Written: May 2020

Reading Time: 7 minutes

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?

This article, written by Erik Kvarvåg, Chief IT/NFVi Infrastructure & Security Architect at Telenor and colleagues, is the third and final in a series about defendable architecture.

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.

Effectiveness Performance
Effective 100% of the incidents the control is meant to mitigate are prevented

100% of incidents identified by the control are mitigated within specified timeframes

Mostly effective 80-99% of the incidents the control is meant to mitigate are prevented

80-99% of incidents identified by the control are mitigated within specified timeframes

Partially effective 50-79% of the incidents the control is meant to mitigate are prevented

50-79% of incidents identified by the control are mitigated within specified timeframes

Not effective <50% of the incidents the control is meant to mitigate are prevented

<50% of incidents identified by the control are mitigated within specified timeframes

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.

Defined Security Capability & Mitigation Effectiveness.

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.

Security Capability Implementation plan

The figure above shows a sample implementation roadmap of the defined capabilities. Note that additional work is required to ensure that proper process support will be in place for the organisation. After all, there is little point in investing millions in a tool if it is not properly integrated into operational alerting and incident response processes.

One very important factor when planning for the implementation of security controls is that some of the capabilities are easier to implement independently than others. Implementing a network topology and security boundaries for the infrastructure platform and the perimeter is less complex and with less impact to services when being setup as green field installation. Centralised logging however can be more easily implemented on top of the existing infrastructure without any service impact.

As a final note, it should also be mentioned that it is important to maintain operational security during the build phase. Proper care should also be taken when sharing documents, diagrams, or other information that can be of great value to an attacker. This is even more important if the infrastructure to some degree is suspected to be compromised and being built for the purpose of migrating services out of a so-called burning platform into a new secured environment.

By following the principles of defendable architecture, meaning assessing threats, modelling around them, designing security controls, and implementing them all tailored to the organisation, you will come a long way towards securing critical services. While this is essential under normal circumstances, the COVID-19 crisis demonstrates that the security of digital services is critical to our society’s ability to operate. Therefore, the services need to be available and preserve both the confidentiality, integrity, and availability of the customers they serve. By sharing some of the workaround building and securing critical infrastructure within Telenor, we hope that others also can benefit and add to their part of responsible business.

Eager for more knowledge? Continue by diving into how you can defend your infrastructure through Security Operations.