When it comes to cloud infrastructure security, two trends emerged in a big way in 2019: headline-producing cloud-native exploits, and the developer movement to address these threats using secure engineering approaches.
On January 1, 2020, the California Consumer Privacy Act (CCPA), California’s answer to GDPR, goes into effect. Like GDPR, the CCPA is delivering anxiety and dread to executives, marketers, compliance officers, and engineers everywhere. As we learned from numerous conversations at the AWS re:Invent 2019 conference last week, engineers responsible for building and managing cloud-based systems and data are focused on CCPA and what it means.
Today, we announced Fugue Developer, a free tier designed for individual engineers to build and maintain secure cloud infrastructure in highly dynamic and regulated cloud environments. Get started here and you'll have a visualization of your AWS or Azure environment in minutes.
Adopting the Rego policy language and the Open Policy Agent (OPA) engine for Fugue’s cloud security SaaS product has paid real dividends for us and our customers. It enables Fugue users to easily create custom policies for their cloud infrastructure environments using open source tools, and it’s helped us implement out-of-the-box policy as code support for complex compliance standards, including CIS Foundations Benchmarks, GDPR, HIPAA, ISO 27001, NIST 800-53, PCI, and SOC 2 (and our own Fugue Best Practices to identify advanced cloud misconfiguration risks).
Most organizations now recognize the importance of cloud security, likely due in large part to the sharp uptick in cloud-based data breaches resulting from cloud misconfiguration. Achieving and maintaining the secure configuration of their cloud infrastructure resources—sometimes referred to as Cloud Security Posture Management (CSPM)—is now a priority for most cloud engineering teams.
Today we released the Fugue Best Practices Framework to help software engineering teams identify and remediate the kinds of dangerous cloud resource misconfigurations used in recent data breaches that aren’t addressed by common compliance frameworks (see A Technical Analysis of the Capital One Cloud Misconfiguration Breach).
Cloud computing platforms like Microsoft Azure and Amazon Web Services (AWS) are powerful because we can program them to respond to our application requirements automatically. Engineers can innovate really fast, spinning resources up and down on demand, and we only pay for what we use.
Just like the challenges of managing large cloud infrastructure operations led to the development of infrastructure as code, ensuring the security and compliance of those environments led to policy as code. Cloud infrastructure environments are simply too vast, complex and dynamic to address with traditional security approaches such as manual audits and checklists.
One aspect of cloud computing platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) is that it’s easier to create infrastructure resources than it is to destroy them. Even more challenging is maintaining full visibility over all of your cloud resources. Corey Quinn once said, and I’m paraphrasing, “the only way to see everything you have running in your AWS account is to look at your AWS bill.”
Cloud misconfiguration is the number one cause of data breaches involving public cloud services such as those offered by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. According to Neil MacDonald at Gartner, “nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement and mistakes.”