Determining When a Security Incident Has Occurred

I l @ ve RuBoard

This sounds deceptively simple. However, it may be very difficult to determine that a security incident has occurred. A system may be running "oddly" because the system has been compromised or it may be that the system is just running oddly.

Unless you have active system monitoring in place, it is unlikely that you, the system manager, will detect an intruder. More likely, a user who is on the system regularly will notice that the system is running slowly, or that he is unable to access something he should be able to access, or that the system is running out of free space, or some other oddity. In a large organization, these will be filtered through the help desk. It is these people who are the first to have the information needed to make a preliminary determination that the system may have been com- promised . All reports should be taken seriously. Hackers have a tendency to brag. Often those they brag to or even the hacker himself may report a security problem.

This is why it takes both technology to set up detection software and procedures to define the proper time and person to notify when an incident is detected and to make an appropriate response to the security incident.

Bibliofind, a subsidiary of Amazon.com for hard-to-find books, disclosed that customer credit card information was stolen between October 2000 and February 2001.

The security breach was discovered on February 26, when the site's homepage was defaced with electronic grafitti. It took the defacement to its website to compel Bibliofind to undertake the investigation of its network logs and server, which uncovered that they had been broken into for at least five months. ^[83]

^[83] Elad, Barry, "Bibliofind.com Finds Out it Has Been Hacked," Copyright 2001 INT Media Group, Inc. All Rights Reserved. Republished with permission from http://www.internet.com.

Determining the Severity of a Security Incident

Most information that shows up in security reports is because of harmless curiosity and honest mistakes ” generally , activities that require no follow-up actions. However, all incdents should be logged and reported in a statistical summary that can indicate changes in trivial attacks or where user education is needed. Management of the volume of data from security logs requires that you classify the severity of the incident reported by the information. Incidents that are common and are stopped by regular security measures, such as an unsuccessful attempt to telnet to your firewall system which does not accept telnet access, should be recorded but not reported. However, activities that indicate that a successful attack is underway, such as the unexpected changing of an executable file, should be reported immediately.

Classification of security alarms requires experience and common sense. It is fairly easy to identify the activities that are unimportant and those that are critical. It is all those in between that have to be evaluated, and an appropriate response defined. What is unimportant on one system might be critical on another. The unsuccessful telnet attempt from an unknown host to the firewall may be unimportant whereas the same activity to a banking system server may be considered critical.

In general, it is best to over-classify the severity of an incident and, with experience, lower the classification to an appropriate level. All new or unexpected activities, those that has not been previously classified, must raise a high level of alarm so they can be investigated and classified appropriately. This is an ongoing process that requires the input of system managers, information owners , and policy makers .

I l @ ve RuBoard