2019 Data Breaches: On Track to Be the Worst Year Consumer privacy (or the lack thereof) is a huge societal concern and concerns about protecting privacy is manifesting itself through many forms, including regulation like the California Consumer Privacy Act and...
Feature Release 19.3: Secure S3 Buckets, Microsoft Teams, & Compliance Heat Map We are excited to announce our newest release of 2019 which continues our mission to help you effectively leverage CSP security and management tools like AWS’ “GET BucketPolicyStatus”...
Government Institutions Risk Data Breaches by Avoiding Cloud Security Automation DivvyCloud co-founder and CTO, Chris DeRamus, recently published an article with HomelandSecurityToday.us on why cloud automation is the antidote for government agencies plagued by...
Guardrails to Innovate and Stay 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.
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:
- 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.
- 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.
- 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.
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 above mentioned common practices by developers can quickly create the nightmare Marriott and countless other companies are currently dealing with.
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:
…to continue reading the rest of our article, go to BetaNews.
Watch DivvyCloud’s 60 second video to learn how we help customers like GE, 3M, Autodesk, Discovery, and Fannie Mae stay secure and compliant.
DivvyCloud minimizes security and compliance risk by providing virtual guardrails for security, compliance, and governance to customers embracing the dynamic, self-service nature of public cloud, and container infrastructure. Customers like General Electric, Discovery Communications, and Fannie Mae run DivvyCloud’s software to achieve continuous security governance in cloud and container environments (AWS, Azure, GCP, Alibaba, and Kubernetes). First, our software performs real-time, continuous discovery of infrastructure resources allowing customers to identify risks and threats. Second, customers can implement out-of-the-box or custom cloud-native policy guardrails that identify and alert on violations. Third, we automate the enforcement and remediation of these policies.