Providing guardrails for developers to innovate while staying secure in the cloud

Enterprise cloud adoption has largely been driven by developers eager to take advantage of its agility. These developers are often moving very quickly and are under pressure to bring new products to market that provide competitive advantages. The speed of development combined with a lack of cloud security expertise often results in engineers and developers bypassing certain security and compliance policies. The result is a chaotic, "Wild, Wild West" cloud environment.

Alongside innovative apps and services, a common byproduct of this "free for all" mentality is data breaches, thanks to misconfigurations and other security glitches. This article shares advice on how organizations can empower their developers and engineers by providing a safe framework within which to operate, so they can stay agile and innovative, without inadvertently compromising security.

Bad Habits

First, let’s look at the common practices of developers and engineers that lead to security lapses. Whether it’s lingering habits from working in traditional environments or newly-formed habits created out of convenience in the world of self-service cloud access, developers can inadvertently create serious security issues. Examples include:

1. Least-privileged access. Developers often start a project using completely open access, with the intention of going back and scoping privileges after the fact. The problem is, they end up forgetting to go back and scope once the project is completed, leaving databases and storage containers holding highly sensitive information wide open.
2. Working Remote. Developers often open up Secure Shell (SSH) or disable firewalls to gain access to a system they’re working on remotely, leaving the system open and vulnerable. Similarly, developers may pull a database containing sensitive information for testing purposes and because it’s not "live" they think it’s just a development system. Instead, they end up exposing an inactive database full of sensitive customer information.
3. Sharing is (not always) caring. A common scenario in enterprises is when one developer spins up a cloud service and is experimenting with it, and a colleague also wants to experiment with it. During this experimentation, the second developer makes it publicly available without knowing the first developer pointed it toward a database containing sensitive information. Now, the company has a massive data breach on its hands.

Devastating Impacts

Allowing the "Wild, Wild West" to continue has devastating impacts on enterprises. Data breaches can result in loss of user trust, damage to brand reputation, lawsuits and fines levied against the company from data privacy regulations, decreased stock price and lower revenue. As just one example, Marriott could face a maximum fine up to $915 million under GDPR for its massive data breach disclosed late last year. And that’s just under one regulation -- once all is said and done, this breach could easily cost Marriott billions of dollars.

Companies that go on thinking this kind of incident couldn’t happen to them are living in a dream world. Any of the abovementioned common practices by developers can quickly create the nightmare Marriott and countless other companies are currently dealing with.

Establishing Guardrails

As scary as the potential consequences of suffering a security or compliance glitch are, shutting down self-service access to the cloud is not the solution. The cloud offers huge benefits for companies looking to get (or stay) ahead of their competitors, and developers being able to spin up new services quickly is key. To allow developers the freedom to innovate without sacrificing security and compliance, enterprises should establish (and enforce!) the following policies:

1. Never experiment with live data in a cloud service.
2. Always use least privilege access and scope it from the beginning of a project -- never skip this step with the intent of going back and scoping later. By then, it could be too late.
3. Always encrypt data.
4. Never, even temporarily, expose cloud services for testing purposes.
5. Never reuse a cloud service that was left unfinished. You don’t know what databases it may point to, and it’s simply not worth the risk.
6. Leverage advanced identity and access management controls as the new perimeter. In today’s world, the only barrier standing between a user and access to applications or sensitive data is the identity of that user. Therefore, advanced IAM solutions are essential.
7. Leverage appropriate native cloud security tools (i.e. CloudWatch, AWS CloudTrail, Shield, Amazon Inspector, AWS Macie, etc.). Many of these tools are highly effective and easy to implement—a no-brainer when it comes to adding extra layers of security.
8. Establish a Q&A process for developers to ensure proper steps have been taken (i.e., is the service bug-free? Has it been run through Macie and Inspector?). This Q&A (or checklist) document will look different for each company, but its purpose is to ensure developers have followed all proper security and compliance considerations.
9. Enforce the above best practices with an automated cloud security and compliance solution. Even with the best intentions, developers could still miss a critical step. Automated cloud security and compliance solutions can detect a misconfiguration or policy violation in real time, and either alert that developer to the issue that needs correction or automatically take the necessary remediation actions.

The world has moved from "command and control" to "trust, but verify." Enterprises can’t put too many roadblocks in the way of their developers, or they will get frustrated and bypass all security and compliance considerations. Developers must be educated on what they can and can’t do in order to keep their organization safe from data breaches and need a system to verify they’re following appropriate protocols and policies. Human error means that inevitably, every company will have a situation in which a mistake is made and data is left vulnerable. Whether a company finds and fixes the mistake themselves, or leaves it for a hacker to find and exploit, can mean the difference between a company’s success and failure.

Image credit: Wavebreakmedia/depositphotos.com

Chris DeRamus is CTO and co-founder, DivvyCloud. He leads DivvyCloud’s technology team and product development and is dedicated to building the most robust, scalable, high-quality software possible to meet our customers’ demanding requirements.