Incident Responders: Can you give some examples of Incidents / types of incidents that are suitable for fully or partly automated response? [closed]

Question

You setup security monitoring - either a full commercial SIEM/SOC or something home-cooked (e.g., rsyslog -> OSSIM / MozDef / Splunk / ...). You also setup some rules so that some event triage is done - and you only get alerts for potential Incidents.

I'd like to know what automation is being done beyond this point. Not just more alerting / sending emails or reports - but something that attempts to resolve the incident itself.

Some use cases and some examples of automation solutions (whether standard or DIY) would be helpful.

Answer 1

Of the top of my head I wouldn’t say anything. The point of a SoC/SIEM is to bring things to the attention of a human analyst in order to evaluate the incident and decide on what actions to do next. Anything you don’t want a human to get “eyes on” should be tuned out of the SIEMs rule set.

There might be certain low risk things you want to automate, for example every time there is an AV hit with the malware being quarantined or deleted a ticket is raised to have the box rescanned while the analyst carries out the initial investigation, but typically this wouldn’t be done by the SIEM. (Although some SIEMs will have this capability and some SoC will use a SIEM to do this.)

A mature SoC will typically have a playbook for common alerts that are not tuned out. For example if x happens then do a, b, c, then escalate to a level two analyst for further investigation. This is more about having a standard operating procedure than automation.

Answer 2

Active responses such as dropping and ignoring requests are the only kind of automated response I've engaged in.

Any commercial IPS or Web Application Firewall does this. HIDS/HIPS can be considered too, for extremely small deployments.

Simple WAF rules might block the attacker for a limited time if:

• If the User-Agent is wget or curl or similar automation
• If somebody tries a known, specific, well-defined exploit
• If somebody tries a well-defined category of exploit: directory traversal, SQL injection,

The WAF can be tuned to include blocks for things like:

• requests for pages which indicate a technology you don't have (e.g, aspx)
• requests for common administrative pages /admin.php

IPSes can also do this but are less precise in their signatures as they tend not to provide information on the http protocol, but raw packets instead. This does give them some extra abilities such as detecting attacks on the WAF or proxy itself, or non-HTTP/HTTPs attacks.

These kinds of responses are normally limited to high-confidence signatures. Commercial vendors tend to include confidence factors in their signature information and allow you to limit blocks accordingly.

Snort, McAfee Intrushield, IBM SiteProtector are IPSes which I've used to to this. F5's ASM I've used for WAF responses. fail2ban, OSSSEC, on the HIDS side.

http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node26.html

http://ossec-docs.readthedocs.io/en/latest/manual/ar/

Automated blocks are reviewed daily and monitored in real-time. The risk of a signature impacting production is very real. Signatures are deployed on a Dev/Stage/Prod cycle so that new signatures don't reach production without a full test cycle.