A small DevOps bug, a giant opening for attackers

A small DevOps bug, a giant opening for attackers

When you look at the breach statistics in today’s cloud-dominated IT world, you can see several examples where a small mistake made by the DevOps or CloudOps team has had a tremendous impact on a company’s reputation or, in some cases, in its existence. Misconfigured AWS S3 buckets, poor password management in publicly exposed databases, and secrets inadvertently exposed by developers on GitHub are a few examples of these mishaps. It’s not uncommon to see misconfigurations and unpatched vulnerabilities pave the way for attackers.

For example, during one of IBM X-Force’s AWS cloud penetration test engagements, researchers exploited a server-side request forgery vulnerability in a web application under development, allowing them to access the service. of the EC2 instance’s metadata and steal the access keys used by the EC2 instance from the web server. Inadvertently, the CloudOps team provided full access to an S3 bucket through this instance profile, allowing researchers full access to sensitive information stored in that bucket.

Since the inception of the cloud, solutions offered by cloud service providers (CSPs) have enabled companies to innovate faster and minimize the time it takes to develop and deploy production applications, but this process is associated with a additional security risk. CSPs may be responsible for protecting their cloud platforms, but companies are responsible for protecting the data on those platforms, which can be a challenging task.

The struggles of cloud adoption

When cloud adoption began, many companies began their journey to the cloud using Infrastructure as a Service offerings from CSPs, the good thing is that they were happy with the level of control they had over the infrastructure. Over time, adopters began to realize that maintaining their infrastructure in the cloud was becoming too complex and time-consuming, leading to a shift to platform-as-a-service (PaaS) offerings. Along the way, CSPs have enhanced their PaaS offerings to make them more reliable, feature-rich, and simpler to operate and integrate, and therefore more attractive to their customers.

But by using a PaaS offering, companies have not outsourced the responsibility of protecting their data to the CSP. Enterprise CloudOps and DevOps teams are responsible for configuring all elements of any cloud service securely to avoid exposing your enterprise data to threats. And that’s where companies are struggling today.

Companies ask questions like: “Have I configured the security tools provided by my CSP correctly?” “Do I have gaps in my identity and access management processes?” “Are my cloud-based storage containers configured correctly so that only legitimate access is allowed?” “Am I correctly integrating security into my continuous integration/continuous delivery pipelines?” These questions can be difficult to answer if security best practices are not included in every step of the development lifecycle.

Additionally, skilled professionals who are knowledgeable about CSPs are difficult to find and retain, presenting challenges to successfully running, securing, and maintaining critical cloud assets. Over the past year, we have seen attackers targeting supply chains, which are outside the direct control of companies. Many companies struggle to keep up with visibility into who is accessing their cloud infrastructure, what types of permissions users have, and what misconfigurations exist in their cloud environment.

Cloud operations: threats and trends

While it is easy to understand the benefits of cloud computing adoption, understanding and addressing the threats associated with today’s hybrid multi-cloud deployments is not easy.

Attackers find entry points into cloud infrastructure by using a variety of tactics, ranging from credential hunting (such as scanning accidentally exposed credentials on code hosting platforms, phishing, and social engineering) to exploitation of vulnerabilities and misconfigurations found in public-facing cloud-based services. assets (web applications, storage, etc.) to move from local victims to cloud infrastructure.

Developers can also be lucrative targets. For them, the public cloud is the perfect platform, providing all the tools they need to write/run/debug code, collaborate with other developers, and act as a centralized platform for code testing and deployment to production. Developers, however, often work under pressure to quickly move their code into production. When this happens, they are prone to mistakes and sometimes overlook security. For example, lack of proper handling of secrets (APP keys, passwords, certificates, etc.) can lead to exposure of the production database administration password, which can mean the end of the game for many companies. CloudOps admins can use over-privileged users or roles as a “temporary” or “quick” test, but often forget to enforce the principle of least privilege after a successful test, allowing for an abuse scenario. privileges and data leakage.

These kinds of things are exactly what attackers are looking for, and once they have compromised the cloud asset, they are free to take the next step towards their ultimate goal (data manipulation, exfiltration, etc.).

Cloud protection: recommendations

When it comes to cloud security, IBM Security X-Force believes that companies should focus on three elements:

  • Invest in developing a security mindset for your DevOps process. ‘Start left’ instead of ‘shift left’. Testing your code for security flaws early in the development lifecycle (shift left) should be combined with writing secure code (start left). Developers should also take security awareness training so they understand the signs of a social engineering scam. In serverless environments, developers are the new target.
  • Leverage cloud-native security tools (Provided by CSP and commercially available) to enhance your threat detection and response capabilities.
  • Conduct regular cloud security assessments (configuration reviews and penetration tests), which will show you how likely attackers are to break into your cloud environment and reveal how they would exploit discovered weaknesses. Assessments should conclude with prioritized recommendations for you to implement so you can reduce the risk of a compromise and build security best practices across your cloud workloads, people, and overall infrastructure.

Learn more about the X-Force Red cloud testing services here.

Leave a Comment