Engineering Effective Data Security Alerts - Data Security Rules Explained Part 4
This blog post is the fourth in a four-part series that explains what we've found that works for creating actionable alerts for cloud data security. The first two parts explained the main ingredients - data classification, data context, and the engines behind rules and policies. The third blog addressed the regulatory compliance use case, specifically Payment Card Industry Data Security Standard (PCI DSS) compliance. In this blog post, I delve into how Open Raven combines data context, configurations, and other granular variables to generate customized and actionable alerts with appropriate prioritization.
Having worked in incident response and with multiple SOCs, I know firsthand how valuable it is for SOCs to know about potential sensitive data exposures due to misconfigurations before an attacker or paid red team service informs them the hard way.
Better Prioritization With Data Context
A SOC manager makes their way to the monthly project status meeting to discuss the types of incidents and requests that the SOC handles to make the company operate more securely. Compliance, risk, and security department heads regularly attend. It has been challenging for the SOC manager to provide metrics of an overall improvement to all of the company's various stakeholders because each has a slightly different perspective on what risk is.
Some of the most sought-after metrics in this meeting explain risks to the cloud environment and how company and customer data are protected. These metrics include the number of (likely) inadvertent cloud misconfigurations that come in as tickets to the SOC. When faced with multiple high-priority security initiatives, concerns, and hundreds or thousands of tickets, how does the SOC manager ensure that a ticket that could expose customer or employee data finds its way to the top of the queue to be handled?
This is precisely where having data context fits in. Open Raven combines critical information on data locations, types, and configurations to ensure that higher priority misconfigurations are raised to the top of the queue and handled first.
Creating Rules and Actionable Alerts
We use the concept of rules that pertain to cloud configurations and data to generate actionable alerts for SOC teams to handle proactively.
The Open Raven Data Security Platform includes default rules and the ability to develop custom rules to address environment-specific conditions. Rules are grouped together in policies and generate alerts when enabled. Rules can be written in either MySQL or Python, as shown below, and allow for a criticality to be selected:
Here are some of our top policies and alerts that our customers actively use today:
Data Security Fundamentals Policy
This policy alerts when personal (PII), health (PHI), financial (PCI), and developer secrets are unencrypted and/or public facing. Simple enough if you have any concerns about this type of data being exposed.
Regional Data Policy
This policy alerts upon discovering country-specific data classes in regions outside that country. For example, perhaps your Compliance team lead has asked you about GDPR compliance. This means you need to know if European customer data is maintained within the appropriate AWS regions. With Open Raven, you can quickly generate an alert on European customer data found outside of European regions by enabling the policy below.
AWS Ransomware Prevention Policy
This policy alerts on datastores that have the potential to be ransomed if an attacker decides to target your cloud environment.
As ransomware continues to have its sights focused on the data in the cloud, it makes sense for security teams to proactively search for this risk. The policy and its associated rules focus on several configuration values that must exist together to generate an alert. The image below shows a rule that checks AWS S3 buckets to determine if MFA delete and Versioning are disabled and if the bucket is publicly accessible.
True PII Violation Alerts
These alerts are customized to focus on any two or three data classes found within the same file that may constitute a PII violation. For example, a United States SSN, bank account number, and birthdate within the same file could violate PII data protection standards. Users can create other customized alerts that combine data classes based on company-specific needs.
Conclusion
Data context empowers SOC teams to pinpoint data security and compliance risk, prevent incidents, and streamline response. In this blog post, we've shown how Open Raven combines data context, configurations, and other granular variables to generate customized policies, rules, and actionable alerts with appropriate prioritization. I encourage you to explore all of the rules and policies that come with Open Raven to help you better answer how your company is doing with data security risk through actions and metrics.