In episode 44 of The Cyber5, we are joined by Ronald Eddings. Ron is a Security Engineer and Architect for Marqeta, host of Hacker Valley Studio podcast, and a cybersecurity expert and blogger have earned him a reputation as a trusted industry leader. In this episode, we discuss the fundamentals of automating threat intelligence. We focus on the automation and analysis of forensic artifacts such as indicators of compromise and actual attacker behaviors within an environment. We also discuss metrics that matter when the objective is to show progress for a security engineering program.
Here are the 5 Topics We Cover in This Episode:
1)Define the Use Cases: (01:19 – 04:17)
For a mature security team, the automation of cyber threat intelligence should start with defining use cases. An enterprise should ask, “What problems am I trying to solve?” Detecting malicious binaries on devices is a good place. For example, let’s start with a problem that plagues all organizations: phishing. Creating an inbox for phishing emails is a good first step. Then, an organization needs to make a decision whether to automate the extraction of file hashes, URLs, and IPs for analysis or to direct employees not to click on the link or open the file.
2) Storage and Logging Components that Need to be In Place:(04:17 – 06:59)
For security engineering to be effective, data must be available. Security engineers should define a data acquisition strategy by eliciting stakeholder requirements and assessing your collection plan. The right data is often spread across multiple tools and systems. This must be consolidated into one location for automation to be effective. For example, if an organization wants to detect lateral movement from an Advanced Persistent Threat and is only storing a month of Windows event logs, success is unlikely.
To be effective, the following logging should be in place:
- Windows event logs
- Netflow (which can be expensive)
- Cloud logs
- EDR logs from endpoint devices
- VPN and RDP logs
3) Prioritizing MITRE ATT&CK in Security Engineering: (06:59 – 10:12)
When beginning a program, security engineering should resist the temptation to automate APT groups. Instead, they should automate alerts in the reconnaissance stages within MITRE ATT&CK and then work down the cyber kill chain towards exfiltration. Reconnaissance stages are easier to automate and by the time an attack escalates to the lateral movement stage, automation will facilitate and speed human analysis.
4) Security Orchestration and Automated Response (SOAR):(10:12 – 12:00)
Python and Go are helpful languages to learn in the SOAR process and useful with incident response.
5) Useful Metrics and What Cannot be Automated in Security Engineering: (12:00 – 19:00)
Mean time to detection, response, and remediation are critical metrics for security engineers to measure. Case management systems such as JIRA can facilitate interaction between the security team roles, including SOC, Incident Response, Security Engineering, Threat Hunt, Threat Intel, Vulnerability Management, Application Security, Business Units, and Red Team. Identifying new threats and understanding why a threat occurred is almost impossible to automate and will always require analysis.