If you’ve been watching movies and TV series, it may come as a surprise that most computer security incident response actually involves a lot of command line interfaces and perl scripts, and rather few graphical interfaces. That was the first disappointment that greeted a team of computer scientists from Honeywell and Kansas State University who tried to help their local security team with some new tools. The second was that those analysing incidents seemed to rely much more on experience and intuition than on rules or algorithms that might be encoded into software or training manuals. Attempts to interview analysts weren’t a great success either as they objected to the addition into their busy schedules and were reluctant to share what might be sensitive information about their work with those perceived as outsiders.
The researchers then consulted their local anthropologist (apparently most US campuses have some) and learned about participant observation. The security team were offered the services of some interns, to help with programming and other tasks. This worked much better: analysts were willing to talk to the interns about their unresolved problems and when the interns produced tools to address them, these were quickly adopted. Discussions soon widened and the interns were able to learn a lot about incident response from their new colleagues.
What they discovered and reported at the FIRST conference matches my own experience of joining the incident response community and, I hope, helping others to join it through the TRANSITS training courses. Incident responders deal with a lot of sensitive information, so very naturally adopt a ‘need to know’ attitude. To get involved in conversations, whether at a personal or organisational level, you must first demonstrate that you can bring benefits to the team and community: “talking with me is worth the time”. And those conversations are critical, because beyond the basics incident response is something you learn by doing. Much of the knowledge is tacit, rather than explicit, so incident responders couldn’t “write down what you know” even if there were sufficient time. Instead it’s a skill learned through sharing knowledge with colleagues and, eventually, experience. Managers and organisations that want to improve their incident response teams need to find ways to facilitate, encourage and reward knowledge sharing both among the team and with others – without that, shiny new technical tools are unlikely to deliver significant benefits.
