5

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.

closed as too broad by schroeder Jun 19 '17 at 12:02

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • this is really subjective - how you respond to an incident is completely dependent on how you assign and want to mitigate risks and the tech you have available – schroeder Jun 19 '17 at 10:33
  • theoretically, you can automate anything - I'm afraid any answers will be a long list of possible things - which is not a great fit for a question format here – schroeder Jun 19 '17 at 10:33
  • 1
    if you are looking for possibilities, just look at the growing 'orchestration' market: FireEye Security Orchestrator, and phantom.us for example – schroeder Jun 19 '17 at 10:36
  • 1
    Asking for lists is really not a great fit for StackExchange – schroeder Jun 19 '17 at 11:27
  • 1
    it's a hard thing when the question is not a good fit, but it triggered something useful - just know that a closed question is not a personal attack and all part of the SOP – schroeder Jun 19 '17 at 12:03
3

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.

  • 1
    Agreed, you automate once the playbook becomes routine and you have a good understanding of the risks involved – schroeder Jun 19 '17 at 10:34
  • @thejulyplot Thanks. Could you give a few use cases / examples that you have automated from your playbook - or have considered automating, after watching them for a while? – Sas3 Jun 19 '17 at 11:26
  • 1
    @Sas3 That is very hard to give specific examples as there are a lot of variables in play. Have a look at this link, lots of good resources: peerlyst.com/posts/… – TheJulyPlot Jun 19 '17 at 11:54
3

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.