The Role of DevOps in Cloud Security Management

Generally speaking, security falls under the jurisdiction of InfoSec teams. This approach to cybersecurity has worked fine until a few years ago. 

The shift to cloud computing infrastructure has created a dispersed software development landscape, which has been instrumental in the growth and scale of software development. DevOps helps teams create, test, and implement software at an accelerated pace - supporting that agility by using a wide range of services during the entire software development lifecycle. Doing this, however, has also introduced new cybersecurity vulnerabilities that traditional information security silos are ill-equipped to manage. To secure the DevOps environment, the DevSecOps sector - a field whose main pillar is secret management - was created.

Cybersecurity is a must 

It should come as no surprise that cloud security has become an integral part of the DevOps team’s responsibilities. Being proactive about cloud security management (CSM) is critical.

Cloud security: Secrets and how to keep them from leaking

So developers, aside from creating software, must now protect their organizations’ secrets from unauthorized or unauthenticated access and do so during the development process. But what is a secret? Secrets are digital credentials that support access permission - whether human-to-application or application-to-application. The latter employs “secrets” such as passwords, encryption keys, certificates,and API keys, among others.

 For DevOps to protect code from data leaks resulting from secret leaks, they must first be aware of the many ways secrets proliferate in their environment. Secrets snowball via seven drivers that include: cloud-native based development, multi-cloud infrastructure, microservices architecture, shifts from user to machine identity, AL/ML/data analytics, IoT/embedded devices and, yes, DevOps. These drivers create vulnerabilities because they allow more opportunities for errors - whether hardcoding secrets to speed testing, using non-secure open source libraries, or neglecting to take into account security of the cloud versus security on the cloud.

 While there are various technologies to help manage secrets, both commercial and open source, consider your organization’s budget and requirements, the technologies you currently deploy, and your DevOps team’s experience with secret management, and the opportunities to implement and keep those technologies current and up to date.

8 Ways DevOps Teams Can Help Secure Cloud infrastructure

1. Identify the necessary requirements - Forewarned is forearmed, so the earlier this process begins the better. Most companies are already at least partially on the cloud, so sometimes it’s hard to step back to look at the big picture.

Don’t forget - cloud services aren’t just AWS, Azure, and Google. Cloud services encompass all those SaaS applications – from the accounting stack to Zoom. Are teams using Slack or another SaaS-based DM?

If the development or DevOps teams are using their Slack channel to share company secrets, a brute force attack to gain Slack access can put the entire organization at risk.

Access to the CI/CD pipeline needs to be defined and managed with clear governance. 

With a majority of data breaches being caused by human error that leads to misconfiguration, secrets leakage, and poor digital hygiene, it falls to DevOps and DevSecOps to manage who has access to what - a basic requirement of every connected security system.

The DBA needs very different data access than the development team, etc. By following a least access privilege policy combined with a correctly configured stack, you’ll be able to reduce risk.

All IaaS, PaaS, or really any XaaS, need to be secured at the most basic level – at the credential level. Google sends alerts to its business clients on a regular basis, notifying them of potential credential leaks.

Whatever you do, don’t forget ShadowIT – make sure that everyone in the organization is aware that their credential leak could be the weakest link to the crown jewels. ShadowIT raises the risk of a credential leak simply because IT isn’t aware of the many external platforms suddenly connected to controlled internal systems.

Lastly, learn from other people’s mistakes. Intel has a handy security checklist you can use as a basis for identifying cloud security requirements.

2. Define the architecture - Once you’ve identified your organization’s cloud security requirements, you’ll have a more complete picture of the type of cloud services you are already using and others you need to add.

Security on the cloud vs. security of the cloud always needs to be top of mind. Don’t forget that you are responsible for securing your own applications, data, OS, user access, and virtual network traffic. Beyond these, hone up on your configuration basics. More than 5 percent of AWS S3 buckets are misconfigured to be publicly readable. Recently, a simple misconfiguration in Kafdrop revealed the Apache Kafka stacks of some of the world’s largest businesses.

While the big three clouds have invested millions to secure their stacks, the PaaS companies don’t have those budgets – so, check, check, and double check. There’s a reason it’s called “zero trust.”

With SaaS and web security, again credential protection is key.

Each architecture type requires its own type of security – be diligent. For example, a hybrid cloud infrastructure needs a “triple whammy” of security - the on-prem needs to be highly secure with all the ports closed, surface area tracked, and a highly active Security Operations Center (SOC). The public cloud aspect needs to be secured using the latest and greatest security tech available with that public cloud stack. The connectivity between them also needs to be secured against attacks.

3. Analyze existing controls and identify the gaps - Taking a piecemeal approach to the security stack doesn’t work well; building from the ground up is clearly a more thorough, sound approach. Here are a few options that make that possible:

