While the claims that "modern business works in real-time and so the security should too" are often heard from various vendors, it appears that few organizations are able to achieve that at the moment. This paper will look at the real-time requirements of the whole organization's security posture.

1. Real-time fallacy: how real-time your security really is?
Anton Chuvakin, Ph.D., GCIA, GCIH
Written in: 2004
DISCLAIMER:
Security is a rapidly changing field of human endeavor. Threats we face literally change every day;
moreover, many security professionals consider the rate of change to be accelerating. On top of
that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as
well. Thus, even though I hope that this document will be useful for to my readers, please keep in
mind that is was possibly written years ago. Also, keep in mind that some of the URL might have
gone 404, please Google around.
While the claims that "modern business works in real-time and so the security should too" are
often heard from various vendors, it appears that few organizations are able to achieve that at the
moment. This paper will look at the real-time requirements of the whole organization's security
posture.
So, how real-time is your security? One might think that most of the security is indeed happens in
real-time or very close to it: network intrusion detection systems pick up attacks off the wire within
microseconds, firewalls block connections as they happen and anti-virus technology makes the
best effort to catch the viruses as soon as they arrive from the network and via email (in fact, many
anti-virus vendors call this feature “real-time protection”). Moreover, intrusion prevention
technologies, with all their limitations, promise to stop attacks before they happen, making security
better than real-time, but proactive.
But security is not just a set of “pizza boxes” and software solutions protecting the enterprise. It is
also a whole slew of processes and people involved in them. How real-time are those? For
example, such processes commonly include:
• The dreaded security update and patch process, forming a flimsy and creaking wall of
protection between attackers and virus writers on one side and corporate assets on the
other. Few organizations patch within hours, even if the announced flaw is serious and
some don’t patch for months.
• Software upgrade process, replacing those Windows 98 machines with modern (and
hopefully more secure) operating systems doesn’t seem to be very speedy as the systems
should have been replaced years ago
• Vulnerability remediation and hardening process. Newly built systems are likely at least
somewhat hardened to comply with the security policy, but ongoing changes to such
systems are likely lagging behind similar to patching and upgrades.
• Security alert response process, where incident response team acts on the alerts and
messages generated by various security solutions. Such alerts almost always require
manual investigation that will take at least minutes and likely more.
Overall, it appears that there is a big disconnect between the timing aspect of technology security
and process security, which leads to suboptimal security operations and loss of dollars from
scarce security budgets. The weakest (or, rather, the “slowest”) link in the chain here is not the
hardware defenses, but their human counterparts.

2. Few people will agree to buy a network intrusion detection system (NIDS) that will only alert them
2 hours after the attack. However, those same people will have their security analysts check the
IDS alarms every morning. Thus, if they discover a critical compromise, a millisecond response
time of the NIDS system will not matter, but the hourly response time of the personnel will. So, if
the "morning after" alert investigation results in discovering a critical system compromise, it is still
deemed acceptable. While intrusion prevention automates such response in some simple cases
(where reliable detection can drive real-time inline blocking or firewall reconfiguration) for many
other abuses such as acceptable use policy violations automated actions are unlikely. Humans still
need to make a decision to activate the protection measures.
Similarly, if a virus-infected file arrives and the software can clean it “in real-time”, the problem is
solved. However, in case the anti-virus software detects the malicious code, but cannot
automatically clean or quarantine it and issues an alert instead (as it happens in the case of some
backdoors and Trojans), the response falls back on the shoulders of the analysts who are likely be
hours behind.
In any case, how many analysts watching alert consoles or wearing pagers 24/7 does your
organization have? The likely answer is 'few or none’; most security budgets are not that “fat”.
While government agencies and some managed security providers succeed in making the security
processes close to real-time, working under strict SLAs and achieving minute-scale responses to
security incidents, for the rest of the world the millisecond response of the technology component
simply will not matter, if the intended human recipient of the alert is asleep at the steering wheel
(or, at home, with the pager set to “off”).
Thus, the above emphasizes the point we are making in this article: to “speed up” your security to
respond to the ever increasing number of threats coming at you from inside and outside the
evaporating perimeter one needs to look at accelerating and optimizing the processes and not the
tools. It is agreed that full automation of a security management will not happen in the foreseeable
future. In fact, is hasn’t happened in a much more mature and less chaotic network management
space, where problems stem from misbehaving tools and not skilled, determined and malicious
“blackhats”, who (even though it pains me to say so) always outnumber and often outperform the
defenders by a significant margin. Automation certainly helps and will continue to expand from
anti-virus to host and network intrusion prevention, but human decision-making and prompt action,
assisted by various tools, will never become extinct. For example, correlation technology, available
in SIM solution, facilitates expanding the automated alerts due to the increased reliability of alerts
coming out of correlation engines. However, an expert input is still required to create the
correlation rules as well as to assist with the investigation in more complicated cases.
Optimizing the process involves decreasing the gap between the incident and response by
providing the actionable ”battlefield” intelligence and the defensive “weapons” to security warriors
as well as educating them how to use them effectively. How alerts are prioritized (and escalated if
needed) using the business relevance information as well as threat and vulnerability data? How
effective and repeatable is the incident response process? How are the lessons learned from prior
incidents lead to the decreased threat in the future? Having a well-defined answers to the above
questions will contribute more to security posture than decreasing the IDS time lag from
milliseconds to microseconds… That might not win the war, but will certainly help with most
battles.
ABOUT AUTHOR:
This is an updated author bio, added to the paper at the time of reposting in 2009.

3. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log
management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI
Compliance" and a contributor to "Know Your Enemy II", "Information Security Management
Handbook" and others. Anton has published dozens of papers on log management, correlation,
data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog
http://www.securitywarrior.org is one of the most popular in the industry.
In addition, Anton teaches classes and presents at many security conferences across the world; he
recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries.
He works on emerging security standards and serves on the advisory boards of several security
start-ups.
Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS
compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly
a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a
Chief Logging Evangelist, tasked with educating the world about the importance of logging for
security, compliance and operations. Before LogLogic, Anton was employed by a security vendor
in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook
University.