DivvyCloud
By: Chris DeRamus
According to Gartner, most data breaches are attributed to misconfigurations and mistakes made by the Cloud Service Provider (CSP) customer, not due to vulnerabilities or failures in the underlying CSP. If CSPs like AWS, GCP, and Azure are doing their part, do organizations need to augment their current cloud security approach to better manage their data breach risk?
Leveraging CSP security controls is essential, and, for some cloud implementations, doing so is sufficient to manage this risk. But, for most enterprises, these controls alone do not adequately address the core aspects of cloud security: audit, visibility, protection, and detection. Aligning cloud complexity with organizational risk appetite is key to determining when and how to augment CSP security controls.
Because most data breaches are attributed to cloud misconfigurations, organizations must implement controls that quickly – and automatically – prevent or detect and remediate these issues. CSPs offer a plethora of security controls. For example, AWS provides dozens of different cloud security services, including GuardDuty, CloudTrail, and AWS Security Hub.
Secure cloud configuration must be a dynamic and continuous process. First, there is the configuration of the cloud environment (e.g., blocking SSH ports). Next, there is the configuration of the CSP security controls (e.g., enabling log monitoring and encryption). And, finally, security teams must address changes to settings (e.g., detecting and acting on a threat actor turning off logging to cover their tracks).
But which controls specifically detect and prevent misconfigurations? The answer is: it depends on the CSP provider and the cloud environment to which you are deploying the controls. And, while these controls play a primary role in securing cloud configurations, merely turning them on does not guarantee security.
Because each CSP has its own security services, individual CSP controls should be aligned with the pillars of cloud security: audit, visibility, protection, and detection. These pillars build on the NIST Cybersecurity Framework (NIST CSF). To augment the NIST CSF and better align it to cloud security, DivvyCloud by Rapid7 includes automation as a pillar. Automation is so central to cloud operations that there is a series of controls to monitor, track, and enforce automation functions.
For most enterprises today, the ideal way to normalize cloud risk is augmenting native CSP security controls with a unifying security control layer, like DivvyCloud. This unifying security control layer facilitates the right balance of audit, visibility, protection, detection, and automation as a basis for managing risk in the cloud. Similarly, organizations must balance protection and detection controls. Both are essential to blocking a data breach. However, heavy-handed protective controls can create friction by putting limits on developers. For example, instituting rules that prevent all SSH and RDP ports (blocking test and development access) versus a more nuanced rule set that prevents SSH and RDP ports within a specific context – for example, in production only.
DivvyCloud provides a unification layer to work in concert with underlying CSP security controls. By leveraging a resource model, DivvyCloud delivers universal monitoring and controls across all major CSPs and containers, allowing customers to achieve continuous security and compliance.
To read more on why CSP controls alone are not adequate to address the core aspects of cloud security check out our white paper, Augmenting Native Cloud Service Provider Security.