Cloud Security Part 1: Understanding Your Attack Surface
Driven by the Coronavirus pandemic, over the past three years organisations have rushed to deploy infrastructure, systems and applications to the cloud as they enabled an almost entirely remote workforce and learnt to compete on a global scale in conditions the world had not seen before.
However, this hasty adoption to innovate, grow and remain competitive meant many organisations suffered ‘cloud sprawl’ (the uncontrolled proliferation of an organisation’s cloud instances, services or providers) and now they struggle to get visibility of and understand the nature of their cloud environments.
Often, these cloud deployments were installed without the proper cloud security policies or guardrails in place, meaning not only has the attack surface expanded but the likelihood of misconfigurations has grown.
Coupled with this, many organisations have expanded their supply chain to integrate in the cloud with many third-party organisations, thus exposing them to additional risk as the digital pervasiveness and interconnectedness of their eco-system proliferates. This has left many organisations puzzled and worrying about how they can get full visibility and an understanding of their entire attack surface, including their cloud environment.
In this four-part series on cloud security, we will be exploring how organisations can secure their ever-expanding cloud footprint. In this first instalment we explore how you can get visibility and an understanding of your entire attack surface, including your cloud environments.
Chapter 1: What are you trying to protect?
In order to manage this heightened exposure, organisations first need to understand the attack surface they are trying to protect, this encompasses not only their on premise and cloud environments but also the third parties they are integrating, connecting and transacting with.
Only by understanding and subsequently consolidating your attack surface, can you effectively monitor it for misconfigurations, the most likely weakness an attacker will exploit.
Once an organisation gains visibility of its attack surface, threat intelligence, control validation, and adversarial emulation can be applied to people, processes, and technologies to improve the prevention, detection, and response capabilities of the organisation.
It should be noted that continuously identifying and remediating every security issue across an organisation’s environment is not practical due the finite resources of most organisations. Therefore, organisations need to focus resources and remedial efforts on their most critical assets. To become more efficient, security teams must understand the concepts of attack vectors and attack paths.
Attack Vectors vs Attack Paths
Attack vectors are the methods leveraged by adversaries to gain unauthorised access to systems and data. Such methods are extremely varied but could include system misconfigurations, exploitable vulnerabilities, user privileges, or risky user behaviours.
Adversaries will leverage tactics, techniques, and procedures to exploit attack vectors and perform privilege escalation or lateral movement. Chaining multiple exploitable attack vectors together to achieve the attacker’s objectives defines the attack path.
While it is essential that organisation’s gain and maintain visibility of the attack vectors that make up their attack surface, it is the process of validating attack paths which pose the most risk to critical business assets, that will provide the most security benefit.
This leads to Attack Path Management. Attack Path Management is the process of identifying attack vectors which can be combined to form validated attack paths to compromise critical assets. Often multiple attack paths will share a single attack vector along the path, which is known as a choke point. Identifying and eliminating such choke points will significantly increase the value of remediation efforts performed by the organisation’s limited security resources.
Context is crucial to understanding risk
Organisations must adopt a strategy of security prioritisation if they are to be effective. To do this, they must realise that not all company assets and data are equal. Attack vectors in isolation do not provide sufficient context of business risk:
Asset A is a system that is determined to be affected by critical vulnerability that includes a publicly available exploit. The vulnerability is rated 10 using a CVSS score (Common Vulnerability Scoring System).
Asset B is a system determined to have no vulnerabilities and is fully patched. However, it is used by a member of the Google Cloud DevOps team to manage cloud resources via the Google Cloud CLI.
While each system represents an attack vector, the lack of context prevents the security team from understanding the risk posed by each. If we add the following context, the associated risk becomes more apparent:
Asset A is located in an isolated network segment on the corporate network and does not contain a local administrator account and has no access to email or any sensitive data. However, it does contain a legacy Microsoft Access database which stores the serial numbers associated with decommissioned printers.
Asset B is a laptop used by a remote member of the Google Cloud DevOps team. Due to the nature of their work, they have been provisioned with an Identity & Access Management (IAM) role that contains sufficient permissions to provision, modify and delete resources within the Google Cloud environment. As part of their daily activities, numerous service account keys are being stored on the laptop.
Attack path management is a process that supports identifying such obscured risk. Using the over simplified example provided, the organisations security team would understand that a compromise of the asset B provides significantly more risk than that of asset A. In fact, asset B is part of an attack path that would permit lateral movement not only between the laptop and the Google Cloud environment, but potentially further privilege escalation and lateral movement within the cloud environment.