Blog
Recent
bg
LastPass Labs

Reasonableness vs. Perfection in Cybersecurity

Alex CoxJune 04, 2024
Reasonableness vs. Perfection in Cybersecurity

So many senior leaders approach cyber with the expectation of "perfection". No malware, no network events, no distributed denial-of-service (DDoS), ever. I've long argued that you should view the security of your firm through the lens of "Was this attack stopped before it caused major impact (material issue)?" instead of "We need to prevent all attacks." Preventing all attacks is an unreasonable expectation; while stopping an attack before major impact is attainable.  

 

Defense in depth is there for a reason.  

 

Defense in depth is a strategy that uses multiple security measures to protect an organization's assets. An analogy I like to use here is a king in a medieval castle. The king has his throne room and guards and the throne room is in a fortified location in the castle. The castle is surrounded by high walls and towers, with archers and pots of hot oil atop the battlements. The walls are surrounded by a moat, with a drawbridge that allows access, and alligators in the moat. Any one of those is a decent defensive measure, but combined they are a deep defensive system. This is Defense in Depth. The goal is to stop attacks before they happen, but if one line of defense is compromised, more layers exist as a backup to thwart attacks along the way, preventing further damage.  

  • A single malware infection on a workstation that's handled by AV/EDR isn't a "near-miss"it's your defense in depth working.  
  • A DDOS that's mitigated by your DDOS provider isn't a "near-miss"it's your defense in depth working. 
  • Your DLP system stopping an employee from sending work home isn't a "near-miss"it's your defense in depth working.  

This is typically a huge issue in the financial sector, with regulators, who are not as experienced in cybersecurity and have unreasonable expectations around cybersecurity, and, as a result, companies in the financial sector have monstrous teams with billion-dollar budgets. The expected response by the check-writers is likely “We’re giving you a billion dollars for cybersecurity; how did we have a malware infection?” 

 

It's important to understand your industry, understand the threats to your industry, understand the mechanisms you'll use to mitigate those threats, and ultimately be able to explain the how and why of your program to those who have a need to understand. Two former managers taught me a few things around this. "Kill them with data," and "Perfect is the enemy of good!" Collect the data you need about threats - targeting and your industry - and design a “good” program that addresses those things in an interconnected manner. Then work on perfecting the program over time once you have a base capability.  

 

Years ago, when I was a police officer, I remember asking my training officer, "How do I make sure I'm doing the right thing? Making the right decisions?" His response has stuck with me my entire career. "Rely on your training and experience and be able to articulate why you made the decisions you did." That’s still true in my role as a cybersecurity leader today. If you can explain the how and why based on data and experience, it’s hard to argue against it, especially from a less-informed viewpoint.  

 

Key cybersecurity principles. 

  • Understand your industry. What are your crown jewels (e.g., data)? Do your peers have a good cybersecurity program already?  
  • Identify and study your attackers and threats. In the last 6 to 12 months, what types of cyber-attacks has your industry seen? Who is perpetrating the attacks?  What tools, tactics, and procedures are they using in their attacks? Where are you vulnerable to those attacks and how would an attack chain take advantage of those vulnerabilities? 
  • Understand mitigation efforts. Based on the above, what are the mitigating technologies, techniques, and processes for those attacks? How would they fit into your organization and existing program? Are they complimentary to each other? Do you have the proper data view to be able to investigate events (logs, artifacts, etc.)? 
  • Define your process. Can you explain your methodology in a way that makes sense to others?  

The bottom-line is don’t accept the status quo of out of the box security and don’t let someone else design YOUR security program!