We don’t do security because it’s fun. No: let me qualify that. Few of us do security because it’s fun – and none of us get paid to do security because it’s fun (sadly.) Security is a means to an end, and that end is to reduce risk. This was a notable change in theme at the recent RSA Conference in San Francisco. 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 for 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 birds-of-a-feather type meetings, risk is beginning to loom large.
[ Read also: 7 security to-do's for CIOs in 2019 ]
I ended up spending quite a lot of time with CISO folks and similar – CSO (Chief Security Officer) and CPSO (Chief Product Security Officer) are two of the favored titles – and risk is top of mind as we see the security landscape develop. The reason this has happened, of course, is that we - the security community - didn’t win.
Breaches: Not if, but when
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 we’ve seen, nobody is confident. 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 “defense 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 organizations 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 (and thoroughly buzzphrase-compliant) security solution, 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.
Boards must understand an organization’s specific risks
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 (Chief Risk Officer), you need to be able to talk to them about risk, because that’s the language that they - and their colleagues –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 CFO/CISO/CSO/CTO/CRO’s job to explain – 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 organization’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 organization 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.
[ How do containers help manage risk? Get the related Red Hat whitepaper: Ten Layers of Container Security. ]
