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 7 delved into public cloud database activity monitoring. Part 8 below addresses the other side of monitoring—alerting.
What would any security program be without alerting? Serious threats need to be identified before they wreak havoc on your environment. Alerting enables teams to respond without delay. Yet, it’s easy for individuals to suffer from alert fatigue and dismiss or delay responses. This is why it’s so important that business units be able to filter out the noise and fine tune the alerting structure based on their environment and specific needs. This empowers you to focus notifications on what truly matters. In addition to crafting your own alerts, it’s also advisable to have out-of-the-box alerts that cover foundational security basics.
Establish and document your alerting process. Is it clear how alerts should be handled and who is responsible for what? Who is accountable? Documenting this minimizes confusion and creates a faster resolution route by streamlining the process. Make the process editable in real-time; the cloud is agile and teams need to match that agility with their own ability to pivot.
Pro tip: Don’t make it easy to ignore alerts (i.e., don’t use automatic rules or email filters that you can neglect). Set them up correctly and you won’t suffer from a barrage of inconsequential notifications.
When drawing up the alerting process, consider:
- Using custom tags
- How often the alert should run
- Who should receive the alert and the process they should follow when an alert is received, including relevant escalation policies
- How long to store the alert
- What to title the alert - it's especially helpful to enter a clear description of what the alert is checking for so it’s obvious what the alert policy is intended to raise awareness about
Not every misconfiguration or vulnerability has the same risk level. Not all data requires the same level of protection. Prioritize alerting based on the level of importance. Use tags and naming conventions to clearly convey groupings. At a minimum, every alert should include:
- A timestamp
- The status - e.g., if it’s open or has been closed
- The level of severity
- The policy the activity is evaluated against
- The activity that triggered the alert
- Who is responsible for addressing the notification
Be sure each alert and the action that was taken in response is recorded for compliance, audit and tracking purposes.
When it comes to evaluating alert tooling options, pay attention to alerting integrations and which software offers the integrations that will best fit your existing processes (e.g., slack, text, pagerduty, email, etc.). A centralized dashboard should consolidate alerts from across all databases by cloud provider and service. Consider the ease with which users can segment, categorize and search alerts. Searchability should come standard. To help subdue an ever expanding volume of security notifications, determine whether you are able to suppress nonessential alerts by using custom rules, tags or severity levels. Additionally, understand the potential for false positives and how they’re addressed.
Look for part 9 of this series where we review reporting recommendations.
Hack-Proof AWS Databases in the Public Cloud
✔ Stop attacks in their tracks with real-time Database Activity Monitoring
✔ Control vulnerabilities with the Security Violations Assessment
✔ Demonstrate on-going progress with dynamic Risk Assessment Scoring