There are six key technologies that have defined our security process for the last 25 years. Some of these technologies aren’t as effective as they once were. Following a record year for data breaches, is it time to question our security processes?
The answer, of course, is yes. When something is broken, you fix it. But first, a brief history lesson:
- In 1986, the first intrusion detection system was invented.
- In 1987, John McAfee released the first version of VirusScan.
- Syslog as a universal format was created in the 1980s and documented as ).
- Packet filtering firewalls were invented in the late 1980s, and stateful firewalls were brought to market in 1989.
- Nessus was invented in 1998.
- In 1999, the first security event management system was created.
The ’80s and ’90s were very innovative times in Internet security. However, several of these technologies have turned out to be very noisy and produced false positives. Security information and event management (SIEM) correlation of security data, OS log data and vulnerability data was supposed to reduce this noise. This began what’s commonly known as the funnel approach. All security events go in the top of the funnel and the “legitimate” events — the ones we are supposed to be paying attention to — are the ones that come out the bottom as alerts. The funnel model may have worked well 10 or 15 years ago with a couple of hundred security events boiled down to 10 or 20. Today, the security team is looking at 10,000 (or more) events in a day and ending up with 1,000 (or more) alerts for follow-up. This has placed the burden back on the human to always ask if an event is a false positive, which leads to a general distrust of their own tools.
Once the security team has seen something that isn’t a false positive, they begin a manual process of linking disparate log events together by time, IP address, host name or other artifact. It can take a few hours to a few days to complete this task. If the right assumptions have been made, the analyst might get to the right root cause and the “patient zero” of where the attack started. Once that’s done, there is an attempt at attribution to a specific set of user credentials. All bets are off if the attacker switched identities, in which case the process takes even longer or may not complete at all.
There have been many evolutionary advances in cybersecurity as technologies improved and features added (which also increased complexity). The function of many of these base technologies has remained the same. There are two areas of innovation which deserve note. The first is Splunk, which pioneered data indexing and schema-on-the-fly for log search, and the other is malware detection and sandboxing pioneered by a number of companies, including FireEye.
The next new big thing is user behavior intelligence solutions. These automated solutions use machine learning, custom built behavior models, user session assembly, Stateful User Tracking™ and risk scoring to ask dynamic sets of questions about user credential behaviors and access characteristics of your existing SIEM data. They then link security system alerts to user sessions and credentials. The result is a dramatic acceleration of processes that expose the entire attack chain and turns the discovery of an advanced persistent threat into a credit-card-fraud-style Q&A by a tier-one analyst — “was that you using the VPN from Shanghai at an odd time of day, attempting to log into these 5 systems, accessing another and then switching identities? And, by the way, while you were logged into the host, FireEye sent out an alert.”
It’s clear that the technologies of the ’80s and ’90s served us well, but the advent of social engineering has put the attacker back in the driver’s seat with sets of valid credentials that allow them to get past current security detection tools. Further, once the attacker gets beyond initial intrusion detection systems by using credentials, there is no security strategy for detection. User behavior intelligence systems turn the security funnel process on its head by starting with the user credential and attributing to it security sensor data.
Don’t believe me?