John Pescatore recently joined the SANS Institute as the Director of Emerging Security Trends. His entire 30+ year career has focused on IT security, which gives him a pretty interesting perspective on where we’ve been and where we’re headed. I talked to him recently about what’s on the horizon for IT security.
Linda: John, what are you looking at in terms of emerging security trends?
John Pescatore: Earlier this year SANS had a Cyber Threat Intelligence event. Since then we have started to focus on security analytics. It’s this space between having lots of event information about our computing environments and making use of that information to deal with immediate threats.
Here’s an example of that gap we have to fill. The Navy was one of the early buyers of SIEM technology. They also were using statistical analysis software from SAS, which was really the precursor for big data. They said, “Let’s plug these two together and maybe big data can find all the security incidents and the potential security attacks we’re not finding.” They sat the two sides together in a room and the SAS people said, “Tell us what you want to look for,” and the SIEM people said “No, you just tell us what you find.” That dialogue happens a lot and it captures the missing part in the middle which is security analytics. The question is, how do we tell the tools what types of things to look for that are indicative of security threats or indicative of vulnerabilities where we are vulnerable to threats that are out there?
If we could have thousands of security analysts to pore over SIEM data, they’d be looking for indicators of compromise, or they’d look for the way attackers start to do things that later on leads to threats. We need to capture the analysts’ knowledge in some automated way to feed the various tools that can pull events from servers and firewalls and IPS really quickly and plow through large amounts of data really quickly.
Linda: In other words, getting information from the SIEM that is immediately and automatically actionable with other security devices.
John Pescatore: Exactly. Security analytics is not just some sort of PhD experiment to see how much stuff you can look at and what you can find. The second key thing about security analytics is it has to feed the security controls to help protect the business. If we use these tools to say, “It looks like we’re vulnerable to a certain attack and that attack has started,” you have to have recommendations of what to do now: implement x on the intrusion prevention system, turn on DoS prevention, close these ports on a firewall, block access to these apps, and so on. We have to connect those dots between “what’s happening” and “what do we do about it?” in a semi-automated sort of way.
The third piece of security analytics is the lessons learned part or corrective action part which says, “Why did we get into this vulnerable state, what’s causing this?” It could be this piece of software we deployed or attacks coming from countries that we never do business with. Perhaps prevention is something as easy as blocking geographic traffic from various countries — though it is rarely that simple.
Tying those three things together – the security expertise, the ability to push settings out to the security controls, and the ability to learn from it and not get into the same problem again – is what I call security analytics.
Linda: If this is the next generation of IT security, what will it take to get us there?
John Pescatore: There are three things you want to extract from the way that security analysts work. Think of it in terms of indication of interest, indication of attack, and indication of compromise.
If you look at the way these targeted attacks work, there’s usually a research phase or reconnaissance. An intruder would think, “I’m going to attack Acme Corp so I’m going to learn all their IP addresses, and I’m going to do everything I can to learn about their vulnerabilities and defenses.” That’s an indication of interest. There are ways we can detect if someone is scanning us, and there are other techniques that are much more advanced where I can say, “Somebody is interested in me and not in the way a customer would be.”
The second phase is indication of attack. This is sometimes as simple as intrusion detection or prevention signatures. We know an attack will leave these footprints on a firewall or a server. If we see those footprints, we know somebody has launched an attack. It also may be intelligence feeds we get from external intelligence sources that are actively looking for attacks that lets us say, “If we see anything from this IP address with a known bad reputation, that’s an indicator of attack.” Then there are the real world attacks that require a combination of all those factors to detect.
An indicator of compromise is an after-the-fact thing. For example, companies like Mandiant and Verizon get detailed information from being called in for incident response engagements, where someone has definitely been compromised. By doing the investigation to figure out how it happened, the examiners can learn the indicators of compromise that allow everyone else to check their systems to see if they see the same things. If so, they know they, too, have been compromised.
Linda: Obviously humans have figured out how to manually perform the tasks necessarily to find these indicators. Now how do you automate all of this?
John Pescatore: There’s a futuristic scenario that’s been talked about quite a bit. If we could have standard schemas and standard syntax for the way we would describe indicators of attack or indicators of compromise or the way we would describe vulnerabilities or firewall policies or intrusion prevention policies… if there was some standard machine-readable syntax, then that would greatly simplify things. That would allow us to find vulnerabilities and indicators and then push them out to our scanning devices and security devices, and those devices would know that if they see the indicators, then they should implement a specific policy.
There are standards efforts like this underway. The broader industry effort is led by NIST and it’s called the Security Content Automation Protocol (SCAP) effort. The participants have developed these schemas and common vulnerability enumeration languages — there’s a whole list of them. This is the path the security industry and government is trying to head toward that would enable a much more automated way of connecting these things.
I think SCAP is 6 or 7 years old and things like the common vulnerability language are even older. There are many tools that support the format, but actual end-to-end automation has proven to be quite complex. The difficulty is that threats change rapidly; IT changes rapidly. Five years ago we weren’t thinking about BYOD and cloud. We were thinking all the targets would be on PCs and servers in our data center that we control and we can look at very deeply. The pace of change is generally much faster than the pace of standards.
Linda: What is SANS Institute doing to help security practitioners learn about security analytics?
John Pescatore: We are putting together a conference, tentatively scheduled for January 2014 in Washington DC, on Cyber Threat Intelligence and Security Analytics. The goal is to help get people over the question of “How do I do this?” We will have numerous users, vendors and service providers involved in this conference, and they all have experience with the first stages of security analytics tools. We’re going to have major focus on what those companies have learned so far and how large enterprises can build their own solutions. The final date will be announced at http://www.sans.org/security-training/by-location/all.
- About Corero
- Investor Relations
- News Room
- Executive Management Team
- Corero Offices
- Contact Us