Home > Security

Computerworld - The security information flood is rising: Just as one is reading this article, a company firewall is probably spewing forth lots of "TCP incoming denied" messages, an intrusion-detection system (IDS) is filling the logs with alerts and a Unix syslog aggregation server is about to fill a new 40GB drive. Too much information effectively drowns the meaningful security events that require a response with a thick layer of noise.
But what events are meaningful? One can use a vendor-supplied priority rating for events. But the same alert from an IDS might mean different things for different environments. For example, a critical alert about a Microsoft Internet Information Server attack will mean next to nothing in a Unix-only network. However, many security products are shipped with fixed "priorities" for the alerts because there is no way to incorporate the unique site requirements.
This article will address the issue of "security response." It is defined as an incident response (IR) taken in a broad context. Security extends far beyond the IR process, which is activated only when a denial-of-service attack hits the Web server or a malicious hacker breaches the perimeter. A big part of security is responding to daily security events, such as log entries, alerts, etc., which might or might not develop into full-scale incidents. Thus security response is a reaction to security events, which can range in severity from a new line in a particular log file to corporate espionage or a major distributed denial-of-service attack.

	Anton Chuvakin, Ph.D., GCIA, is a senior security analyst at a major information security company. His areas of expertise include intrusion detection, Unix security, forensics and honeypots. In his spare time, he maintains his security portal www.info-secure.org.

What is the purpose of security response? What is the process to make security more effective given unique business constraints? In this three-part series, we will consider three environments -- the small or home office, the small to medium-size company and the large enterprise. Each has different requirements and associated security processes, and we will touch upon prioritizing security responses for each.
Security neither seen nor heard
The first scenario involves security response requirements for a small or home office LAN. Security in this environment should neither be seen nor heard. Admittedly, few people are excited about reviewing their system log files. In addition, few people collect attack statistics from home systems (unless you are a member of www.dshield.org distributed intrusion detection) and even fewer care about failed attacks (such as Code Red on a system