Risk assessments are one of those things that system administrators of larger companies are often asked to get involved in. Most system administrators consider this a waste of time that could be better spend keeping the systems running. Even when the system administrators aren’t directly involved in the assessment, they invariably get more work as a result of someone else’s risk assessment.
In this article, I shall attempt to help the system administrators understand why these risk assessments happen and how being involved in a risk assessment can help the system administrator do a better job.
A risk assessment is a formal process, typically carried out by people who sit in an unusual position in the company called IT governance. These people have the odd job of trying to translate corporate management and business need into information technology terms and back again. The risk assessment process itself is fancy formal process meant to identify all the assets of the company and the risks against them. It then takes those lists and sets priorities.
In my opinion, one of the big failings of the process is that most of the formal processes talk about enumerating the technology in terms of systems. The real assets are not the systems but the data in those systems. This article isn’t meant to debate the merits of the risk assessment process, but to help people who get stuck at the end of it better understand the process.
So, step one is to enumerate all the systems (at least those in the target scope of the risk assessment). Step two is to enumerate all the sources of risk to those systems.
How does this help the system administrator? For starters, there are going to be systems on the edges of the “target scope” like unofficial admin systems and old network hardware. An admin that is involved from the start can either down-play or highlight these systems to get them into (or keep them out of) the risk assessment. As part of the risk assessment you have the opportunity to argue for more resources to upgrade/replace those systems or to keep management from noticing them.
Be careful here. This can backfire. Get an unofficial admin system noticed and it might be taken away instead of replaced. Get it noticed and there might be a lot more work maintaining it once it’s official and needs to go through change control. Keep it hidden and if it becomes the source of a problem you might get in trouble for not identifying it. The trade-offs can be rough.
Next up is risks. Risks are another trouble spot. They can be anything from elite hackers to nearby train tracks. The key to including a particular risk in the risk assessment is two fold. First there needs to be good 3rd party documentation about it. Articles in professional magazines that the management types recognize or white papers published by information security and audit companies. The second is some details that can support how likely this risk is to be a problem. Industry reports of recent events or statistical papers of historical occurrences. Again, sources that management understand are important.
Good sources of material to management are not the same as good sources to technical people. In fact, they are often quite opposite. Wikipedia would not usually be considered good from a management perspective but the sources that the Wikipedia article references might be. Likewise 2600 magazine and wired are not going to be good sources to management. On the other hand, Business Week, the Wall Street Journal, and white papers published by Deloitte, Trustwave, or most of your corporate vendors will be sources that management trusts.
These sources are not an exhaustive list and may not be accurate for all organizations. If you can find out where the management in your organization get their news, that’s a good start.
The key to all of this for the system administrator is to identify risks to specific systems and point them out to the people writing the risk assessment. More risks and risks with a higher likelihood are likely to get a system more attention.
Understand of what went into the risk assessment report helps to understand why management is putting increased focus on some things and less focus on other things. If that key system that keeps everything running smoothly is ignored, there may not be sufficient resources to keep it that way. If a minor system gets too much focus the administration staff may find they are spending too much time on something nobody really cares about.