We don’t do security because it’s fun. No: let me qualify that. Most of us don’t do security because it’s fun, but none of us get paid to do security because it’s fun[1]. Security isn’t a thing in itself, it’s a means to an end, and that end is to reduce risk. This was a notable change in theme in and around the RSA Conference last week. I’d love to say that it was reflected in the Expo, but although it got some lip service, selling point solutions still seemed to be the approach for most vendors. We’re way overdue some industry consolidation, given the number of vendors advertising solutions which, to me, seemed almost indistinguishable.
In some of the sessions, however, and certainly in many of the conversations that I had in the “hallway track” or the more focused birds-of-a-feather type after show meetings, risk is beginning to feature large. I ended up spending quite a lot of time with CISO folks and similar – CSO (Chief Security Officer) and CPSO (Chief Product Security Officer) were two other of the favoured titles – and risk is top of mind as we see the security landscape develop. The reason this has happened, of course, is that we didn’t win.
What didn’t we win? Well, any of it, really. It’s become clear that the “it’s not if, it’s when” approach to security breaches is correct. Given some of the huge, and long-term, breaches across some huge organisations from British Airways to the Marriott group to Citrix, and the continued experience of the industry after Sony and Equifax, nobody is confident that they can plug all of the breaches, and everybody is aware that it just takes one breach, in a part of the attack surface that you weren’t even thinking about, for you to be exposed, and to be exposed big time.
There are a variety of ways to try to manage this problem, all of which I heard expressed at the conference. They include:
- cultural approaches (making security everybody’s responsibility/problem, training more staff in different ways, more or less often);
- process approaches (“shifting left” so that security is visible earlier in your projects);
- technical approaches (too many to list, let alone understand or implement fully, and ranging from hardware to firmware to software, using Machine Learning, not using Machine Learning, relying on hardware, not relying on hardware, and pretty much everything in between);
- design approaches (using serverless, selecting security-friendly languages, using smart contracts, not using smart contracts);
- cryptographic approaches (trusting existing, tested, peer-reviewed primitives, combining established but underused techniques such as threshold signatures, embracing quantum-resistant algorithms, ensuring that you use “quantum-generated” entropy);
- architectural approaches (placing all of your sensitive data in the cloud, placing none of your sensitive data in the cloud).
In the end, none of these is going to work. Not singly, not in concert. We must use as many of them as make sense in our environment, and ensure that we’re espousing a “defence in depth” philosophy such that no vulnerability will lay our entire estate or stack open if it is compromised. But it’s not going to be enough.
Businesses and organisations exist to run, not to be weighed down by the encumbrance of security measure after security measure. Hence the “as make sense in our environment” above, because there will always come a point where the balance of security measures outweighs the ability of the business to function effectively.
And that’s fine, actually. Security people have always managed risk. We may have forgotten this, as we rush to implement the latest, greatest AI-enhanced, post-quantum container-based blockchain security solution[2], but we’re always making a balance. Too often that balance is “if we lose data, I’ll get fired”, though, rather than a different conversation entirely.
The people who pay our salaries are not our customers, despite what your manager and SVP of Sales may tell you. They are the members of the Board. Whether the relevant person on the Board is the CFO, the CISO, the CSO, the CTO or the CRO[3], they need to be able to talk to their colleagues about risk, because that’s the language that the rest of them will understand. In fact, it’s what they talk about every day. Whether it’s fraud risk, currency exchange risk, economic risk, terrorist risk, hostile take-over risk, reputational risk, competitive risk or one of the dozens of other types, risk is what they want to hear about. And not security. Security should be a way to measure, monitor and mitigate risk. They know by now – and if they don’t, it’s the C[F|IS|S|T|R]O’s job to explain to them – that there’s always a likelihood that the security of your core product/network/sales system/whatever won’t be sufficient. What they need to know is what risks that exposes. Is it risk that:
- the organisation’s intellectual property will be stolen;
- customers’ private information will be exposed to the Internet;
- merger and acquisition information will go to competitors;
- payroll information will be leaked to the press – and employees;
- sales won’t be able to take any orders for a week;
- employees won’t be paid for a month;
- or something completely different?
The answer (or, more likely, answers) will depend on the organisation and sector, but the risks will be there. And the Board will be happy to hear about them. Well, maybe that’s an overstatement, but they’ll be happier hearing about them in advance than after an attack has happened. Because if they hear about them in advance, they can plan mitigations, whether that’s insurance, changes in systems, increased security or something else.
So we, as a security profession, need to get better a presenting the risk, and also at presenting options to the Board, so that they can make informed decisions. We don’t always have all the information, and neither will anybody else, but the more understanding there is of what we do, and why we do it, the more we will be valued. And there’s little risk in that.
1 – if I’m wrong about this, and you do get paid to do security because it’s fun, please contact me privately. I interested, but don’t think we should share the secret too widely.
2 – if this buzzphrase-compliant clickbait doesn’t get me page views, I don’t know what will.
3 – Chief [Financial|Information Security|Security|Technology|Risk] Officer.
Alice, Eve and Bob - a security blog 
2 thoughts on “Don’t talk security: talk risk”