A Breach-Proof Public Cloud Database Security Program — Part 9: Reporting

    Sep 29, 2020 / by SecureCloudDB

    In this 10 part series, we review the key components that are needed to formulate and apply a consistent, regimented cloud database security program that helps ensure data is only available through authorized access. Part 8 addressed the other side of monitoringalerting. Part 9 below reviews reporting recommendations. 

    Today, it’s not enough for an organization to focus its efforts solely on passing an audit. Given the increased number of cloud databases an organization is responsible for, and their ability to spin up and down in a mere matter of days or weeks, achieving point-in-time compliance is only a fraction of what it takes to establish a strong security posture.  

    Organizations must understand all the security details they collect in order to prioritize actions based on level of severity, document the plan and verify changes. But with so much raw data coming from the cloud, it can be hard to process it, much less make sense of it. Yet, the key is transforming it into usable information. Again, this bears repeating: among the most difficult issues with cloud security is the availability of too much, rather than too little data.

    It’s very important to ensure actions within the database are recorded so that if (when) an attack occurs, it is possible to track down the source of the attack and the extent of the damage. Different database types have disparate auditing systems and logs. Some are more robust than others. Understanding the limits of each, what’s appropriate and necessary, and how to enable reporting is another complex task that requires deep understanding of each available option.

    Third party reporting capabilities solve the data collection and interpretation conundrum in addition to preparing organizations for audits. It’s imperative to understand how a security tool transforms your information into valuable reporting. Consider what intel would be of most value not only to you and your team, but also to other areas of the organization. We recommend looking for reporting that addresses:

    • Database security status, including a full violations history across all accounts
    • Data sovereignty - where databases and backups are located around the world, across all accounts
    • The organization's encryption posture 
    • Risk across services, accounts, and regions
    • Changes to your databases and backups
    • Database activity including most active users, most active databases, and activity details 
    • User privileges

    Ensure both a past and present perspective is provided via summary and detailed views so that the security posture can be easily communicated to both technical and non-technical stakeholders in a consistent, repeatable format. Automated reporting does the heavy lifting for you by distilling terabytes of information down to confirm what information is secure, establish where problem areas exist and turn issues into actionable items.

    Communication is critical to managing vulnerabilities. Reports should be shared with senior management and decision makers (as noted, this may also help with security training). Look for tooling that allows you to share reports with the click of a button.

    Read part 10 of this series where we provide considerations for selecting security service providers and conclude the series.


    SCDB - InfoSec Ad 1.15.20


    Begin Your Free 14 Day Trial Now



    Tags: Security Program Series

    Written by SecureCloudDB