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:

Incident Response: Humans and Tools

Saturday, June 28, 2014 - 13:59

Following a couple of talks earlier in the FIRST conference that described how economic forces drive security downwards, it was good to hear a final keynote from Bruce Schneier that suggested that economics may actually encourage the development of high-quality incident response services. Incident response is commonly divided into three phases: prevent, detect, respond. Prevent and detect are increasingly in the hands of others: with a cloud provider you can’t specify specific security measures or monitor detailed activity logs; if your chosen monitoring or prevention solution isn’t in the app store then you can’t install it on your endpoints. Response is increasingly where organisations do have control and where they should be focussing their efforts.

The good news about response is that it doesn’t seem to share the same economics as much of the rest of IT. There high, entry costs, low marginal costs, high switching costs, and information asymmetries between buyers and sellers tend to lead to natural monopolies where competition is less effective at maintaining the quality of products and services. Responding to incidents requires much more human involvement – automated tools can support incident handlers but seem unlikely to replace them – so the marginal costs are higher. Furthermore, a good analyst should be able to work with a wide variety of tools – they’ll often have to – so switching costs are lower. And unlike the prevent and, particularly, detect stages, the quality of a response tool or process is likely to become apparent pretty quickly. This feels much more like a traditional economic market where different ways of doing incident response can be compared, the economic advantages of providing or switching to a better one are clear, and the advantage of being first to market is significantly reduced.

How humans and tools might work together is suggested by a model originally developed for aerial dogfights – the OODA loop. OODA stands for observe, orient, decide, act: the sequence followed by individuals in direct competition with others. And because each competing party (the attacker and the defender in the incident response process) is applying their own OODA loops, the side that gets around the loop quickest and most accurately is likely to prevail. Automated tools can be particularly helpful in gathering and presenting real-time evidence in an intuitive way: the Observe and Orient phases, in incident response often referred to as situational awareness. Decide is the stage that can only be done effectively by a human, though tools can again help automate the Act that they decide on. The effect of (and response to) that Act is the Observe and Orient stages of the next loop.

So a positive message to end the conference: incident response is increasingly important for security, humans are vital to it, and economics should promote the development and adoption of tools that help us do it better.