Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/24/2018
02:00 PM
Liz Maida
Liz Maida
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Security Automation: Time to Start Thinking More Strategically

To benefit from automation, we need to review incident response processes to find the areas where security analysts can engage in more critical thought and problem-solving.

Automation is being hailed as a way to take some of the heavy lifting away from overworked security operations teams. Security vendors are integrating automation into their point solutions to automate tasks such as security policy orchestration, change and configuration management, incident response playbooks, and other labor-intensive tasks.

This is a good start toward solving some of the challenges of managing the modern security stack. But we need to think more strategically about automation if we're truly going to solve cybersecurity workforce challenges and gain any kind of edge over hackers.

Most automation takes place at the front end of the cycle: the detection and prioritization of security alerts. A combination of threat intelligence feeds, SIEMs, and incident response platforms generate event and incident data and perform some level of automation (correlation, orchestration, change management, etc.). This automation is helpful, but I hear, on average,  from security teams that they are only spending about 30% of their time on the front end of the cycle. It's what happens after a threat is detected, prioritized, and sent to the operations team that the real work begins.

In most organizations I've worked with, I see an estimated 40% of a team's resources being poured into manual investigation of incidents. This is often the most painstaking, lengthy part of the security life cycle. Analysts tasked with investigating and remediating security alerts often see more than 1,000 alerts per week from the more than 40 vendors deployed throughout their complex environment. The introduction of threat intelligence compounds this problem, as a single feed can generate more than 3.5 million indicators per month. Given the volume of data that must be evaluated and investigated, the average enterprise is ultimately throwing away more than 90% of its security data.

The remaining 30% of their time is focused on mitigation and reporting of the incident. These last two steps are the most important for learning from an incident and being better prepared for a future incident — yet most teams simply do not have the time or infrastructure to properly follow through on them. Once the lengthy investigation process is concluded, the results of that investigation are retained as independent, isolated reports. The technical details of the security incident are not stored or structured in a way that allows for automated correlations and are often missing the organizational context. Even when enterprises are creating their own indicators, they are manually maintaining lists of malicious IPs or domains in spreadsheets or text files rather than feeding those insights back into the system to be applied to future threats.

It's not enough to simply introduce automation. In order to extract the most benefit from automation, we need to holistically review incident response processes to find the areas where security analysts can engage in more critical thought and problem-solving.

Part of that means finding ways to automate the actual intelligence and do more of the analytical work in order to allow analysts to make quicker, more informed decisions. Beyond automating process elements, look for ways to automate correlation rules, historical analysis and coordinated communication between security devices. Intelligence automation will bring incident response to the next level. 

Related Content:

Liz Maida is instrumental in building and leading the company and its technology, which is founded on core elements of her graduate school research examining the application of graph theory to network interconnection. She was formerly a senior director at Akamai Technologies, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
aumickmanuela
50%
50%
aumickmanuela,
User Rank: Strategist
2/7/2018 | 10:01:42 AM
Thanks)
yeah, that is true) Great article, thanks a  lot for sharing)
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft Patches Windows Vuln Discovered by the NSA
Kelly Sheridan, Staff Editor, Dark Reading,  1/14/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Post a Comment
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.