Threat Intelligence
10/14/2014
02:00 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Mastering Security Analytics

Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?

Today's enterprise security tools have developed an ability to detect a plethora of anomalies and "events" that indicate an attack is underway. For most companies, the problem is interpreting all of that security data to identify sophisticated threats and eliminate them before a serious data loss occurs.

"We're sort of living in this alert-driven culture, but no one has the resources to respond to every alert," says Dmitri Alperovitch, co-founder and CTO of CrowdStrike, a security intelligence and analytics firm. "There are a lot of false positives, so not every alert is going to be prioritized."

Innovations within security software, appliances, and services have automated many detection and blocking tasks, resulting in improved protection from next-generation firewalls and intrusion-prevention systems. But no matter how advanced a tool is, it will never block 100% of attacks.

That's why, even with so much sophisticated technology available today, brainpower remains the most effective tool in fighting advanced attacks. Smart analysts can connect the dots among different security alerts and logs, letting analysts hunt down and shut down the sneakiest of exploits. But as security data proliferates, these analysts are being snowed under.

Even the most highly skilled analysts can only sift through so much data per day before they become ineffective. What's more, there are only so many analysts out there -- and they don't come cheap.

For most companies, then, it's not just a matter of hiring more analysts. "It's all about how do you maximize the efficiency of your human analysts -- how you present them with the information that's most relevant to them and most actionable," Alperovitch says.

To do that, IT organizations must rethink the factors that drive their security intelligence and analysis. They need to find ways to digest data more efficiently and automate some of the easier correlations among data sets so that analysts have more time to focus on the complex ones.

There are a number of ways to improve data analysis, and much of it revolves around providing data in better context, automating data flows and mathematical analyses, and improving the way data is presented to humans when it's decision-making time.

The trouble with SIEM
Anyone who has been in IT security for a little while might stop at this point and ask, "Wait, isn't data analysis what security information and event management (SIEM) systems are for?"

When SIEM technology kicked off over a decade ago, the promise was that these platforms would become the catch-all system for storing and correlating security data across the enterprise to help analysts stop attacks in their tracks. But that was a time when the corporate attack surface was fairly limited, and the volume of attacks was still manageable. Many of these SIEM systems had a pedigree in log management, and their underlying architecture was built in a time long before the nonrelational database revolutionized big data analysis. As a result, SIEM has a number of weaknesses that keep it from being an analytical superstar.

First, many SIEM platforms still can't pull in all of the necessary feeds to track attacks across the typical attack life cycle, or kill chain, which often spans endpoints, network resources, databases, and so on. Even when they can ingest data from, say, endpoint security systems, they are often unable to normalize it (meaning get the data sets into roughly the same format) and pair it with related network security data that could help analysts correlate separate events into a single attack.

"The challenge is you have endpoint systems that don't talk to log data and don't talk to network data," says Craig Carpenter of AccessData, a forensics and incident response vendor. "It may all be sitting in the SIEM, but it's not being correlated. It's not being translated into a singular language that the analyst can actually look at."

In most cases, Carpenter adds, you'll have two different teams looking at the data: the network team and the endpoint team. 

"And the two alerts don't match to each other, so they look like completely different events to the analysts," he says.

As the number of security data feeds increases with more specialized services and products -- be they phishing and malware detection or external threat intelligence data -- it only gets harder to map out a single attack across all of the different infrastructure touch points. It's a case of too many alerts with little to no context.

"There's no prioritization," explains Alperovitch. "So it's easy to say with hindsight that they should have connected the dots because there was one alert, but if there's 5 million dots for you to connect, then it's really, really hard for any organization to make sense of it all."

For example, prior to its breach, the retailer Target did get an alert from its security tool, but it was lost in the noise of many other alerts coming in at a rate of hundreds a day.

To read the rest of this story, download the latest issue of
Dark Reading Tech Digest
(registration required).

 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
jimmyblake
50%
50%
jimmyblake,
User Rank: Apprentice
11/3/2014 | 11:22:25 AM
Re: Mastering Security Analytics
"...SIEM platforms still can't pull in all of the necessary feeds to track attacks across the typical attack life cycle, or kill chain, which often spans endpoints, network resources, databases, and so on..." - if so you've not the wrong SIEM platform or Use Cases, normally the latter.

I'm continually frustrated by working with companies who model use cases from available, and easy to get hold of, event sources rather than considering the intent, tools, techniques and procedures that the attacker will use (which is what you're trying to detect).  In these bottom-up cases, you end up modelling your defences in use cases, not what the attacker is doing.  These same companies are now shouting from the hilltop that SIEM is broken, but they're now going to invest heavily in analytics and fail again because the problem isn't the tool - it's the approach.

An efficient and effective SIEM platform should model the full extent of an attack-chain (we use 10 different stages in our methodology) and absolutely should include traditional infosec technical controls, network, database, endpoints - but also user profiles & permissions and applications.  If your SIEM can't handle these - your chosen SIEM platform - not SIEM itself - is the problem.  A good security operations capability should b eable to do everything mentioned here, with the right processes and skills to develop good attack-chain based use cases, to triage and tune rules continually, to product meaningful management information broken down by line-of-business and to report on the effectiveness of security controls across the business. 

The problem with Target, as you point out, was false positives.  Did Target have the right SLAs in place with their MSSP around false positives?  Did they have a defined process to continually refine content with the service provider to reduce false positives?  Did they select the service provide with the right service catalog and skills to effectively detect, prioritise and investigate incidents - or did they simply through the monitoring problem over the shelf at a third party who'd provide the service at the cheapest possible cost?  None of these problems are SIEM related, their process and governance related.

You should also build your rules to offer staged correlation that can capture possible indicators of compromise that can be used as the starting point for exploratory analytics - SIEM, analytics and visulation coupled with good profiling of your threats into use cases is the solution, not replacing one set of SIEM blinky lights with another set of analytics blinky lights.  

I'm coming across so many companies that haven't done the basics with regard business alignment, people and process around their SIEM platforms that are now looking to replace them with analytics platforms, and they won't do the right  business alignment, people and process there either -  business alignment, people and process is hard, buying a product isn't.
JasonSachowski
50%
50%
JasonSachowski,
User Rank: Author
10/15/2014 | 7:28:38 AM
Re: Mastering Security Analytics
Nice article @ErickaChickowski. As you've clearly outlined throughout, there are a few pain points: volume, prioritization, and resources (both people and technology). I agree that if we continue "living in this alert-driven culture", we will never get out heads above water; regardless of how many responders are at our disposal.
Hacked IV Pumps and Digital Smart Pens Can Lead to Data Breaches
Dawn Kawamoto, Associate Editor, Dark Reading,  12/4/2017
Tips for Writing Better Infosec Job Descriptions
Kelly Sheridan, Associate Editor, Dark Reading,  12/4/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Managing Cyber-Risk
An online breach could have a huge impact on your organization. Here are some strategies for measuring and managing that risk.
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.