The answers to the questions above will determine how to proceed in the event of an incident and may prove critical to the organization. Let us consider them individ-ually and see what information is required as well as possible sources and metrics.
15.1.1 Is it Actually an Incident?
Nontechnical personnel encountering unusual events on the network or on their computer may suspect that an incident is taking place and report it, perhaps to the help desk. Help desk staff unfamiliar with the situation may in turn escalate it to IT or security, or ignore it. If the situation is unfamiliar to security staff or IT, how will they determine if the situation constitutes an incident and is in fact posing a risk?
What must be done to clarify whether just an individual desktop machine has a problem or it is a manifestation of a bigger event? It is likely to prove useful to have a defined, systematic approach of troubleshooting to quickly determine these an-swers so that proper response can be initiated. As in medical situations, early detec-tion and proper diagnosis are key to preventing serious impacts. In the majority of organizations, general awareness education about incidents and specific training for key personnel is the proven method of improving incident detection, management, and response.
Depending on what is monitored and the types of metrics available, there will be information, which, if accessible, will be helpful in incident diagnosis. For exam-ple, incidents involving intrusions into a network may be detected by network intru-sion detection systems (NIDS) or host IDS (HIDS) or other tools such as security information management (SIM) tools checking logs. There may be possibilities for detecting anomalies when the ranges of normal operations are known, in a manner similar to anomaly-based IDSs. In other words, unusual levels of traffic or certain operations at unusual times can be an indication that something is amiss. This is true of physical access as well, and having visibility into existing physical access controls is essential and, surprisingly, in most organizations, unusual.
A simple and effective monitoring tool is to simply correlate physical presence with log-in location. Obviously, if someone not shown to be on the premises by physical access controls is found to be logging into the system from the premises (i.e., not remotely) either there is a failure of the access controls or there is some other security incident occurring.
The information needed to determine whether an event constitutes an incident will require personnel monitoring resources having suitable skills as well as effec-tive communication channels. If skills are not adequate, the decision will be to ei-ther provide training or acquire personnel with the necessary skills. If who needs to communicate what to whom, when, and how is not understood or the channels are not available, the decisions will revolve around addressing those issues.
Understanding that this information is required to make appropriate decisions makes it straightforward to determine what metrics or monitoring are needed for management.
The skills needed must be determined and then skills assessment testing is re-quired to determine the gap that must be addressed. Communication channels can be tested by simulated incidents, perhaps starting with a table-top walk-through to ensure that personnel have the right information and understand their responsibili-ties. The metric will be binary, that is, personnel either have the skills and know what to do or they do not.
15.1.2 What Kind of Incident Is It?
There are generally few metrics likely to directly identify the type of incident ex-cept monitoring and diagnostic capabilities. An example is a physical event that will have technical manifestations such as lost connectivity when a ditch digging machine severs the fiber link to the data center or a wiring closet burns up. Whether the organization considers these to be security events varies, although, arguably, this will impact availability, which usually has security implications of one sort or another. If emergency services cannot be contacted, air traffic control cannot com-municate with aircraft, or credit cards cannot be authorized, it is difficult to argue that availability is not a security issue.
Validating that an incident has occurred, as in the foregoing paragraph, will gen-erally result in the determination of the kind of incident it is. Additional information will usually be required such as the scope and possible impact of the incident as well.
15.1.3 Is It a Security Incident?
There is little consensus on exactly what constitutes a “security” event, although many organizations have developed internal criteria and definitions. Organizations often consider the cause of an incident to be determinative; that is, a deliberate dis-ruptive act would be a security matter, whereas an accident would not. This distinc-tion suffers from the fact that it is easy to imagine many accidental situadistinc-tions that can have major security implications and impacts. It may be more prudent to con-sider a security incident as any event that has the potential of compromising securi-ty or elevating risk, regardless of cause.
15.1.4 What Is the Severity Level?
Severity of an incident must be determined quickly and, hopefully, with a degree of accuracy. Declaring a full-fledged disaster as the result of a minor incident is not likely to be a good career move and neither is failing to declare one and reacting ap-propriately when there actually is one.
Severity levels must be defined and agreed upon, and personnel must be educat-ed or traineducat-ed to make the determination. Authority to declare the various severity levels must be assigned and escalation procedures defined. Other preconditions ex-ist such as information asset classification, which is required so that the criticality and/or sensitivity of affected assets can be quickly determined, which, along with the level of impact, will be largely determinative of severity level.
Once again, good diagnostics will be the key to efficiently gathering the needed information to arrive at a conclusion and initiate appropriate action.
15.1.5 Are there Multiple Events and/or Impacts?
Incidents can aggregate and/or cascade. That is, one threat can affect multiple re-sources concurrently, or an incident can initiate a chain of events, causing a “cas-cade” of failures, the so-called domino effect. It will be critical to determine the scope of the impact or whether there are other resources at risk as a result of an event. Metrics and monitoring are often helpful in assessing scope but intimate knowledge of systems, networks, personnel, or facilities are likely to be needed to assess likely “knock-on” eventualities.
15.1.6 Will an Incident Need Triage?
Multiple events that exceed the organization’s incident response capacity to address them all will require triage to determine which issues to deal with; which to ignore, either because they are not serious or there is no ability to address them effectively;
and in which order. This capability requires substantial expertise; systems, person-nel, and, possibly, facilities knowledge; a variety of real-time operational metrics about what is working and what is not; performance impacts; and so on. For purely technical events, the typical range of data being monitored in the NOC may be ade-quate provided there is the expertise to interpret it correctly.
15.1.7 What is the Most Effective Response?
Determining the most effective response to a security incident requires the right in-formation and knowledge of the available options. For example, if an attacker has breached perimeter security and raised an intrusion detection alert, what action should be taken? Perhaps the network is segmented and the attack can be isolated.
Perhaps the intruder can be blocked at the firewall or, possibly, more drastic action is required such as terminating the connection to the Internet. Without adequate in-formation and an understanding of the systems and architectures, it will be difficult to determine the least disruptive response consistent with security.
Physical compromise such as theft of proprietary information or indications of embezzlement by an insider will present even more challenging response issues.
Often, the main metrics and sources of information for these types of events will be technical or accounting forensics.
15.1.8 What Immediate Actions Must be Taken?
Some incidents will require immediate action to avoid serious consequences. HIDS or NIDS inside the perimeter signaling an intrusion certainly qualifies. Besides val-idating that it is in fact an intrusion, operational metrics indicating the scope and na-ture of activity are critical to deciding the nana-ture and extent of action required.
In many organizations in which operations and traffic follows consistent pat-terns, anomalies may be a useful metrics to warn of incipient incidents.
15.1.9 Which Incident Response Teams and Other Personnel Must be Mobilized?
The type and nature of an incident must be determined to make decisions about which teams or personnel will be required to deal with it.
15.1.10 Who Must be Notified?
Utilizing defined severity criteria will provide the input into the declaration criteria, which,if properly developed, defines who has what authority and who must be noti-fied.
15.1.11 Who Is in Charge?
Indecision and lack of clear authority to take necessary actions can and has trans-formed and incident into a disaster.
15.1.12 Is it Becoming a Disaster?
It is clear that one of the metrics the information security manager must develop from an incident management and response perspective is the level of skill and ex-pertise available at a given point in time to address events.
Information Security Governance. By Krag Brotby 161 Copyright © 2009 John Wiley & Sons, Inc.
Chapter 16
Conclusion
For the stalwart reader that has come this far, it should be evident that developing and implementing information security governance in situations where little exists or where a significant overhaul is required is no minor endeavor. Nevertheless, moving into the future, there are not many good options and organizations will have few prudent choices. The combination of regulatory, legal, and credit industry pres-sures coupled with ever more spectacular security compromises will make it in-creasingly difficult to continue the ad-hoc, reactive, point solution approaches that are still the norm. It has become evident that the historical approach of seeking the substantial benefits offered by information technology and global interconnectivity cannot continue to operate “on the cheap” and must be properly governed and man-aged. As with any major organizational activity, this requires commitment and re-sources. More importantly, it also requires a systematic, organized, engineered ap-proach managed by competent professionals, coupled with good business sense and the “soft” interpersonal skills that are the mark of effective managers.
It is essential to understand that effective governance is not possible without metrics, and the converse is true as well. The maxim that “what gets measured gets done” is well founded. It is clear that the way forward for security is not significant-ly different from that of any other nascent discipline. The processes that give rise to reasonable levels of assurance require integration into the fundamental objectives of the enterprise at the highest levels. It must be the concomitant with setting orga-nizational goals and it must become the nonnegotiable requirement of the exercise of due care. Until such time, information security will be characterized by the hap-hazard, reactive point solutions typical of security departments generally operating behind the power curve and all too often in crisis mode.
Information Security Governance. By Krag Brotby 163 Copyright © 2009 John Wiley & Sons, Inc.