Obtaining Data About Security-Related Incidents

Obtaining Data About Security- Related Incidents

What about determining the specific kinds of security-related incidents that are most likely to transpire in a particular organization? This is by no means an easy task.The next part of this chapter explores some approaches to this problem.

Data About Incidents Within One's Own Organization

One of the most readily available sources of information for an organization is data about incidents that have occurred in the past. To at least some degree, incidents that have already occurred serve as a predictor of incidents that are likely to occur in the future. An organization that has had a rash of break-ins over the last few years , for example, is likely to continue to see the same pattern, at least in the near future.

Successfully gathering incident data of this nature generally requires that there be a policy concerning whether incidents must be reported to a central group or function. Mandatory rather than voluntary reporting results in both more data and better quality data. Additionally, standardizing reporting in terms of the type of data to be reported is generally more useful in producing the kind of information that is likely to be helpful: the total number of incidents, types of incidents, the duration and severity, and so forth. Chapter 3,"A Methodology for Incident Response," deals with the specific types of information that are critical when incidents occur.

Firewall and system logs are a good source of data pertaining to incidents that occur within one's own organization. Firewall logs are particularly valuable in that they can capture all traffic coming in to and going out of a network. The problem, of course, is the voluminous amount of information that both firewall and system logs are likely to capture. Additionally, the format of these logs is often far less than optimal from a human usability viewpoint. Another good way to collect incident data is to deploy intrusion detection systems (IDSs). IDSs declare certain events they detect to be incidents or, alternatively, at least anomalous.

Data About Incidents Collected by Other Organizations

A number of incident response teams make information about incidents and potential incidents publicly available. CERT/CC, for example, releases summaries of current incident activity. ^[4] CERT/CC's quarterly summaries of the kinds of incidents that have been reported to this center, in addition to its advisories that describe new attack trends, can provide extremely valuable information about previous incidents and threats. Additionally, certain agencies and organizations within the U.S. Government (such as the National Infrastructure Protection Center [NIPC]) furnish threat update information at various times through electronic advisories and/or web pages.

^[4] www.cert.org/current/current_activity.html

Web sites such as alldas.org ^[5] and antionline.com ^[6] can also be sources of extremely worthwhile information about incidents that have occurred as well as hosts and sites that might be currently targeted . Although no statistics are ever immune from at least some form of criticism, these teams' and web sites' statistics can serve as an excellent source of at least a general understanding of incidents (including their relative prevalence), something that can be readily translated into risk estimates.

^[5] www.alldas.org

^[6] www.antionline.com

Vulnerability Analysis

Vulnerability analysis can also provide data about risk. Vulnerability analysis involves finding out how the security of systems, network devices, applications, and databases can be breached; how easy or difficult it would be to exploit each weakness that has been identified; the particular systems, network devices, applications, and data that are vulnerable; and the kinds of impact each breach would have. Note that vulnerability analysis is most effective when it is paired with penetration testing, which can provide tangible evidence not only of the presence of vulnerabilities but of the degree of difficulty in exploiting each.

Vulnerability Detection

The value of vulnerability analysis is by no means limited to risk identification and assessment. Finding vulnerabilities before they are posted on newsgroups and then cooperating with vendors to address the vulnerabilities that have been discovered , for example, constitutes one of the most productive and proactive activities in the entire information security arena.

Determining that most vulnerabilities (and all potentially high-impact vulnerabilities) have been patched in nearly every system and application throughout an enterprise, for example, would translate to a much lower estimate of risk than if the vulnerabilities were not addressed. Or, alternatively, perhaps some types of systems (such as AIX or AS400 systems) have many unpatched vulnerabilities, but others (such as NetWare and Solaris systems) have few. In this latter case, the magnitude of estimated risk would be considerably lower than in the former case.