* Triage aspect of responding to computer-related emergencies
In this series of articles on computer incident response teams (CIRT), I turn next to some of the immediate issues in responding to computer emergencies.
These are:
* Triage – deciding how to direct calls for help or reports of a computer security incident.
* Technical expertise – the different kinds of knowledge that support effective response.
* Tracking incidents – ensuring appropriate documentation to save time and reduce errors.
* Critical information – laying the ground rules for collecting the kinds of data needed for effective decisions.
* The telephone hotline – suggestions for real-time notification and response.
So let’s start with triage.
The word itself comes from a French root meaning “to sort.” In medicine, triage is “prioritization of patients for medical treatment: the process of prioritizing sick or injured people for treatment according to the seriousness of the condition or injury,” according to Microsoft Encarta Reference Library 2004.
Similarly, anyone receiving calls about computer security incidents must be able to classify the call right away so that the right resources can be called into play. As the DISA course on computer incident response team management suggests:
The triage process recognizes and separates:
* New incidents.
* New information for ongoing incidents.
* Vulnerability reports.
* Information requests.
* Other service requests.
(I have altered the order of the original list to reflect a decreasing rank of importance for these factors in communicating and acting upon calls.)
Triage is common to ordinary help desks as well as to emergency hotlines. In general, there are two models for staffing the phones for such front-line functions: the “dispatch” model and the “resolve” model. The dispatcher has just enough technical knowledge to collect appropriate information about an incident and assign it to a team member for investigation; the alternative is to assign someone with more expertise to answer the phone so that response can be even faster. However, the resolve model risks wasting resources because the more experienced staff member may end up doing largely clerical work instead of focusing on applying his or her expertise to problem analysis and resolution.
To support triage, staff members need explicit training on data collection and priorities. They need to record who is calling, how to reach that person, what the caller thinks is happening, what the caller has observed, how serious the consequences are, how many people or systems are affected, whether the incident is in progress or is over (as far as they know), and how the caller and others are responding. CIRT procedures should include guidance on assigning priorities to incidents; factors can include security classifications (e.g., secret or company confidential data under attack), type of problem (e.g., breach of confidentiality, data corruption, loss of control, loss of authenticity, degradation of availability or utility), possible direct costs (e.g., personnel downtime, costs of recovery, loss of business), possible indirect costs (e.g., damage to business reputation, legal liability) and so on as appropriate for each organization.
Readers may find the work of John Howard relevant for such analysis; Howard has established a useful taxonomy for discussing computer security incidents that can serve as a framework for establishing priorities:
https://www.cert.org/research/JHThesis/Start.html
I recommend an automated system for capturing information on all calls to the CIRT. Using keywords “helpdesk software” and also “help desk software” brings up dozens of options for such programs. If you have modest skill in database design, you can also create your own using a program such as Microsoft Access. With appropriate locking strategies and automated reports, your CIRT can know and control the priorities of all the open incidents under investigation at any time.
