ACTING (like we care about) Securityms: Focusing on Risks, Outcomes, and Business Value

This will be my last entry on the topic for a while. For context, I introduced the idea that folks don’t care about security; they care about outcomes in this post, and then I began exploring ways we, as IT practitioners, can shift the focus to the results and, therefore, contextualize the actions needed as something other than “security for the sake of security.” In this post, I’m continuing with that line of discussion. What can we DO to make our environments more secure, and how can we get our colleagues to understand and want to do it?

Focus on Actual Risks and Realistic Outcomes

(or: Don’t let “perfect” be the enemy of “good”)

When doing your homework to build those aforementioned risk profiles, you need to be open to the possibility that whatever you’re trying to fix doesn’t represent a material risk or isn’t as big of a deal as you initially thought.

On the other hand, sometimes the risk really *IS* that bad, yet the company seems unwilling to discuss it. There are two things to keep in mind:

1. Remember that “accept” is one of the options for risk management. The trick is getting someone to sign off on that acceptance formally. Implicit acceptance is the worst kind of risk acceptance and is usually a sign of a communication breakdown. If the best you can get is a verbal “It’ll be fine; you worry too much!” then you might have a much more considerable risk on your hands:
2. Second, consider that the organization didn’t really hear (or internalize) what you’ve been saying. They’re refusing to listen now because they haven’t been part of the journey up to this point. Your next step isn’t to throw your hands up but rather to retrace your steps and discover where the disconnect happened.

I won’t lie; this is where the politics and interpersonal element can be its most frustrating – it’s incredibly difficult to go back and reiterate everything you’ve already said, to go through the act of what feels like smoothing ruffled feathers and soothing fragile egos. But like ANY relationship, communication (and its lack) always sits at the point between moving forward and getting caught endlessly in the past. That doesn’t mean you have to be everyone’s punching bag. But just as I suggested at the beginning of this section, you need to be open to the reality that an issue you perceive to be a risk might not be that big of a deal; so to do you need to be open to the possibility that your first attempt to communicate didn’t work that well, and you need to admit that to everyone and try again.

“We’re from the government, and we’re here to help.”

As I hinted at earlier, NIST is aware of this issue and is attempting to bridge the gap between organizational/leadership goals and objectives and the value that infosec can provide. One of the primary outputs of this effort is the “Integrating Cybersecurity and Enterprise Risk Management” document.

One of the authors, Bob Gardner, calls it “making the connection from the adversary to the wiring closet to the board room.”

This document (along with other content in the 8286 series) underscores NIST’s understanding that what businesses want from cybersecurity is a contribution to risk management in terms of mitigation, avoidance, transfer, etc.

The NIST series extends (and aligns with) an earlier plan, OMB Circular A-123, which directs Federal agencies to develop a formal “risk profile” (sound familiar?) and use it to combat cybersecurity threats.

But the assistance and insight doesn’t end there. Sometimes, the answer to “what are we supposed to do about this” is hidden within the very security policies and frameworks companies are bound to comply with. Whether you’re talking about HIPAA, PCI-DSS, SOX, GDPR, or any one of the many other acts, provisions, or guidelines; there are usually goals and achievable objectives described.

In this regard, Samuel Svarc points out: “These schemes don’t mandate specific technical steps (e.g., Advanced AV, password manager, etc.) but rather broad categories of requirements (“company will create reasonable password policies,” “company will take reasonable measures to secure computers from common threats,” etc.) that are open to interpretation… ” and yet provide a reasonably clear path forward.

Furthermore, Svarc says, “…if a company can show that they conducted a real risk assessment which was then substantially followed, they will be treated differently than a company that didn’t. A company that has a current firewall, Advanced AV on workstations, ZTNA for remote workers, Bitlocker on all laptops, password managers, and FIDO keys with 2FA, normal logging monitored by competent SOC, is in a totally different place security-wise than a company that has laptops running around unencrypted, or without 2FA turned on (to mention two low hanging security steps).”

Security by any other name

A long-running discussion I’ve had with Kymberlee Price revolves around the definition of security and why we are (or should be) concerned about it at an organizational level. Security continues to be presented as a technology in its own right when, in fact, it’s truly about improving quality. “Quality code,” Price states with the authority of someone who’s spent over 25 years working in the security space, “is reliable. Quality code is secure.” She’s championed for a while, and it’s gaining traction in the industry at large.

Tell a developer their code has a security issue, and you will not likely get more than a passing glance. After all, “shift left” was recognized as corporate double-speak for “one programmer does the work of two people for the same pay,” shortly after Larry Smith coined the term in 2001. Using it to mean developers should test their own code for security only increases the resistance.

However, tell a developer their code has a quality issue, and you’ll have their full attention.

“Security is actually quality by a different name” is more than a marketing spin; it’s a message meant for more than the coding crowd. If a business’ processes, policies, or products have overlooked or under-emphasized security, it’s highly likely that other aspects got short shrift as well. And that speaks to low quality. Conversely, if security has been fully considered, it’s far more likely the other aspects have also been reviewed and confirmed – if for no other reason than the fact that the job of security teams is to ensure those elements have been reviewed in the first place.

What I’m getting at is that security is one of the fundamental aspects of any business, tightly bound to everything from design to delivery. Pretending otherwise and treating security as some completely separate discipline that’s divorced from poor outcomes in success, velocity, and even profitability is how we ended up in the current situation in the first place.

Summary

It’s difficult, if not impossible, to argue that backups aren’t important for the simple reason that the value they provide (i.e., the ability to restore data) is intuitively obvious to every level of the business, from executives on down.

Security has failed to enjoy organizational support simply because the methods of creating a secure environment are much more complex, the types of threats are much more varied, and the surety of the outcomes is much less assured.

In my opinion, this is due to the fact that the focus of so much of the infosec narrative has been on the technology and its delivery. This is equivalent to the backup operators making their case by describing the differences in DAT tapes vs. optical vs cloud or the benefits of full backups vs. incremental vs differential. Again, nobody cares about that stuff. Instead, infosec practitioners should shift their narrative to emphasize the business benefits of quality, resilience, and increased value.

Put succinctly: Nobody cares about security, but they sure as hell care about increasing revenue, reducing cost, and removing risk. Your job is to champion the truth that, in order to have those things (revenue, etc), the business needs to invest in security across the organization.