Walk into the average business and you’ll find the information security function and the risk management function in different places, writes Andrew Lintell, VP of EMEA, FireMon. Sometimes this is because of a misconception about where information security belongs; sometimes it’s because of a misconception about where it doesn’t belong.
On the surface, security management is something that techies do. Wouldn’t it be great if, without any real technical skill, you could tell the infrastructure to make certain services available to particular parties, and block access to everyone else? Well, you can’t: for the foreseeable future you’re going to need some technical ability. And you generally find that in the IT department.
But think for a moment about what security management does. Part of it is about designing and implementing the security settings of the infrastructure, but is this really a very big element? At installation time it is, of course: the initial configuration task can be gargantuan and highly technical. But the ongoing task is neither – in fact, it can be mundane and repetitive. It’s all about monitoring, recording, reviewing, managing change, conducting audits.
We mentioned earlier the concept of where security management doesn’t belong. The risk management people have traditionally assumed that information security doesn’t belong with them … or in many cases they’ve probably not even thought about it. But that’s going to change.
Information security standards aren’t actually information security standards: they’re risk management standards.
For instance, as section 0 (the very first bit) of the ISO 27001 standards document puts it: “The information security management system preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed”.
Risk gets two mentions in paragraph 2, and on one page it’s mentioned a whopping 17 times. Information security is the same as risk management.
A security audit generally has the auditor asking questions of the auditee, with a techie on hand to pull the necessary data out of whatever systems need to have data pulled out of them. In 2020, that’s going to change.
Why do we need technical support to pull information out of systems? We already have the technology to provide auditors with the data they need, in a way that lets them ask for it directly themselves.
It’s no different from board reports in that respect – modern software lets us take source data and produce non-technical reports without the need for an organic life-form to hack it about on the way. Of course, as well as reducing human effort this also means that we can eliminate the step where someone gets to “clarify” the data and make the bright red flag look a little more green; some may well consider this a good elimination.
Oh, and while we’re asking the “why” questions, why do we only do periodic audits? The January data isn’t audited until the auditor lands in October … but why? It’s there all year, and we have the tools that we need to use it all year.
And that’s where information security management will go. First of all, we’ll realise that management is 10 percent configuration and 90 percent looking. Then we’ll realise that because we now have tools that take a complex collection of information and make it visible in a simple way to lay readers – auditors, say, or risk managers. Then those risk managers will realise that if they’re asking the same questions of the same data every time, that could be done more efficiently – and less boringly – by an automated routine on a computer. And then they’ll simply get the technology to write the reports, and to alert them if something isn’t aligning with what it should look like.
At which point they’ll realise that information security management and risk management are, in fact, the same thing.
Read this: Botched Windows 10 Security Update was Meant to Revoke a Vulnerable Kaspersky Bootloader
