Spending money on cyber security doesn’t prove an organization is getting better at it.
Ask Nicholas Johnston, Toronto-based vice president of the global data risk group at Duff & Phelps, an international consultancy.
“It is painful how many people are not doing detect and respond,” he said in an interview. “They put in a big firewall and then not do anything else. Having logs and firewalls is great, but if nobody’s looking at it, it is doing absolutely no good.”
Which is why having a formal system for measuring cyber security maturity is essential these days.
It is increasingly being demanded by boards to help direct improvements in cyber security risk management. But it has to be done rigorously and not by collecting random metrics like the number of incidents faced, patched systems or how many compliance boxes have been checked off.
Infosec leaders have a number of security maturity models to chose from including the U.S. National Institute of Standards and Technology’s (NIST) Cyber Security Framework, ISO 27001, The Open Group’s O-ISM3, the Information Security Forum’s Maturity Model Accelerator Tool and the Information Systems Audit and Control Association’s (ISACA) COBIT.
They usually include a scoring system gives a fast indicator of which security control processes are under-achieving or need to be tuned against security targets.
To get an idea of how an infosec team should use a model, we asked Johnston to take us through the first section of NIST’s framework.
Johnston, who has helped organizations implement security maturity models, likes NIST because it’s organized like a project.
The core of the framework sets out five functions: Identify, Protect, Detect, Respond and Recover. Within each function are related categories with activities to be analyzed. For example, under Identity are Asset Management; Business Environment; Governance; Risk Assessment; and Risk Management Strategy.
“It’s a nice, easy model” says Johnston, with clear tier scoring definitions:
1 — Partial: Organizational cyber security risk management practices aren’t formalized
2–Risk management practices are approved by management but may not be established as an organizational-wide policy
3–Risk management practices are expressed as policy
4–There is a process of continual improvement.
Successful implementation of the framework is based on achieving outcomes in the organization’s target profile based on business needs. But the scoring can be used to show progress.
NIST warns against using the framework as a one-time check for measuring security maturity. It’s really a snapshot, says Johnston, which can be taken to management with the question, “Are we comfortable with where we’re at?”
You don’t have to get to level 4 if you don’t need to in every category, he adds. The question is will doing so change the risk profile?
Before starting, a CISO should assemble the documentation the security team already has, including information and security policies, incident response plans, documentation on security controls. Then go through the sections in order.
We’ll do the first page of Identity, which covers Asset Management, to get an idea of what has to be done:
The centre section lists processes to be documented, while the right hand column are references to standards that may have to be adhered to for regulatory reasons and will help in figuring out what has to be covered.
Arguably the first two steps are the easiest:
1 – “Physical devices and systems within the organization are inventoried.”
2–”Software platforms and applications within the organization are inventoried.”
But Johnston says too many IT departments – especially in small and medium sized businesses – don’t do it. Asset management software can be a boon here, particularly in finding unauthorized cloud applications, Wi-Fi routers and plug-in desktop storage.
Organizations with bring-your-own-device (BYOD) policies may have to inventory all staff devices. Or the CISO may have to limit the scope of this category to only IT-controlled devices.
“Inventory is so critical,” Johnston says, “and many people do not have a handle on it. It’s one of those easy things to do once, but you have do it frequently.”
3- “Organizational communication and data flows are mapped”
This covers how data moves through the organization – for example, what happens when a customer signs up for a service or product on a Web site. It will likely help that a physical inventory has been done (remember step one?).
Data flow diagrams can be used for documentation, or a simple description. But these days, with data stored not only on premise but also in the cloud, finding paths can be tricky but every process has to be mapped– including, for example, if a staffer pulls data from a database for a report and emails it to another employee.
4–”External information systems are catalogued”
This covers everything outside the firewall, including cloud services and the supply chain. Is there third party hardware in your data centre, an on-premise Google device you don’t have full control over that indexes and searches data?
5 –”Resources (e.g., hardware, devices, data, time, and software) are prioritized based on their classification, criticality, and business value.”
Ranking services will become important later in the process when looking at safeguards and security controls. But, Johnston says, the team has to determine the relationships of pieces. So X may be valuable, but only if it’s fed by Y database.
6–”Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established”
Who – internally or among third parties – is in charge of data protection? Are they trained, is there documentation that says only only authorized personnel can have access to certain data?
This is just a quick look at the process of completing the NIST framework, which covers 18 pages. The infosec team’s first attempt at it might be ragged. Johnston says some pieces may benefit from a consultant’s outside eye. It may take a few weeks to do a first draft, and longer to get a more solid document.
The smaller IT staff the harder it can be, Johnston acknowledges, but starting small is better than nothing. Look, for example, at the high level categories to and ask if those steps are being done. Over time the work can be refined. Asking questions such as ‘Do we know what we have (in hardware and software)? Do we have some safeguards in place? Do we have some kind of detection? Are we looking at the network? In the event of an incident do we know who to call? Do we have backups?’ are a good start.
“What you will see in a small organization is maybe they’ve invested a lot in protection: They make a one time spend of $40,000 on a firewall. Well, maybe they’ve gone from a zero to a three there. But they’re not doing any of the other stuff, which is disastrous. It would be better to be doing all of these [in the framework] at a 2 than one of them at a 4.”
(For more on security maturity see the May edition of Digital Security magazine)
