Container security in 5 simple steps!
When adopting containers, organizations need to create a risk profile for the types of threats and vulnerabilities they expect to experience. This type of analysis is especially important with containers, since the attack surface increases significantly, while the level of security visibility across hosts, containers, and the infrastructure control plane decreases.
For example, one of the most prominent attack scenarios in containers is the idea of blast radius. After the initial point of compromise, an attacker can escalate privileges quickly to gain control of other containers in the cluster. Since attackers are looking for the greatest returns for the least amount of effort, a vulnerable Kubernetes or Docker cluster may be a great place to strike quickly and do a lot of damage across a wide attack surface.
New, sophisticated attacks to cloud infrastructure emerge every day. But, if you follow the five steps outlined below to create a cybersecurity risk assessment, you can anticipate where your organization may be most vulnerable and strengthen your system’s security accordingly before an attacker gets the chance to strike.
1. Establish the baseline
It’s hard to evaluate risk without baselining what business as usual looks like in your organization. Evaluate your systems, applications, and services as well as scripts that may run in your environment. Try your best to understand who has access to your environment, as well as how and where the data is flowing.
For example, If you have tools in place that gather data across complex, distributed systems, you can gain a better understanding of the intricacies of your “business as usual” operating state. Look at data from past incidents to find opportunities to optimize your processes, operations, and outcomes. This level of security observability will allow your team to proactively identify risks and put mitigation strategies in place prior to an incident occurring — rather than have to deal with issues after the fact in a reactive, ad hoc manner.
2. Identify the threat landscape
Consider probable threats that are typically included in risk assessments, such as insider threats (malicious or intentional), data leaks with unintentional exposure of information, or data loss. Depending on your systems, stakeholders, and environments, you will probably identify additional threats, and you should incorporate these into your assessment. Penetration testing with zero knowledge can help your team understand your system’s vulnerabilities from an outsider’s (read: a hacker’s) perspective.
For example, in a containerized environment, there are often single gateways (such as etcd in Kubernetes) that serve as key value stores for highly sensitive cluster data. These gateways, if left unprotected, can serve as a major conduit for data loss via the unintentional exposure of information.
3. Determine inherent business risk and impact.
Rate the impact of potential threats on your landscape without considering the control environment you have in place. Approach the assessment in this way to prevent factoring in controls that could mitigate the risk, so you can clearly understand the full potential of threat events.
Ever go through the exercise of “What’s the worst that could happen?” Now’s the time to try it. Rank each potential threat based on its likely impact. By way of example, < a href=”https://www.sans.org/reading-room/whitepapers/auditing/overview-threat-risk-assessment-76″>SANS uses the following rankings:
Minor Severity (Rating 1): Vulnerability requires few resources to exploit, with little potential for loss. Exposure is relatively minor. The effects of the vulnerability are tightly contained, and it does not increase the probability of additional vulnerabilities being exploited.
Moderate Severity (Rating 2): Vulnerability requires significant resources to exploit, with significant potential for loss. Or, vulnerability requires few resources to exploit, with moderate potential for loss. Exposure is moderate, meaning that one or more system components may be affected. Exploitation may lead to further vulnerabilities.
High Severity (Rating 3): Vulnerability requires few resources to exploit, with significant potential for loss. Exposure is high, with the vulnerability affecting the majority of system components. There’s a significant probability of further vulnerabilities.
4. Include control environment.
Typically, you need to examine several categories of information to adequately assess your control environment. Ultimately, identify threat prevention, mitigation, detection, or compensating controls and their relationship to identified threats. A few examples include organizational risk management controls, user provisioning controls, and administration controls.
For reference, the CIS Benchmark reports on Kubernetes and Docker give an extensive overview of the security controls that need to be in place in a containerized environment. Access control, proper configuration, and protecting cluster components are three top container security considerations to keep in mind.
5. Benchmark against your industry peers
Finally, consider the industry sectors in which you and your customers operate and the types of data that you store, as well as your size, infrastructure, and assets. These factors will allow you to compare yourself to similar businesses and prepare for threats they have dealt with in the past.
For example, if you are a healthcare organization, consider the additional HIPAA compliance controls and requirements around customer data as you’re transitioning to a containerized environment. Speak to other organizations that have undergone similar infrastructure transitions to find out if there are any particular risks you may not have considered already. If there have been recent, high-profile breaches in your industry, use them for scenario analysis purposes.Share on Facebook Share on Twitter Share on Pinterest