More on the Limitations of Intrusion Detection Systems
Despite my passion for intrusion detection, I am deeply concerned about what is happening in the intrusion detection arena. Nearly a year ago I wrote a short blog series called “The new intrusion detection.” I asserted that intrusion detection systems are missing many current types of attacks, such as social engineering attacks in which malicious attachments and URLs of malicious Web sites are contained in email messages that appear to be sent from someone the intended recipient knows. Statistics presented by Christopher Novak of Investigative Response Verizon Business Security Solutions presented at the ISSA-Silicon Valley meeting earlier this week suggest that the problem is even worse than I previously suspected. According to Novak, only three percent of all attacks indentified by Verizon Businesses’ clients were identified by signature-based intrusion detection systems (IDSs). In contrast, clients became aware of 69 percent of these attacks only after they were informed by a third party.
I have previously argued that IDSs (especially signature-based IDSs) in and of themselves are of little value anymore. They “see” only what they are configured to “see,” a fraction of the multitude of events that occur within networks and hosts. But they can at least provide one source of input for attack identification. Event correlation based on input from multiple sources, IDSs very much included, is necessary if organizations are going to be more proficient in identifying attacks. Security Information and Event Management (SIEM) technology is thus in theory ideally suited for this purpose, but as if have said so many times before, not all SIEM tools are equal. Only a few have excellent event correlation capability–the rest are essentially nothing more than log data aggregators and managers that provide little if any help whatsoever in incident detection.
So now I have a new concern regarding IDSs–using them can delude people into believing that they are really informing them about attacks that have occurred, when they in reality are not (unless, of course, they are being used as data reporters in event correlation). Just look at how long it took TJX, Heartland Payment Systems, the University of California-Berkeley, and UCLA to detect their recent massive data security breaches. I am confident that too often information security and IT staff members deploy IDSs without attempting to benchmark them for their proficiency (or lack thereof) and to estimate the amount of residual risk associated with them. These people somehow need to be educated concerning the limitations of today’s IDSs as well of the need to benchmark them and perform residual risk analyses on them.
At the same time, we need to wake up to the fact that even if an organization has good event correlation capability, organizations still need to share data about attacks with each other to improve the ability to recognize attacks. The US Government set up numerous Information Sharing and Analysis Centers (ISACs) in an attempt to achieve this and other goals. The Financial ISAC, for example, promotes sharing of security-related information within the financial sector, whereas the Energy ISAC facilitates information sharing within the energy section. Although ISACs have a way to go, they have at least established the value of such centers in cooperative information sharing that leads (among other things) to incident recognition.
Intrusion detection methods need to evolve as attacks and detection evasion methods get better. Right now event correlation and cooperative information sharing currently provide the best results, but other, more proficient methods will certainly surface in the future.