How to Build Your DevOps Cloud Security Stack

For a long time, the best approach to network and data security was network segregation. If you protect your intranet from the Internet, there are significantly fewer vectors of attack. But with 94% of organizations using multiple cloud platforms, the old cybersecurity practices are no longer valid. From AWS to Zoom, there are dozens of cloud tools and services developers use and can introduce potential security threats.

While cloud services are no longer new to Software Development Lifecycle (SDLC), security issues and concerns are growing. As dependence on cloud services grows, so does the motivation for malefactors to figure out new avenues of attack. In many cases, attacks are simply a result of effective and quick snooping across exposed cloud assets.

There is a growing concern for cloud security among experts in recent years, backed with regulatory demands and a plethora of solutions for keeping your cloud services running securely. But considering just how complex cloud computing security can get, where do you even start? And what do you need to know to build your DevOps cloud security stack?

What Is A Cloud Security Stack?

Any technology stack is a set of solutions that work together to achieve an end goal. A security stack is a set of services or tools that work together to maintain the security level necessary for your organization.

In the case of cloud security, more is not better. 53% of companies investing over 100M in cloud services are using 2-5 security tools. A well-thought-out stack of tools is best formed with a strong base of robust solutions.

Why You Should Take Responsibility For Your Cloud Security

Cloud service providers can and will do everything in their power to secure the cloud itself. They have the financial motivation to do so. Nobody will use a Cloud service that has been shown to have vulnerabilities. However, cloud service providers do not have access to your entire software stack and cannot provide security for anything outside their control.

This situation can confuse companies eager to protect their cloud-based applications from cyber attacks, data leaks, and misconfigurations. In fact, 73% of companies report not having a clear understanding of where their responsibility begins and where the CSP’s responsibility ends. This statistic strongly suggests that the overall positive notion companies have of enterprise cloud security cloud be misconceived. 

Innovative teams are already getting ahead of the problem and not waiting on CSPs to shoulder more of the cybersecurity load. The “shared responsibility model” is quickly becoming the most common security model among industry leaders. For example, the AWS team has written a very clear guide on how the shared responsibility model works when using their cloud services.

This model applies to the majority of cloud services. In addition, AWS encourages you to have a zero-trust policy, i.e., do not trust anything unless you can verify its trustworthiness. A zero-trust policy and a well-defined shared responsibility model are the two main building blocks upon which you should construct your cloud security stack.

3 Essential Building Blocks For Any Cloud Security Stack

The process of setting up your Cloud security stack is the same for all DevSecOps teams. So, if you’re setting up from scratch or running maintenance and adding optimizations, the same holds.

1. Identify requirements

The recommended approach to building a cloud security stack is to identify your requirements as early as possible, ideally during cloud service planning. If you know which services you’re going to use, you can better prepare for potential threats.

When accounting for cloud services that you need to secure, you must account for all cloud services, even innocent-looking SaaS such as Zoom and Slack. However, it is also best to do some risk assessment. What kind of exposure is likely from loss of security with such services? For example, Slack credentials may provide malefactor access into other parts of your cloud, posing a more significant potential threat than Zoom credentials.

Make sure you are also aware of who needs access to what. QA teams may not need the same level of access as developers. Some people on your team may need access to your CI/CD pipeline, while others do not. The least access privilege policy, along with a correctly configured stack, will significantly reduce the risk of leaks. 

Software, Platforms, and Infrastructures as a Service all need to be secured. No service provider can fully secure a platform, as even the lowest exposure platform is accessed using credentials. In fact, you should consider credentials as your first line of security. Almost all significant cyber-attacks involved leaked credentials, including the now-infamous Solarwinds based data breach. This is why protecting secrets is a vital aspect of a cloud security stack.

The best way to approach identifying requirements is with a checklist. Use other people’s experiences to make sure you have all the information you need before moving forward.

2. Define the architecture

Once you have figured out your organization’s requirements, you will have a good idea about what kind of cloud services you will use. Different types of cloud services require various measures of security.

Infrastructure (IaaS) – Customers are responsible for securing their data, user access, applications, operating systems, and virtual network traffic. However, the most common security vulnerabilities are due to misconfiguration. 5.5% of Amazon Web Services (AWS) S3 buckets in use are misconfigured to be publicly readable, which is a critical data breach no one wants to have to resolve. 

Platform (PaaS) – Customers are responsible for securing their applications, data, and user access. The service providers are responsible for securing the operating system and physical infrastructure. While it is natural to trust that a service provider has done its due diligence in securing whatever they are responsible for? You should research and make sure it is so. This is what zero-trust is all about.

Service (SaaS) – The majority of responsibility lies with the service provider. Users are responsible for securing user data and user access. In other words, users must keep their credentials safe.

Web Services – In terms of security, web services provide similar challenges to SaaS, and as such, the exact security solutions are applicable. 

The architecture will inform what type of security solutions are required.

3. Assess the security controls & identify control gaps

The more connected any system is? The more security vulnerabilities there are. Cloud services may be accessed from many different types of devices that might require various security measures. For example, if a mobile device like a phone is used to access sensitive corporate Cloud services and resources? It must have higher security protocols in case of loss or theft. 

When considering which solutions to add to your stack, it is crucial to consider the types of Cloud services your organization uses and possibly which services you might use in the future. Building a security stack from the ground up, rather than a fill-the-gap approach, will always result in a more secure system.

• Cloud access security broker (CASB)  – CASB is an intermediary between users and cloud service providers. It provides governance, monitoring, data loss prevention, and configuration auditing, among others.
• Cloud workload protection platforms (CWPP) – CWPP solutions are designed to monitor the computational resources deployed on your cloud Infrastructure. The purpose is to prevent system overloads, whether intentional, such as a DDoS, or unintentional, such as bad code.
• Cloud security posture management (CSPM) – CSPMs provide continuous auditing against misconfiguration. With misconfiguration being such a common problem, a CSPM is likely to prevent many security issues; even if your team has experts, human error will eventually get the better of them.
• Static Application Security Testing (SAST) – Any code produced by the development team is a potential security issue. SAST is a method by which source code is statically scanned for potential vulnerabilities. Since it is nearly impossible to scan all code manually, employing a smart SAST tool in your stack is best.
• Data loss prevention (DLP) – DLPs are sets of tools and policies that help ensure that sensitive data remains secure and is not lost. They can be a part of a CASB or work separately. DLP tools are important for any organization that has sensitive or expensive data that must be protected.

Protecting Secrets In Code With SpectralOps

Awareness of cloud security is still not where it needs to be, and many organizations remain vulnerable today. Building your security stack involves figuring out the requirements and finding a simple, minimal stack of solutions to protect your assets. 

At the base of every cloud security stack, you need a SAST solution to scan your code for potential issues statically. Only a secret scanner can protect secrets from leaking through code and other cloud services.

The most important thing to remember is that cloud security is your problem and not cloud service providers. Don’t blindly trust cloud services to be doing their side of the shared responsibility model. Ask around, do your research, and make sure to employ the solutions needed to plug the potential holes in your cloud perimeter. You wouldn’t just hand your credit card to your neighbor for safekeeping. So don’t automatically trust a service provider with the safety of your business assets in the cloud.

And when it comes to your side of the shared security model, make sure to keep your stack small and cover as much ground as possible. Too many tools may trip over each other, but the right stack of 2-5 tools is a great starting point.