• Cloud access security broker (CASB) 
• Cloud workload protection platforms (CWPP) 
• Cloud security posture management (CSPM)
• Static application security testing (SAST)
• Data loss prevention (DLP)

A CASB serves as an intermediary between the organization and the cloud service provider - and offers configuration auditing, data loss prevention, governance, and monitoring, among other services. Common CASBs include Broadcom, Palo Alto, and Forcepoint.

CWPPs prevent system overloads, such as DDoS or bad code that leads to potential memory overruns. They monitor your cloud’s computational resources deployed on the cloud infrastructure. CheckPoint, Trend Micro, and Carbon Black all offer CWPPs.

CSPMs help detect human errors (one of the major causes of security breaches) by providing continuous auditing to detect misconfiguration, including Spectral, among others.

SAST scans source code for potential vulnerabilities - such as hard coded database access credentials forgotten after testing – to prevent secrets from being released into the wild due to human error/omission.

DLPs may be part of a CASB or a separate technology that delivers tools and policies to secure sensitive data by reducing/eliminating the risk of data exfiltration, whether by bad actors or internal resources.

These tools may be used individually or as part of a larger security stack. They may be used across the organization or just within specific areas – e.g. SAST for development.

4. Focus on protecting your cloud secrets - Firstly, in the ideal world - through education, a security-focused culture, and enough tools, no secrets will leak, ever. But human error will eventually win. So, while generally, the old saw is “faster, cheaper, better, pick two,” the new version needs to include “more secure.” Of course, initial revenue is made during "faster" and "cheaper" - but the repercussions of ignoring “more secure” can have a much longer lasting impact on the business.

Developers are under enormous pressure to get code out the door. Sometimes they take shortcuts or try to simplify access across tools with one easy-to-remember password, or they rotate passwords with an easy-to-guess pattern.

Thus, focus needs to be on credential protection. Keys and passwords need to be rotated automatically where possible, removing the need for human interaction. They must be strong enough to withstand brute force attacks.

Don’t forget about training employees to be aware of the “typical” threats such as phishing, smishing, poisoned links, etc.

No matter how careful a team is, though, we all make mistakes.

5. Scan for misconfigurations - As mentioned previously, in the race for faster, quicker, better, developers have been focused on getting code out the door. One way to accelerate the process is to hard code secrets, like database access, into the configurations. Occasionally, they cut corners by setting “read access rights” to “public” for QA and testing. 

The problem is that developers have so many other things they’re focusing on that they sometimes forget to remove these access privileges – leaving the entire system vulnerable. Automated configuration scanning is the key to finding these types of errors, as no one really has the time to dedicate to reviewing every line of configuration code.

6. Focus on least-access principles - In an ideal world, everyone is 100 percent competent and honest, never making mistakes or contemplating wrongdoing.

In the real world, enforcing the least access privilege principle - limiting access to those who strictly need it - will allow for better access management by reducing the risk of errors, limiting the scope of damage, and strengthening security. For example, such a policy could have greatly reduced the damage caused at Sage, when a single employee from accounting went rogue. True, least access privilege may not be a sufficient solution and needs to be complemented by continuous monitoring, but it can be reinforced by:

• Eliminating administrator privileges on end-user machines
• Better securing of account credentials
• Monitoring privileged sessions to ensure proper usage
• Restricting developer access, unless they have a specific requirement
• Restricting access to production systems

Again, a technological solution exists. Privilege access management technology provides monitoring, auditing, and compliance enforcement. A good privilege access solution allows for easy assignment or denial on-the-fly, ensuring access on an as-needed basis only.

7. Fully and continuously secure your CI/CD pipeline - Shifting left is key. Security should start with the first line of code and not be left to QA or testing. Proactive security reduces the potential for issues across the entire SDLC – from preventing non-compliance and misconfiguration to limiting secret leakage and credential vulnerabilities.

Proactive and reactive security need to go hand-in-hand with every step of development, keeping everything agile while accelerating responsiveness. Security needs to be in the mind of every developer, and both new and old code need to be examined for potential vulnerabilities. The best way to start is simple - when writing new code, do it securely. When reviewing old code, look for issues.

8. Keep it simple - Automation is the quickest and easiest way to ensure security across the entire SDLC. Configuration inspection, secret scanners, identity access management, governance, compliance, masking, and synthetic data are all important solutions. The key is finding the combination that will maximize cloud security, minimize false positives, and keep quality code going out the door quickly and inexpensively.

The best solution is the simplest: Build a secure stack using the least number of tools delivering the highest level of security – and the lowest level of false positives. Unfortunately, getting there is rather complex. Many companies offer all-in-one tools or compatible suites that may simplify the process - but you can’t always count on that. As with all mammoth projects, the best approach is to take this one step at a time.

Never forget security on the cloud versus security of the cloud, although shared responsibility is rarely fully that. Check your service level agreements to find all the holes your cloud provider has left for you – and fill them.