Last updated: 
3 weeks 2 days ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

An anthropologist learns about incident response

Wednesday, June 25, 2014 - 22:43

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.