I promised you some more thoughts on the AVAR conference. Randy Abrams and I put together a paper on user education for the conference (it should be up on our White Papers page quite soon) about the argument between the two main camps in security thinking on the topic. You could sum it up as
I promised you some more thoughts on the AVAR conference. Randy Abrams and I put together a paper on user education for the conference (it should be up on our White Papers page quite soon) about the argument between the two main camps in security thinking on the topic. You could sum it up as “If user education was ever going to work, it would have worked by now!” versus “You can’t fix social problems with technological solutions!” And I guess you could sum up our position as “Since neither approach is going to eradicate security breaches, why not integrate the best elements of both approaches into a multi-layered strategy?” (Not as simple as it sounds, but it’s worked for both of us in our previous careers.)
While Randy was doing the presentation (it’s called delegation 🙂 ) I had one of those moments of blinding clarity. The trouble with these instances of dazzling insight is that sometimes they turn out to be about suddenly realizing something that the rest of the world has taken for granted since the Renaissance, but I’ll share it with you anyway.
I’ve spent a great deal of my working life in user support: not so much manning (personning?) the helpdesk phone – though I’ve a fair amount of flying time there, too – but second and third line support. You can certainly look at user education and training as a close relative and in some contexts a subset of user support functionality (no, that isn’t the insight).
There are, it occurs to me, two ways of approaching user support (not that they’re mutually exclusive): for each trouble ticket with your name on it you can take whatever technical measures are appropriate almost without reference to the end-user. That way, you often get a quick fix (re-install, disinfect, replace a malfunctioning component, reset a password) and you can move on quickly to the next job. Users are generally happy because you aren’t expecting any significant effort from them. But what if it’s a problem to which they contributed in some way? All they’ve learned is that if the problem reoccurs, you’ll come back and sort it again. You’ve treated the symptom, not the disease.
The alternative is to look at each trouble ticket (logged request for support) as (potentially) a learning experience. If the user has some understanding of what the problem is, he or she may also realize that there’s a better way of approaching the task that originally sparked the problem. Involving the customer more directly in the problem-solving process may add significantly to each incident resolution, but that’s not a problem if it results in some reduction of the overall volume of incidents. This is social engineering in its more general sense, persuading people to do what’s good for them and the groups to which they belong, not what’s good for some blackhat Svengali.
Of course, some users will resent any attempt to educate them: they will regard it as your job to fix anything they break, just as some AV users expect that because they’ve installed AV, they should be able to click on anything they like without thinking about it. Well, teachers don’t manage to educate all their pupils, either, but we haven’t given up founding schools and universities…
David Harley
Director of Malware Intelligence
