There is a lot of talk about DevSecOps these days, and we've been working in the area for years now and have learned some things that work and some that don't. First, we'll give you our view on what DevSecOps is, and then we'll make a few recommendations on how to start doing it and get real results in an hour or two!
A lot of folks have realized that manually fixing cloud infrastructure to correct security and compliance issues is just too slow and error prone to handle the threat landscape on the cloud. An increasingly common approach to speeding up remediation these days is to use cloud functions, such as AWS Lambda or Azure Functions, connected to a threat detection tool, to remediate specific cloud misconfigurations.
All humans make mistakes and some of those mistakes could lead to security breaches. According to Gartner, through 2023 at least 99% of cloud security failures will be the customer’s fault. Many of these successful cyber-attacks will be a result of hackers preying on the vulnerabilities of human weakness to successfully gain access to an organization’s infrastructure and networks wreaking havoc and damage.
Infrastructure misconfiguration is the leading cause of data breaches in the cloud, and a big reason misconfiguration happens is infrastructure configuration “drift,” or change that occurs in a cloud environment post-provisioning. If you’re responsible for the security and compliance of cloud environments, you probably spend a lot of time focused on analyzing infrastructure drift events and remediating them. It’s easy to think of all drift as being bad or undesirable. And make no mistake, some of it is really bad. Ugly even! But some drift is good and desired, and understanding the differences between the good, the bad, and the ugly--and how to recognize them--can save you and your team a lot of frustration and wasted time.
In last week’s blog we discussed the Shared Responsibility Model and how it affects enterprises’ cloud security. Based on the Shared Responsibility Model, organizations are responsible for security in the cloud, which includes how they configure and use the resources provided by the cloud service providers. Falling within this realm are cloud resource configurations. Cloud configurations are complex and if not implemented correctly, can increase the risk of a data breach.
Security and compliance are priorities for companies in the cloud. However, cloud security and compliance is not the responsibility of any single entity alone and determining the demarcation line can lead to confusion. Security and compliance in the cloud is a shared responsibility between the cloud service providers (CSP) and their customers.
Whenever there's talk of the cloud, misconfiguration and the security risk it brings inevitably becomes a part of the conversation. And of course, once you start talking about cloud misconfiguration, “auto-remediation” often creeps into the conversation. But what does “auto-remediation” really mean? The concept of “auto-remediation” is that the solution finds problems or policy violations in your cloud infrastructure and automatically fixes them.
As organizations adopt cloud technology to modernize their businesses and increase agility, employing security automation to identify and correct cloud infrastructure misconfiguration has become a necessity. Cloud misconfiguration is one of the most common and significant security risks facing organizations today, yet it is also preventable.
Yesterday, we showed you how you can use Fugue to scan your AWS infrastructure, discover what resources you have running, and identify any policy violations for compliance frameworks like HIPAA, GDPR, NIST 800-53, and the AWS CIS Benchmarks.
This week at AWS re:Invent 2018, we announced that our new SaaS solution for cloud infrastructure security and compliance enforcement, is now available. Get it here.