Technologies such as Kubernetes and Terraform have revolutionized the way how scalable applications are deployed. By using cloud-native tools, companies can focus on implementing the business logic of their applications rather than having to maintain a dedicated IT infrastructure.
In such environments, cloud security requires special attention - but it must also keep pace with technological advancements. What are the right priorities?
Picture: insspirito/pixabay.com
Shared Responsibility Model
It is a misconception that cloud applications are more secure out of the box because the provider takes care of security. Security in the cloud remains a shared responsibility between the user and the provider.
According to the shared responsibility model, the cloud provider is responsible, among other things, for the physical security of the hardware or the up-to-dateness of the drivers, for the underlying operating system, the runtime environments, and the physical protection of the network.
Cloud users, however, remain responsible for application security and the correct configuration of the cloud environment.
User overall responsibility varies from 8 to 52 percent, as estimated by Ory Segal. In the following sections, we will outline best practices and tools that specifically apply to the responsibilities of cloud customers.
Application Security with SCA
Software Composition Analysis (SCA) examines which third-party libraries are contained in an application. This is necessary to detect existing security vulnerabilities in the third-party libraries, better known as CVEs (Common Vulnerabilities and Exposures).
Such an analysis of the software composition also examines the application environment. For example, it looks at which applications and shared libraries are installed in a virtual machine or Docker container and whether they contain known security vulnerabilities.
SCA has become an inevitable tool for enforcing application security. This is mainly due to the fact that software nowadays makes extensive use of existing code in the form of libraries instead of reinventing the wheel for each project.
Application Security with SAST
Static Application Security Testing (SAST) is essential in any well-structured Software Development Lifecycle (SDLC). It examines the source code of applications to identify security vulnerabilities and anti-patterns.
Many commercial and free tools exist on the market for performing static code analyses. Some can be integrated as plug-ins directly into the developer’s integrated development environment (IDE) so that developers already receive early feedback on potential security vulnerabilities. This “shift left” approach prevents surprises during the build and deployment process.
Cloud Configuration Security with CIEM
Access management is an essential security topic and is used to manage access to services and resources. In addition to the individual cloud resources such as databases, virtual machines, containers, functions, and S3 buckets that communicate with each other, it is also necessary to tightly manage user accounts in the cloud.
Cloud Infrastructure Entitlements Management (CIEM) is the right tool for this and provides a graphical representation of the access permissions within the cloud. From an organizational perspective, CIEM allows the access permissions to be kept to a minimum in line with the Principle of Least Privilege.
Cloud Configuration Security with CSPM
A Cloud Security Posture Management (CSPM) tool finds misconfigurations within a cloud account. It checks all resources for conformity with common rule sets such as the Service Organization Control 2 (SOC2), Payment Card Industry Data Security Standard (PCI DSS), or the benchmarks of the Center of Internet Security (CIS).
Common rules in the benchmarks include typical errors such as open ports for SSH, missing data encryption in transit or at rest, or publicly exposed resources such as S3 buckets and databases.
Context and Prioritization
The mentioned tools are essential to secure cloud environments. Errors in the cloud setup or vulnerabilities in the application can easily open a door for attackers.
In an ideal world, security teams would close all vulnerabilities as soon as they appear - but the reality is more complex. DevOps and Security teams are often understaffed in terms of personnel and available resources.
Teams need to focus on the most critical issues to keep up with the large number of alerts from various tools. Often, the severity assigned to vulnerabilities automatically define the priority.
But judging solely based on severity can easily lead to misjudgment. For example, an affected database server could be an unused test instance that cannot be reached from the internet and doesn’t have any critical data on it. The priority of such a vulnerable database would be low despite a high severity of a finding.
Security teams have to be cautious when prioritizing mitigation activities and can’t exclusively rely on severity scores. The full picture (context) of the application and environment is necessary to accurately assess the risk of a vulnerability.