Events, news, technologies and products about cyber security
Wednesday, April 23, 2014
[securityintelligence] Why Context is King for Enterprise IT Security
The importance of context in vulnerability management is imperative. However, the role of context goes far beyond the walls of vulnerability management and, in fact, has significant relevance in all areas of enterprise IT security, especially in security intelligence. The core purpose of security intelligence is to gain knowledge in an effort to efficiently secure networks. In both defense and assessment, this means fewer false positives and more relevant findings. Sadly, many security efforts fail to gain these benefits due to a lack of contextual information.
What Is Context?
According to Oxford Dictionaries, the definition of “context” is, simply, “The circumstances that form the setting for an event, statement or idea and in terms of which it can be fully understood and assessed.” Even from this simple definition, it is probably fairly clear to see why context is imperative in security intelligence: It is the contextual information that provides clarity in security events, and that clarity is what drives operational efficiency in the actions taken to address events.
Clarity in security events is rarely provided by a single piece of information; rather, it is derived from a myriad of experiences and at-hand data artifacts. Recently, there has been a major trend toward deeper integration of blacklist data and other artifacts under the terminology of “security intelligence integration.” While this data is invaluable, it is lacking in context and, if not used properly, can be the cause of inefficiency in security operations instead of being the solution.
Take, for example, the IP-based intelligence that comes from organizations that release blacklists. The information captured by these organizations is the direct result of a great deal of effort that includes detecting threats, figuring out what they are doing, determining their origins, determining the methodology that the threats are using and a great deal of other information. Unfortunately, all that effort is often bottlenecked down to single bits of information, such as an IP address or a DNS name.
The result is an inefficient process for those who adopt and integrate that information as a key piece of theirsecurity strategy. This is due to the processes that security operations professionals would have to utilize in order to make use of the information and ensure that the information is relevant in the context in which it was discovered on their network.
Creating Context in Security Intelligence
Examples of poorly integrated intelligence, such as that given with regard to IP-based intelligence, are widespread and common primarily because creating valuable intelligence inclusive of context is incredibly difficult. Previously, more mature security teams were able to create context and intelligence with a great deal of teamwork and the “yelling-over-the-wall” model of interteam information sharing. That model, however, is reaching its upper limit since the complexity of information architectures and the effort required to detect threats is increasing rapidly.
The result is requirements for the centralization of data and the automation of manual processes. Given the fact that the vast majority of adopted security technologies are primarily focused on alerting about specific technical aspects of an attack rather than about the root cause of the attack, automation of detection processes can be very difficult. Therefore, in order to achieve a deeper level of detection through automation, there has to be a combination of multiple security events with environmental information to give the context of an event and provide insight into the proper response.
This is primarily based on the specific event and the type of security countermeasure that a particular organization’s security strategy keys off of. In addition, it is extremely helpful when this information is centralized in either a log management solution or a Security Information Event Manager (SIEM). For example, if an intrusion prevention system (IPS) is central to security event detection in an organization, given a particular alert (e.g., an attempted buffer overflow), in order to determine the severity of the event and the proper reaction to it, answers to the following questions would be necessary:
What is the alert that fired?
What is the source of the event?
What are the details of the traffic that generated the alert? Is it an actual attack or a false positive?
Is the alert reliable? Or is it known for false positives?
Is this event common? Was a similar event previously noted as a false positive?
What is known about the source? Is it blacklisted for reasons associated with the traffic being seen?
Were there other events that may have provided an attacker with the insight necessary to perform this attack?
Were there associated events on the system?
Was there anomalous traffic pre- or post-attack?
Is the system known to be vulnerable to an attack of this nature?
Is there any additional information that would be of use?
Armed with this information, a simple IPS alert can become a powerful trigger for deeper automated processes; this is due to the security intelligence inclusive of contextual information. As a result, either a human analyst or an automated centralized system would be capable of more accurately identifying issues and providing a better response.