Detection & Response - Alert Deployment and Tuning

A critical component of a detection and response security program are the alerts, often stemming from SIEM (Security Information and Event Management). Some common types of SIEM alerts include:

1. Intrusion Detection: Alerts generated when an intrusion is detected, such as a successful login from a suspicious IP address.
2. Data Loss Prevention: Alerts generated when sensitive data is detected leaving the network, such as credit card numbers or confidential documents.
3. Malware Detection: Alerts generated when malware is detected on the network, such as a virus or ransomware attack.
4. Anomaly Detection: Alerts generated when unusual activity is detected, such as an unusual increase in network traffic.

While it is fairly straightforward to add all conceivable log sources to a SIEM and enable all possible alerts, doing so is not desirable as it costs a lot of compute, money and stress to the person analyzing alerts aka "Alert Fatigue". Instead there are frameworks and processes to ensure a good coverage of alerts, including continues maintenance or "tuning".

Proactive Alert Deployment

Proactive deployment refers to the initialization of SIEM alerts without any knowledge of current operations. This includes:

1. Best Practices: Vendor and system documentation, such as the "best security practice" section in the MongoDB documentation. Alerts should be deployed with this documentation in mind. Think "how can I detect and mitigate if my system is not configured according to the best practices"? This means the entire stack, including the cloud vendor security best practices and recommended logging.
2. Standards: Following the NIST - 800, ISO 27001, CMMI, OWASP or similar standards and deploy coverage for possible violations of these standards.
3. Guidelines: Follow benchmarks and guidelines such as CIS to deploy checklist checks across your environment.
4. Frameworks: Finally, use a framework like MITRE ATT&CK and Cyber Kill Chain to orient your logs toward defense in depth. Focus on log collection for different kill chain stages before adding multiple sources to the same "depth". Broad coverage is better than deep coverage and deep coverage comes with maturity.

Retroactive Alert Deployment

Retroactive deployment refers to all knowledge obtained through current operations. This includes:

1. Incidents: Current and past incident briefings should uncover additional log deployment or tuning.
2. Red-Team and probing: Table-top exercises, Red Team as well as Blue Team work and knowledge should help uncover gaps in log collection.
3. Threat Hunts: Intelligence, threat hunts and outside information can also be used to inform new logs or tune existing ones.

Tuning

Tuning logs is the process of minimizing false positives, eliminating false negatives and increasing true positive accuracy. First and most importantly, a mechanism to communicate, document and measure outcomes for log tuning must exists. Then:

1. Correlate and Normalize: Correlate activity between systems based on time, source, destination, session and other identifying information.  Normalize fields, data types and events by formatting them into a common standard.
2. Data Enrichment: Use secondary sources to enrich data to make it more useful, such as Open Source Intelligence (OSINT), tools, integrations or lists. For example, add user VIP data or IP address lookups where useful.
3. Thresholds and Baselines: Use data science to help filter logs, such as statistical anomalies in volume, velocity and variety.
4. Machine Learning: Train and continuously improve a model based on your data. Be careful not to over-fit the model and account for low accuracy fail saves.
5. Testing: Comprehensive testing of log sources can reveal tuning requirements. In high maturity environments this testing can be automated.