CIRT Management: Beyond technical expertise

In this installment of my continuing series on Computer Incident Response Team management, I’ll address the expertise needed for various functions in the CIRT and the attitude CIRT members should adopt when working with users.

The DISA course I’ve been referencing has simple, clear recommendations, which I will summarize here. We can start by classifying technical expertise in approximate ranges:

* Low. Suitable for the triage function, which involves determining who should best handle a specific call.

* Medium. Appropriate for answering requests for information.

* High. Suitable for technical problem-solving.

* Expert. Suitable for handling problems that others have been unable to resolve and especially for issues involving vulnerability analysis and real-time responds to attacks.

As the DISA writers point out, “Vulnerability handling requires your most proficient personnel.… These individuals must be able to work with software vendors, CIRTs, and other experts to identify and resolve vulnerabilities. Many CIRTs don’t have access to this level of technical expertise.”

I want to add some additional requirements for the personnel involved in the CIRT. Not only should managers look for and ensure adequate technical knowledge, but they also should select and enhance interpersonal skills and disciplined work habits.

CIRT members inevitably work with some users who are stressed by the problems they are facing. It is no help to have a technical wizard who so offends the users that they stop cooperating with the problem-resolution team. Sometimes, CIRT staff forget that their job includes not only resolving a technical issue but also keeping the clients as happy as possible under the circumstances – and the use of the word “clients” is deliberate here.

Here are some of the most irritating responses to users I have run across in my 25 years of technical support followed by my comments in parentheses:

* “No one has ever complained about this before.” (So what? If the problem is real, we should thank the user for reporting it, not make veiled criticisms that imply that the problem can’t be real.)

* “I don’t have time for this now.” (That’s a time management problem for the CIRT, not for the client. Take responsibility for getting the right person to take charge of the problem in real-time.)

* “Why don’t you try calling [someone else]?” (Same comment as just above.)

* “That’s not my problem.” (Just plain rude, as well as irresponsible.)

* “Why don’t you reload the operating system and call me back if it happens again?” (Significant risk and time-cost for the client; often the first line suggestion of the terminally incompetent technician.)

* “Just format your hard disk and see if it happens again.” (Even worse than the previous suggestion if it is just a casual suggestion to get the client off the phone for now.)

* “Don’t get mad at me – I just work here.” (A professional will understand that there’s a difference between criticism directed at the organization or its procedures vs. a direct _ad hominem_ attack. The former should be taken seriously and passed on to people who can evaluate the seriousness of the criticism; the latter can be unacceptable and should be passed on to a manager who can explain the need for civility even under stress.)

If you would like to download PowerPoint presentations that cover many aspects of technical support management, you are welcome to visit my Web site:

https://www2.norwich.edu/mkabay/courses/academic/jac/TSP/index.htm

In the next articles in this series, I’ll be looking at how to track the details of calls to the CIRT.