Starting to Care About Security

(This post originally appeared on AdatoSystems.com

In my last post, I discussed the issue of getting people to care about security, and how it’s largely due to a focus on security behaviors rather than security outcomes. In this post I’m picking up where I left off, and will talk about…

Forging a path forward

Obviously, the point of sharing this post (and the last one) is to do more than just complain about the situation. This will only be useful if it offers ideas and suggestions for approaching the problem differently and moving past it to a more successful outcome. So, what actionable advice do I have?

Speaking the Language of Business

I’ve written about this before, but it’s worth reiterating here: We IT practitioners need to learn what matters to the business and then frame our goals and needs in those terms. No matter how different we wished it was, nobody ever got a PO approved by describing the technical capabilities of a new firewall to the CFO.

If it bothers you, having to learn to couch your critical technical and security needs in business terms, consider this quote from Bob Lewis, which holds as true today as it did when he first said it back in 2004: “There’s no such thing as an IT project. There are only business projects with an IT component.”

What does that mean from a functional perspective? 

Lesson 1: The only two things that make people buy a product are “discomfort” and “convenience.” Discomfort will win every time. 

Lesson 2: There are only three things a business cares about: Increasing revenue, reducing cost, and removing risk. You need to speak to (at least) one of those things to make your case. 

Lesson 3: Know what’s important. Which systems does the business consider critical to its continued financial success? Those are the ones you’ll want to focus on in terms of risk assessments.

One of the InfoSec experts I spoke to in preparing this blog put it this way: “In my firm, the biggest financial risk is reputational damage, so the CISO’s pitch to the board is framed in terms of how it affects that.”

If that angle works for you at your company, you should absolutely pursue it. In many companies, the concern about ransomware remains that it interrupts services, which in turn stops the money-making machine. That, in addition to the cost to recover, is concerning enough to catch many executives’ attention.

Lesson 4: Know when it’s important. While it might be true that some systems are critical all the time, some times are more critical than others. For some businesses, it might be Black Friday, while for others, it might be the end of the year, tax season, or summer break. Whatever it is, you need to understand your organization’s financial rhythms to time your messaging (and your work). 

As an IT practitioner who cares about information security, you’re probably familiar with the concept of “situational awareness.” This is equally true for an IT practitioner who wants the business to approve their work, initiatives, and budget. You will only be effective in executing a plan by first understanding the pre-existing opinions, pain points, needs, and timelines of the people you’re trying to convince. 

Say it with flowers data

IT folks should appreciate that data is your business’s love language. Infosec professionals must bring facts to make a compelling argument. 

Let’s start by using data to refute some of the commonly held beliefs I mentioned earlier in this post:

Contrary to what many managers believe, reputational damage resulting from a breach DOES have negative impacts. In discussing this topic with Zatik Security CEO Kymberlee Price, she pointed me to a post by Dr. Erdal Ozkaya. According to Dr. Ozkaya, business impacts of security breaches include: 

• An immediate 3-5% drop in stock price, typically driven by investor concerns.
• Underperforming in the market for several years afterward.
• Eroded investor confidence, leading to long-term lower stock valuations.
• In some cases, a credit rating downgrade.

Any one of those things should be enough to grab the attention of the C-suite. Taken together, they become a compelling argument for an improved security posture.

Ms. Price also let the air out of the tires of the whole “it’s cheaper to pay for insurance than for security” myth. She points out that various new laws coming into effect in Europe call for fines of 2% to 7% of an enterprise’s global annual revenue for violations of each law. This means that a single incident leading to a data breach may trigger multiple instances of revenue-based fines — and that’s just in Europe. When you consider other jurisdictions that are following the EU’s Brussels lead, this adds up fast.

Samuel Svarc, owner of CompuMedic Solution, echos and extends this thought: “Cyber liability insurers, due to the complex realities and prevalence of hacking, are mandating that companies certify that they are mitigating their risk and reject claims where these were falsely attested to.”

There are many other reports, sources, and data points you can bring to bear in your discussions. The problem with my listing them here is that they aren’t guaranteed to be specific to your circumstances, industry, or even the point you’re trying to make. Instead, I suggest you structure your discussion points using the guidelines in “Integrating Cybersecurity and Enterprise Risk Management” from NIST. In that document, it suggests you develop a formal “risk profile,” use it to identify risks and assign impact estimates, and then build a risk management plan (including cybersecurity) with the intent of having the business decide whether (and how) they will mitigate, avoid, transfer, or accept those risks. 

As a final thought on this topic, look for places where your goals and interests align with other teams. A great example of that is automation, a beloved topic among your DevOps and SRE teams. Putting your weight behind their efforts to automate can help get more automation rolled out – reducing risks associated with human error while increasing efficiency- and creating a powerful organizational alliance. Another is metrics and telemetry – something your monitoring and observability folks will happily discuss at length. 

There’s still more ground to cover.

I’ve started to identify the things you can do to encourage and promote healthy infosec behaviors, but there’s still more. Stick with me until the next post, where I lay it all out.

And if you have any questions, corrections, or kudos to share in the meanwhile, I’d love to hear them in the comments below.