IT World Canada is pleased to offer research from Meta Group Inc. This content will be featured on ITWorldCanada.com for three months from the article’s publication date.
Event monitoring is of interest from both a security and an operations perspective, but to date they have tended to be implemented separately with different toolsets. This joint interest has given rise to vendors and enterprises exploring the convergence of these two capabilities. Although overlaps in technologies, requirements, and processes exist, significant differences remain, which will impede full convergence indefinitely.
META Trend: Threat and vulnerability management integration will accelerate through 2004. While most organizations still focus on technology problems of intrusion control and count on improved detection, correlation, and prevention capabilities, advanced organizations pursue a more process-oriented approach (introducing a business perspective), which will evolve into comprehensive vulnerability life-cycle management in 2006/07. Demand for managed security services of various types (e.g., security monitoring, customized alerts) will increase, but despite vendor consolidation, maturity will lag for many disciplines through 2005.
This research explores the similarities and the differences between operations and security event monitoring (discerning useful information from discrete recorded occurrences) to illuminate the challenges before an industry and a market that would like to exploit the efficiencies presented by convergence. It should be noted that the difference between operations and security monitoring can seem subtle. Operations is about troubles caused by machine failures and accidents. Security is about troubles caused by human failures and malicious intent. If operations realizes that a server is down not because of a hard-disk crash, but because someone stole it then it is a security event. If security people find out that a Syn flood is caused by a defective network card, then it is an operations event, and both parties should forward accordingly.
Two Requirements
The most obvious area where security and operations differ is in what they are looking for in the events. Security requirements focus on behavior, access, performance (patterns), privilege usage, and configuration changes that indicate a violation or suspected violation of data confidentiality or integrity. Operations requirements typically focus on infrastructure and software component performance and availability to detect an outage, performance degradation, failed service-level agreement, or affected service. One of the most significant differences is in the characteristics of the detection requirements. Operations events tend toward deterministic patterns for root-cause analysis, identifying hard faults in operations, while security events tend to be probabilistic chains of user behavior leading to suspected security threats.
Two Sources of Data
There are many overlaps in the data sources used for each requirement. For example, Unix Syslog contains data of value to both requirements. However, some sources are clearly of higher value to one than the other. For example, the Windows system and application logs will be more useful from an operations perspective, and the security log will be of more use from a security perspective. Although both perspectives can make use of all three logs, one of the goals of event log analysis is to lower data volumes by focusing on higher-value events.
Two Teams
The security and the operations teams are typically separate organizationally with different reporting chains and focuses. It is unlikely that these two teams will be integrated due to differences in skill sets and day-to-day activities. Such teams should also be kept separate to maintain the principle of separation of duties (see Delta 2375). However, it is possible that some organizations will create a first-line analysis capability using shared process elements of both security and operations events before handoff to teams with more expertise.
Two Processes
The processes followed by each of these teams can diverge as well. Operations processes usually have the primary goal of correcting technical issues or making configuration changes to fix an identified concern. Security teams must monitor for threat or attack, then have escalation and response processes crafted to the type and the impact of a particular security attack or threat. The deterministic nature of the operations events lends itself more to automation than do the security events. In addition, security must retain collected data for further analysis and prosecution support (with a clean evidentiary trail showing uncompromised integrity), whereas operations usually does not care about the event data for prosecution reasons. Although separate processes should be maintained, many should be interfaced (e.g., security incident response, operations incident response, security research, configuration management).
Two Toolsets
Overlap exists in the collection, centralization, and normalization requirements for tools in both spaces. For example, both use similar architectures with local agents and remote access. However, the dichotomy of deterministic operations requirements versus probabilistic behavioral security requirements limits the useful overlap of analysis engines. Security analysis can take on many forms (and many different perspectives), including well before an attack (probing), just before an attack (to prevent intrusion), during an attack (to mitigate intrusion detection), during midattack for a worm spreading through an organization (to limit damage), and during postattack (for forensics, prosecution support, and appropriate countermeasures to prevent future attacks see Delta 2705).
A Single Goal (Likely Convergence Points) Even given all these differences, there is room for convergence on many levels. Starting with toolsets, there will likely be a shared infrastructure in both spaces to collect, centralize, and normalize events possibly into a central database. Organizations should attempt to minimize the number of agents they deploy and therefore share data across all audiences. The analysis engines will be different, potentially coming from diverse vendors. Aside from a potential common first-line support, the alerts will be directed to different teams with very different goals. This common infrastructure should reduce situations where the data is collected twice, but we predict that security will always collect higher volumes of data. Conformance to security policy might restrict some aspects of this common infrastructure, because the operations team might not want to deal with security-unique requirements to protect the integrity of the data.
Most organizations will end up with separate security event managers and operational event managers. Although they may come from the same vendor (several years in the future), the implementation of rules and integration to data sources will drive separate products, pricing, and implementations (though the vendor may leverage some of the same technology across each tool).
Processes will have to change for convergence to work at any meaningful level. Each group should share data. For example, the security team might be asked to pass correlated “security events” to the operations console (e.g., intrusion underway that is why the CPU is pegged on this machine). The operations team will be asked to share correlated “root cause” with security. However, each will continue to maintain its own tools beyond the shared infrastructure.
Business Impact: Some level of operations and security event correlation is possible, but taking it too far could fail and decrease the effectiveness of both capabilities.
Bottom Line: Although there is a belief among vendors that operations and security event tools will come together, the differences in which data is monitored and collected, how it is analyzed, who analyzes it, what actions are taken, and how it is stored long term all drive toward the need for separate products.
Copyright
