Getting the message to the board
08:00 Wednesday, 28 July 2021
UK Cyber Security Council
One of the key roles of the cyber security team is the identification, assessment and reporting to senior management of the organisation’s cyber risks. Cyber security is a risk-based concept, after all: one starts by finding risks, following up afterwards with the relevant parties to mitigate the risks.
Except in the case of a security incident, in which case response takes priority, the single most important thing the security team must do is to inform senior management and the board, understandably and comprehensively, what risks exist, their individual severities (generally in terms of likelihood and impact) and their relative importance (which is derived in part from the individual risks’ severities).
Reporting is partly a technical skill, and partly a soft skill. Some of one’s cyber status can be quantified using solid, unequivocal numbers – for instance the number of “high” and “critical” vulnerabilities on one’s web sites as measured by one of the many commercial scanning services. Other risks are more qualitative, particularly when calculating (or, more correctly, estimating) the likelihood of a particular vulnerability being exploited by an attacker.
There are two simple rules for both quantitative and qualitative reporting, though: be consistent, and state facts, or as close to facts as you can get. This is because if you are measuring something in the same way each month, over time you can show that most important of things: a trend.
In this sense, some of the most useful skills in cyber security are often completely general and unrelated to security as a concept. For example, the ability to write a script to extract security data from (say) your Active Directory setup on a monthly, weekly or daily basis guarantees that you can plot today’s data against previous versions and make valid comparisons. Some intermediate Excel skills will enable you to automate that plotting to a large extent. Some SQL and Power BI skills will make it possible to automate the whole thing end-to-end – perhaps even giving the management and board teams a dashboard they can dip into at will. This doesn’t mean you as a security expert need to become, say, a shell script or SQL reporting guru: it’s perfectly fine to engage someone with the right skills so long as you’re able to explain what you need them to do.
We mentioned earlier that the reports must be understandable. You should endeavour, of course, to give regular training to senior management to enhance their comprehension of security concepts, but it would be unreasonable to expect them to understand more than the basic technical concepts – particularly if your organisation (and by inference the areas of expertise of many of the senior individuals) is not in a particularly technical sector.
A common approach in representing risk– cyber or otherwise – to lay people is a red/amber/green or “RAG” status. Everyone understands the premise that green is OK, red is very bad and amber is in the middle … but few realise that this basic premise is utterly insufficient because the most important element is often omitted: the key to what red, amber and green mean.
For example, let us imagine that the board report shows the risk indicator for web site vulnerabilities as “red”. At most, this simply says to the board that there is something that whoever wrote the report is very worried about: the inevitable response to the bad news is: “who says?” Let us now add some definitions, and assume that management have previously agreed that:
- green = no existing critical or high severity issues found in vulnerability scans this month
- amber = one or more critical or high severity issues found, but none of them has been found for more than two consecutive months (including this month)
- red = one or more critical or high severity issues, of which at least one has been found for at least three consecutive months (again, including this month).
Every risk appetite will vary, of course, and this is merely an example – but it demonstrates how a simple definition can take an apparently vague and subjective rating to something with a firm meaning. Not only this, but you can add just one further sentence to bat off the question the board should be asking: who says something is “critical” or “high” severity – by referencing widely used standards such as CVSS1 and vulnerability lists such as CVE2. Learning how to write definitions concisely and in jargon-free words of few syllables is a superb skill to learn if you don’t already have it. A few short words take the information from meaningless to priceless.
The final skill you will need for getting the message to senior management is that of speaking with senior management. We noted earlier that reporting facts is essential, which implies (correctly) that security reports should not be riddled with opinions. You should expect senior management to read the facts in your report and then ask you for comment or opinion on what is in front of them – which means you must have the confidence to answer them robustly. Much of this is down to experience, as the more you do it the more confident you become at it, but equally you can engage with coaches and mentors to build your skills and gain from their experience in parallel with building your own. And as the security specialist, why not engage directly, offline, with a handful of senior management or even one or two board members and build a relationship? It can be a tremendous boost to have, say, a non-exec director watching your back as you explain something unpalatable at a board meeting – and potentially to be better prepared by asking his or her opinion before the event.
Reporting security matters to senior management is therefore a two-faceted concept. Gain the skills you need to make reporting easy, clear, factual, consistent, and as automated as possible, so that you spend as little time as possible doing it. Then focus the rest of your learning on the soft skills around your actual interactions with management and the board.