Three ingredients for a top-notch threat detection program in the Cloud
Threat Detection in the Cloud
Threat detection is identifying and responding to security incidents to prevent or mitigate attacks and security breaches. A simple sentence, but one that is a significant undertaking to implement well. This post looks at three ingredients to impellent a top-notch threat detection program in your cloud environment.
Remember that building a threat detection program is not a linear process with a beginning and an end. It’s a circle; in each rotation, you will simplify, expand, speed up, enrich, automate, organize, reduce, or any number of verbs that improve your threat detection program. Start small and improve continuously.
First Ingredient: Know What to Detect
First thing first, you need to have an idea of what kinds of attack techniques you are going to detect first. Learning about potential attacks will help you prioritize the next two ingredients. Know where clouds are vulnerable, how attackers operate, what part of your environment is most at risk, and what attacks are favored in your business vertical. Public libraries have different threats than government contractors, which should drive prioritization.
One of the best reference materials on attack techniques is MITRE ATT&CK. ATT&CK is an organized and well-researched model describing attacker techniques, the attackers who used them, and general mitigation and detection overviews. Many companies that publish attack reports rely on MITRE ATT&CK as their primary reference material. Bookmark it.
Screenshot of the MITRE ATT&CK Framework
Several companies provide yearly reports on top attacks that can help with prioritization. For instance, Palo Alto’s Unit42 Threat Research, Red Canary’s Threat Detection Report, and Verizon’s Data Break Investigation Report provide good attack research.
At the beginning of your threat detection process, identifying the kinds of attacks to look for first will help prioritize the next section, getting telemetry.
Robust Telemetry Flow
We need data and a lot of it. Data flows from the data generation resource to our SIEM. That might mean bringing data from our cloud to our on-prem environment or from one cloud provider to another. Networks, data ingestion applications, SIEM collectors, and endpoint data generators all must be working in concert to get that data from point A to point B. In a purely on-prem environment, we may likely integrate multiple services to get this data. Host data from Sysmon, NetFlow from network traffic, and firewall logs are all separate systems that require data flows. Cloud providers try to simplify this by providing a single process for collecting and shipping data. Azure can ship logs to Storage Accounts and Log Analytic Workspaces with just a few clicks.
Telemetry flow diagram for AWS Security Hub
Telemetry describes logs, alerts, metrics, and any other data that might be needed.We can collect alerts from our posture management tools and workload protection tools such as AWS GuardDuty or Azure Sentinel. In your cloud environment, ensure you have turned on telemetry collection from all environments you intend to monitor and all regions where resources could be deployed. Ensure you monitor data flows into your SIEM and can detect if a flow stops. When the right data is consistently flowing, it’s time to do the fun stuff.
Effective Analytic and Alerting
We got the data into a central location, usually your SIEM; now it’s time to write analytics and do something with them. Your threat research will help you build out your initial detection. AWS and Azure have security and configuration compliance tools that can look for easy-to-spot problems, the low-hanging fruit. How you apply them is dictated by how uniform your environment is.
For instance, AWS and Azure can detect brute-force attacks against your external SSH services on hosts. But if all your systems are managed by internet-facing SSH servers, then brute force will happen. Combining an attack technique with configuration insight could increase the risk. Brute force against an SSH server is riskier if you use a username/password authentication.
A detection should then go into a ticketing or issue-tracking system. Analysts should be able to look at the alert, run follow on queries, gather details about the resources involved, and document and resolve. Track false positives, missed details, or improvements and feed them back into the beginning of the cycle.
Conclusion
Threat detection and detection engineering can take you past domains and file hashes to detect unusual behavior and advanced attacks. Thinking of it as a continuous process, building out a production-level system will ensure you can respond to newly deployed resources or new attack techniques.To learn about threat detection, monitoring, detection engineering, and the attacker’s techniques, check out my SANS class SEC541: Cloud Security Attacker Techniques, Monitoring, and Threat Detection.
About the Author
As a hands-on practitioner with a gift for architecture design, Shaun explores the good and bad of how the Cloud is changing the way the industry secures and runs infrastructure. During his 25+ years of experience, Shaun has spent equal parts in security engineer and operations as well as software development. With extensive experience within the Department of Defense, Shaun was the Technical Director of the Red and Blue operations teams, a researcher of advanced host analytics, and ran a threat intelligence focused open source platform based on MITRE ATT&CK. Previously, he was a consultant with H&A Security Solutions, focusing on analytic development, DevOps support, and security automation tooling. Shaun is co-author of SANS SEC541: Cloud Security Attacker Techniques, Monitoring, and Threat Detection. Read more about Shaun.
