Regrettably, my faults regarding tolerance (or lack thereof) are not limited to grammar and spelling. Having once been a player in the SIEM arena for almost three and a half years, I cannot help thinking less of people who make what I think are bad decisions concerning purchasing and using SIEM products. SIEM stands for Security Information and Event Management. It consists of what used to be two fairly independent functions, Security Information Management (SIM) and Security Event Management (SEM). SIM functionality mainly includes log aggregation, log management and reporting. SEM functionality mainly includes event analysis through event correlation and possibly other methods, alerting, incident response facilitation (including trouble ticket and case creation, updating and tracking), and helping analysts in achieving situational awareness by providing network topology and other displays that pinpoint where in a network and what specific hosts and devices have been affected by incidents.

Although "we hold these truths to be self-evident, that all men are created equal" may apply to humans, it definitely does not apply to SIEM products. Many of these products, some of which sell surprisingly well, include little more than SIM capabilities. People buy these products, install and stick them in some server room while these products aggregate data that people seldom or never inspect. These people also configure reporting to obtain reports that they seldom use until they get word that auditors will be visiting them in the future, and go merrily on their way, often with the assumption that they are obtaining a very favorable total cost of ownership (TCO) because they feel they are meeting some compliance requirements by having these mostly unused and not-all-that-functional products.

Are you kidding me? What SIM products lack can sink the proverbial ship of an organization nowadays. We are getting hammered with Advanced Persistent Threats (APTs), with all kinds of attacks coming from China, Russia, Belarus, the Ukraine, Brazil, and oh by the way, also the US. The number of zero-day exploits per week has never been higher. Additionally, hundreds of new types and variants of malware are released into the wild every day. And what do SIM tools do about all this? They just sit there blissfully ignorant, unable to detect and report attacks because they have little or no event correlation functionality. Or they may have event correlation capability in name only. Frankly speaking, the proficiency of detection rules in SIEM tools designed primarily to do log aggregation, log management, and reporting is downright abysmal.

For about the same price as a SIEM tool that delivers only SIM functionality, someone can buy a SIEM product that will not only deliver log aggregation, log management, and reporting, but also all the SEM functions that are so critical, given the plethora of security threats that we currently face. How shortsighted can those who buy products with SIM but not SEM capabilities be? I don't know, but I suspect they are also the kind of people who also use "it's" in the possessive sense...

We have controls--plenty of them. Some of them (policies and standards, firewalls, intrusion prevention systems (IPSs), network access control systems, mantraps, fences and much more) help prevent attacks from succeeding. Some organizations, financial institutions in particular, are likely to deploy a wide range of preventative controls in an attempt to achieve "defense-in-depth," implementing layers of security so that if one layer fails, there will still be others to counter an attack. Some organizations do far better than others in using preventative controls, yet according to a multitude of sources, the number and cost of cyberincidents, in particular data security breaches, have sharply increased over time. A myriad of reasons why preventative controls have neither lived up to expectations and have not produced favorable a total cost of ownership (TCO) exists. In all likelihood the most critical one is that the black hat community is always one (and often more) move ahead of the white hat community when it comes to the proverbial game of cyberchess.

We also have plenty of detective controls--intrusion detection systems (IDSs), system and network event logging, network traffic sniffing, motion detectors, security guards in buildings, trip lights, content filters, security information and event management (SIEM) systems that collect, integrate and potentially even correlate information from all over a network, and more. The major idea behind detective controls is that as potentially good as protective controls are, they are far from perfect; there is not one of them that cannot be defeated or bypassed by a clever perpetrator. So, the idea goes, organizations need the ability to detect potentially adverse events that occur to determine whether or not they constitute an attack or other source of an outage or disruption. If so, intervention that reduces the amount of loss and damage can be initiated.

Reactive controls are the third and final type of control. Here we have automated incident response tools, incident response teams, business continuity and disaster recovery teams, chemical suppressant systems, self-adapting networks, anti-malware software that cleans malware infections, and much more. Without reactive controls, detective controls would be of little value, because detecting a malicious event without intervening accomplishes functionally nothing. At the same time, without detective controls, reactive controls would also be of little value.

So I'll get back to my original question. Which type of control, preventative, detective or reactive, works best? In theory the first should be the best, because top-notch preventative controls should be able to thwart all (or at least most) incidents. But something far different from theory is occurring with preventative controls today. They are working, but, well, just sort-of, and certainly not nearly as well as many of us have been led to expect. Consider, for example, the currently popularity of IPSs. A recent independent study show that several top selling IPS products did not even stop half of all attacks launched against the network they were supposed to defend in a test laboratory. One stopped only 17 percent of all attacks! Another similar study on anti-virus software showed that the majority of commercial anti-virus products did not even detect half of the Trojans that were installed in test systems in which the software was running. Defense-in-depth would help, true, but it is clear that the current generation of perpetrators is completely outwitting preventative control vendors.

So we turn next to detection. Unfortunately, IDSs have not fared a whole lot better than IPSs and anti-virus software when it comes to independent testing concerning detection proficiency. But when IDSs are at work providing one of numerous sources of detection information, the proficiency in identifying nefarious events can increase substantially if they are merely one of a number of sources of intrusion detection information. The same is true of firewalls, IPSs, anti-virus software, systems that send system logs to a central server, the output of network monitoring tools, and more. Collecting this all this information in a central location makes inspecting all this information possible, but chances are the amount of such information in a typical network is overwhelming for a team of technically proficient staff to inspect. So why not automate the analysis of the centrally collected information? Better yet, why not correlate the information, comparing each piece of input to models of the log and alert output that information systems and devices produce when cyberattacks occur and issue alerts when the information fits a model? By now, you should be getting my drift. SIEM technology makes proficient detection of potentially harmful events possible--it provides a way to make sense of volumes of information. Not all SIEM technology is equally proficient, however, but that is a topic for another blog entry.

Reaction is also potentially hugely critical, but it does not in my estimation reach the level of importance that detection does. The reason is that for the most part in the information security arena automated reaction mechanisms are not doing what they are needed to do as well as they should. For example, an automated reaction mechanism can send a command to a firewall to "shun" all incoming traffic from a particular source IP address, but there is a good chance that that IP address has been spoofed, something that may disrupt an ongoing set of e-commerce or business-to-business transactions. And I am sure you have heard how automated reaction mechanisms have malfunctioned, causing major lock-ups and disruption within IT environments. So for the most part, today's reaction mechanisms are manual, carried out by incident response personnel. It would thus be difficult to give reaction the nod as the type of control that works best.

In closing, as imperfect as some of them are, all three, preventative, detective, and reactive controls, are necessary in the struggle to stave off today's cyberattacks. But if we are going to rely on one technology, it would be a good bet to rely on detective technology, especially if strong SIEM technology is used.