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.

Sas3
  • 2,638
  • 9
  • 20
  • 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 https://www.phantom.us/ for example – schroeder Jun 19 '17 at 10:36
  • @schroeder Thanks, I appreciate your input. I started with the curiosity to know what people who have matured processes are doing - but am also curious to look at what's possible - even if those are, as you say subjective and/or applicable only under certain circumstances. The objective for me is to compile a list of possibilities - and start working down the list to do as much of it as possible. – Sas3 Jun 19 '17 at 11:23
  • 1
    Asking for lists is really not a great fit for StackExchange – schroeder Jun 19 '17 at 11:27
  • @schroeder Ok, so what's the right thing to do now with this question? Close it somehow, esp., if that's what your SOP requires you to do? Suitability for SE aside, I am thankful for the responses. Both the answers so far, as well as your comment mentioning phantom.us have been helpful. – Sas3 Jun 19 '17 at 11:49
  • I'll remove the bounty and close the question. – schroeder Jun 19 '17 at 12:02
  • 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
  • See the paper -- High-Benefit/Low-Regret Automated Actions as Common Practice -- https://static1.squarespace.com/static/5a94b67ff93fd440f0516297/t/5b71d9a8758d46e4065d01e3/1534187945107/Low_Regret_Automated_Response_072018.pdf – atdre Aug 13 '19 at 22:19
  • John Hopkins used data science to kick off the IACD Automate program. You can make decision making in automation non-subjectively. I think that @schroeder is incorrect in his assessment. Also: his vendor pitches did not add value to this conversation. – atdre Aug 13 '19 at 22:20
  • @atdre "pitches"? The product examples were provided as a source of the lists requested. The question is asking for lists of stuff. Twice. It is rightfully closed for this reason. The ideas in the John Hopkins paper are very useful, if not obvious, but would not stand as an answer to this question. – schroeder Aug 14 '19 at 06:42
  • @atdre I'll repeat my comment above: "it's a hard thing when the question is not a good fit, but it triggered something useful". – schroeder Aug 14 '19 at 06:47
  • @schroeder : maybe we can find a place to discuss these important topics? – atdre Aug 14 '19 at 14:46
  • @atdre absolutely, and as a Q&A site, we are driven by questions. Post one. – schroeder Aug 14 '19 at 15:53

2 Answers2

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.

TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
  • 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: https://www.peerlyst.com/posts/how-to-build-and-run-a-soc-for-incident-response-and-enterprise-defensibility-a-collection-of-resources – 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.

mgjk
  • 7,535
  • 2
  • 20
  • 34