2
Automated Security Operations and Incident Response Do it right from the outset by using automation from the offset, otherwise you will be drowning in alerts Are You Implementing a SIEM or SOC? In a large company the number of security events will be in millions per day sent to SOC. There is no way a human team can consume this much data. Fortunately most events sent to the SOC are not the result of a security breach, but are harmless activities. So the problem is to find the needles in this event haystack. The SIEM reduces the amount of data so that alerts are a magnitude smaller than numbers of events, but the SOC analyst is still confronted with a needle in the haystack. One issue is the high rate of false positives that SIEM rules trigger (all detectors have this problem) and tuning with tuned rules is a trade off with the danger of creating equally damaging false positives where we actually miss things. The Issue Analysing an alert is by no means a straightforward task. Alerts themselves have very little information content, yet the analyst has to answer questions such as; Who conducted the attack? What did they do or try to do? Why did they do it? When did they do it? Where did they attack? How did they go about it? Routine activities like patching, backups and testing may trigger SIEM alerts, this can create unnecessary additional SOC workload. Coordination is needed. SOC analysts can make or request changes regarding security tools, but may have little power to request changes or to request additional information from other IT or business operational areas. These factors delay investigations and add to the SOC workload backlog of open security cases. Challenges Facing SOC Investigations All tools, including SIEM, ticketing system, asset management, threat intelligence, and various integration tools, are weakly integrated. As a result, analysts spend a great deal of time going back and forth between the tools, cutting and pasting, with much of the analyst activity not logged or tracked, which makes it hard to recreate or replicate what a given analyst has done for future cases. Solution Disconnect Adding an automation layer into your SIEM and security monitoring is the only way to help your team understand the context of alerts, know who they need to liaise with, and enable them to scale to the demands of modern day security incidents.

Are You Implementing a SIEM or SOC? The Issuehoneycomb.co.uk/wp-content/data/datasheets... · The SIEM reduces the amount of data so that alerts are a magnitude smaller than numbers

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Are You Implementing a SIEM or SOC? The Issuehoneycomb.co.uk/wp-content/data/datasheets... · The SIEM reduces the amount of data so that alerts are a magnitude smaller than numbers

Automated Security Operations and Incident Response

Do it right from the outset by using automation from the offset, otherwise you will be drowning in alerts

Are You Implementing a SIEM or SOC?

In a large company the number of security events will be in millions per day sent to SOC. There is no way a human team can consume this much data.

Fortunately most events sent to the SOC are not the result of a security breach, but are harmless activities. So the problem is to find the needles in this event haystack.

The SIEM reduces the amount of data so that alerts are a magnitude smaller than numbers of events, but the SOC analyst is still confronted with a needle in the haystack.

One issue is the high rate of false positives that SIEM rules trigger (all detectors have this problem) and tuning with tuned rules is a trade off with the danger of creating equally damaging false positives where we actually miss things.

The Issue

Analysing an alert is by no means a straightforward task. Alerts themselves have very little information content, yet the analyst has to answer questions such as;

▪ Who conducted the attack? ▪ What did they do or try to do? ▪ Why did they do it? ▪ When did they do it? ▪ Where did they attack? ▪ How did they go about it?

Routine activities like patching, backups and testing may trigger SIEM alerts, this can create unnecessary additional SOC workload. Coordination is needed. SOC analysts can make or request changes regarding security tools, but may have little power to request changes or to request additional information from other IT or business operational areas. These factors delay investigations and add to the SOC workload backlog of open security cases.

Challenges Facing SOC Investigations

All tools, including SIEM, ticketing system, asset management, threat intelligence, and various integration tools, are weakly integrated.

As a result, analysts spend a great deal of time going back and forth between the tools, cutting and pasting, with much of the analyst activity not logged or tracked, which makes it hard to recreate or replicate what a given analyst has done for future cases.

Solution Disconnect

Adding an automation layer into your SIEM and security monitoring is the only way to help your team understand the context of alerts, know who they need to liaise with, and enable

them to scale to the demands of modern day security incidents.

Page 2: Are You Implementing a SIEM or SOC? The Issuehoneycomb.co.uk/wp-content/data/datasheets... · The SIEM reduces the amount of data so that alerts are a magnitude smaller than numbers

The SOCAutomation platform seamlessly plugs into all SIEMs and then rapidly adds the much needed context to incidents, making the security analysts job far ‘slicker’ by delivering knowledge to his/her fingertips.

The Solution

Once an analyst has this rich compendium of information, they can then quickly decide to escalate the alert to an incident. The automation delivers time saving to the SOC to get to this stage, which means the volume of alerts can all

be fully handled and increases the SOC’s processing power hugely.

SOCAutomation offers fully customisable dashboards, giving each user a personalised graphical representation of the data, as well as incidents and alerts relevant to them. Using a fully distributed and automated reporting engine, SOCAutomation is able to generate and deliver reports, graphs, tables, summaries, and statistics to any number of stakeholders.

Personnel from different areas of your organisation can receive specific reports relevant to their role via email, and reports are able to be automatically distributed to all stakeholders involved in an incident as soon as it is resolved. Some of the reports that can be generated are listed below:

▪ Incidents Handled by Severity ▪ Incident Response Timeliness ▪ Open Incidents ▪ Closed Incidents ▪ Incidents Utilising Most Resources ▪ Incidents Requiring Further Investigation ▪ Incident Handling Satisfaction

▪ Damage From an Incident ▪ Process Workflow ▪ General Mission Success ▪ Fire Drill Results ▪ Lessons Learned ▪ Incident Response Performance ▪ Incident Costs

KPIs and Reporting

SOCAutomation also suggests a proposed Run-Book to remediate an incident, the analyst can simply accept this or can customise it to suit.

These Run-Books contain step-by-step guides on how each user should best respond to incidents, and includes both manual and automated tasks.

Run-BooksA huge library of automation use cases, fully and easily customisable to fit specific security and IT environments and technologies. SOCAutomation’s advanced Automated Security Modelling can cater for any automation use case, and crucially includes a comprehensive set of common security use cases out-of-the-box.

Automated Security Modelling

Example Malware Run-Book

Example Phishing Campaign Use Case