Branimir Valentic A great deal has already been said about incidents. Actually, I think that I’m not wrong when I say that Incident Management is the most commonly implemented process in IT Service Management (ITSM). And, that’s perfectly logical and reasonable.
Both ITIL and ISO 20000 define an approach for how to handle incidents. But, both of them pay particular attention to the security-related incidents. And, that’s logical and reasonable, too.
What’s the importance?
In general, incidents are highly visible to your users (i.e., people using your services) and customers (i.e., those who pay for using your services). Take e-mail service as an example. Can you imagine how your users would feel if or when that service became unavailable? Actually, you don’t have to do that, because you know the answer. And, they would have the same feelings if their e-mail service started having interruptions or malfunctions, i.e., incidents started to occur.
And, you know what? Incidents could get worse – when they are security related. Basically, security-related incidents mean that not all incidents are the same. Let me get back to the e-mail service example again. A security-related example would mean that, e.g., someone’s account is compromised, meaning an unauthorized person has access to it, or that a lot of SPAM is sent from someone’s corporate account. In both cases the issue is not only that, e.g., that user can’t use the service for some time (that would be a case when a “normal” incident occurs), but that the company could have a significant financial loss (e.g., sensitive data are revealed because an unauthorized person has access to the e-mail account) or all corporate e-mails are banned by SPAM filters due to unsolicited e-mail that is sent.
How do you handle them?
As you can see, not all incidents are the same; i.e., security-related incidents are usually more visible than others. It’s reasonable to ask – how can you distinguish them? As we already explained (see the article All About Incident Classification, incidents have different categories and priorities. That’s the mechanism companies use to differentiate security-related incidents from others – a separate category is defined in the incident catalogue (that’s a list of all incident categories) and the priority matrix is more conservative (i.e., security incidents are always assigned higher or highest priorities – I have seen an organization where security-related incidents always get highest priority).
A key activity in defining the category and priority for security incidents is risk assessment, which will enable differentiation between different kinds of security incidents. Actually, ITIL will advise you, and ISO 20000 will oblige you to do the risk assessment. That means that you will have to analyze potential threats (sources of a security breach, e.g., unauthorized access to the e-mail account) and respective vulnerabilities (what can be exploited from that particular threat, e.g., weak password) and define controls to eliminate and manage that risk (e.g., a password policy in place that defines password complexity and frequent renewal of the password). Once you have analyzed your risks, you can assign priorities to particular types of risks. The benefits of risk assessment are twofold: priority, i.e., category is defined, as well as preventive measures to mitigate or manage such risks.
Whatever your risk assessment method looks like, one thing is certain – security-related incidents should be handled by Incident Management (or, in ISO 20000, Incident and Service Request Management). Use this article: Incident Management in ITIL – solid foundations of operational processes to learn more about the Incident Management process. In this way you will have efficient management of such incidents, with a defined process in place; activities, roles, and responsibilities; and a tool where all details are documented.
Once under control – what’s next?
Even if you have the perfect priority table or incident catalogue, there is always something you could do in order to be better. In the case of security-related incidents, to be better means that security incidents happen as rarely as possible. Therefore, you should analyze them. That means that you will look for the same kind of incidents, group them, and look for their root cause (that can include proactive Problem Management as well). Other criteria during analysis could be number of incidents or their impact.
The bottom line is that you are proactive. Once you start the analysis you will notice that many incidents contain common elements. Once you have eliminated those elements, you (most probably) will have resolved all such incidents in the future.
There is one more benefit of doing analyses – reports. Security-related incidents are sensitive. It could happen that they cause customer data loss (through, e.g., information leakage) or material costs. And that would interest your management. So, my experience is that you should be ready. Have your reports not only for your own reasons (e.g., improvement of existing processes or technological solutions), but also to answer some unpleasant questions from your management. Or even some public authority.
Lessons learned
I’m sure that you have experienced some kind of security incidents. And, most probably, you felt better when you were aware that someone (who works on resolutions to such incidents) knew what he/she was doing. Believe me, so will your users. Security incidents can be very painful (remember stolen credit cards or millions of e-mail accounts revealed), but it’s even more painful when users see that someone doesn’t know how to approach them.
To implement ISO 20000 easily and efficiently, use our ISO 20000 Documentation Toolkit that provides step-by-step guidance for full ISO 20000 compliance.
