Frankly Speaking 8/23/22 - Security needs more second-order thinking

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

If you enjoy my posts, please consider using your professional development budget to pay for a yearly subscription! It helps keep this blog going.

LET’S BE FRANK

I was reading this article about how smart people use second-order thinking to outsmart others, and it inspired this week’s newsletter. Honestly, I’m a bit tired of people telling me that cybersecurity is a cat-and-mouse game. It is, but it’s no different than developing features or a platform — you develop a feature, it will have bugs, you fix the bugs, then there will be more bugs, and it keeps going. However, after reading the article, I understand why people might believe in the futility of the security industry. I believe the main reason for this belief is that security suffers too much from first-order thinking, especially when attackers tend to use second-order thinking.

In this newsletter, I’ll talk about the following:

• First and second-order thinking

• Why the current state of the security industry is a result of too much first-order thinking

• How we can use second-order thinking to improve a company’s security posture and possibly the security industry

First and second-order thinking

The article does a good job talking about first and second-order thinking, so I won’t try to re-summarize it here. It’s short, so I encourage you to read it before proceeding to the rest of this newsletter.

However, I do want to re-paste this Ray Dalio quote from the article:

“Failing to consider second- and third-order consequences is the cause of a lot of painfully bad decisions, and it is especially deadly when the first inferior option confirms your own biases. Never seize on the first available option, no matter how good it seems, before you’ve asked questions and explored.”

—Ray Dalio

First-order thinking is simple and generates a solution that just addresses the current problem. However, it fails to consider additional problems that might result from the solution. Sometimes, the additional problems actually make the situation worse. That sounds a lot like what happens in cybersecurity!

However, I want to disclaim, as the article also does, that second-order thinking is incredibly difficult and is by no means a perfect science.

The current state of the security industry

There is a common complaint that the security industry has too many tools, and every CISO wants to reduce the number of tools. Unfortunately, they are the problem! They are the ones buying tools in reaction to some security breach or new “trend.” For example, CISOs bought CSPMs as a result of cloud adoption which led to open S3 buckets. CISOs, in the past 2 years, have been buying tools that have been marketed to prevent ransomware. I say “marketed” because it’s not actually clear if many of these tools work or actually solve the fundamental problem. I’ve written about this issue in the past where I discuss why all security products suck.

Marketing departments at these security companies are preying on this type of first-order thinking, and good for them! I don’t blame them. They are just doing their jobs, but I do blame the security professionals who are falling for these tactics and then complaining they don’t help.

Compliance also further fuels the issue, and it’s common for naive security teams to conflate compliance and security. Don’t get me wrong. You should meet your compliance requirements and buy tools that help you achieve that in the lowest effort way possible. But, you should understand it for what it is — to check a box. The problem with these types of tools and solutions is that it chains two first-order thoughts, believing it’s second-order thinking. Let’s take the following example. A team buys a product for compliance, and it produces alerts. As a result, the team believes these alerts need to be resolved to improve security and concludes this tool enhances security. Each of those two thoughts is individually a first-order thought. They believe it’s a second-order thought — improving security posture through alert detection and resolution even though the original purpose was compliance! It’s not even clear how this tool is improving security posture because it’s not clear what security problem (other than compliance) this tool was originally solving.

With that said, it’s also common to hear that despite a large number of tools, security at companies doesn’t seem to be improving. In my opinion, this can again be attributed to first-order thinking. CISOs buy tools to solve problems, but they don’t think about the consequences of these tools. These tools might require new processes. Maybe the tool isn’t that great, so they need to hire people to maintain it. Similarly, the tool might cause friction in the engineering organization. They might need to buy another tool to help this tool be more effective. The list goes on, but it all started when the CISO bought a tool that he/she thought would solve a problem without thinking about the consequences of having this tool and losing sight of what problem it solves.

Second-order thinking to the rescue!

How do we solve this problem? To be clear, I don’t have all the solutions (or even any solutions). I’m merely saying that first-order thinking is dangerous and might cause more problems than it solves. As I said in the beginning, second-order thinking is hard and requires substantial context to do properly. As a result, solutions will most likely differ from organization to organization. In other words, even if I wanted to provide a “universal” solution, it might not work well for everyone.

However, there are some principles we can use to ensure we limit poor decisions made based on first-order thinking. First and probably most obvious, don’t react immediately to a breach or a trend. It’s important to truly understand the problem. In engineering, we have retros for incidents and design reviews for new tools to ensure we are solving the actual problem, and the solution is considering the right tradeoffs. Security should adopt these practices.

For example, the core problems in the cloud are actually not solved by CSPMs. They detect problems, but many tools don’t provide clear solutions. In fact, the problem perpetuates as engineering teams scramble to find solutions. Most S3 buckets are caused unintentionally by careless infrastructure as code templates, so it seems that the solution here is to provide some guardrails and scanning around those templates and use CSPMs to detect when someone accidentally opens an S3 bucket in the console or through some other mechanism. This seems more productive than chasing down all the alerts in the CSPM with processes and additional staff. Similarly, CSPMs find problems with IAM. A solution might be to have a good IAM story and use CSPMs to detect drifts in that IAM story. It seems CSPMs isn’t the solution but rather a way to detect drifts in a broader cloud security strategy.

Next, it’s important to think about what happens if the tool doesn’t actually solve a problem. Will I need more staff or better processes? What if no tool solves this problem? Is this problem actually an issue that substantially worsens our security posture? Just asking these extra questions helps prevents a solution actually worsening the original problem. These questions are particularly relevant as many companies are resource and time-constrained. Even if the solution works well with additional staff, are the time and resources better spent elsewhere?

Finally, it’s important to have a good incident detection and response strategy. Even if you do everything right, there are a lot of unknowns and variables that might lead to an incident, e.g. zero days, bad supply chain, etc. I am constantly frustrated when others say that doing certain security tasks reduce the probability of an incident. Sure, it might, but there are two issues. First, how are we calculating this probability, and does the effort required to reduce the probability in a meaningful and material way? Second, is effort better spent elsewhere? The second question is always a tough one, and it depends on an organization’s risk tolerance. Having a solid incident detection and response strategy will limit the impact of a potential breach or threat. In some ways, incident response is second-order thinking. It’s thinking about how to manage the consequences of gaps (known and unknown) in a security program.

Unfortunately, this is one of my more dire assessments of the security industry, but I do believe by being more thoughtful and asking the right questions, we can improve substantially as an industry.