By Rick Howard

May 11, 2020

CSO Perspectives is a weekly column and podcast where Rick Howard discusses the ideas, strategies and technologies that senior cybersecurity executives wrestle with on a daily basis.

Cybersecurity first principles.

Listen to the podcast episode.

Note: This is the first essay in a planned series that will discuss the development of a general purpose cybersecurity strategy for all network defender practitioners-- be they from the commercial sector, government enterprise, or academic institutions-- using the concept of first principles. This first essay discusses what first principles are in general and what the very first principle should be for any infosec program.

The CISO’s world can be daunting. There always seems to be way too many things that we must do in order to protect our organizations from a cyber attack. In my early days, I struggled with this. The projects that me and my teams pursued became an endless collection of things in the to-do pile with no priorities. This day-to-day grind eventually devolved into fixing the crisis of the day. Whatever fire popped up that day was the thing that we would throw all of our resources toward. The crisis became the priority. And because that is all we did, we never put into practice anything that would prevent the fires from popping up in the first place. All of those fires are known in the industry today as technical debt. You can never move forward to innovate for your company because you spend your time every day fixing and updating the things that you have already built. There is not time to add new things because you are constantly trying to keep the old things up and running. Doing the job in that old fashioned way is exhausting. I would get overwhelmed with the number of things on the to-do list that seemed to grow faster than I could address them. And forget about measuring any kind of forward progress other than counting the things in the “done” pile. I needed another way.

As an aside, this situation is exactly the subject of the Cybersecurity Canon Hall of Fame book, The Phoenix Project. That book was my introduction to the world of DevOps and DevSecOps and how automation, and the management of that automation, can help you reduce that technical debt and move forward with your security program. But at the time, DevOps hadn’t become a thing yet and I was struggling.

And then I listened to an NPR story about two British mathematicians, Alfred Whitehead and Bertrand Russell. They published a book, Principia Mathematica, in 1910 that attempted to rebuild the language of math from the ground up using a small set of first principles. They recognized some inconsistencies in the current set of rules used by the math community at the time. You could use the same rules to get two different and absolutely correct results; something called the Russell Paradox. In a precision engineering world, that was a recipe for disaster. So, they went back to the drawing board, threw everything out, and started from scratch. It took them 80 pages to mathematically prove that 1 + 1 = 2. In a footnote, Whitehead and Russell famously wrote this line:

"The above proposition is occasionally useful."

And you all thought that math nerds were not funny.

The idea of first principles has been around since the Greek age of sophistry. Aristotle spoke about the concept some 300 years B.C.E.:

"In every systematic inquiry where there are first principles, or causes, or elements, […] science result[s] from acquiring knowledge of these.”

Two thousand years later, Rene Descartes talked about the concept in his book, Principles of Philosophy, published in 1644:

“… in order to study the acquisition of [knowledge], we must commence with the investigation of those first causes which are called Principles.”

In our modern day, when asked about how he approached the concepts of electrical autonomous cars, affordable solar energy, and economic space flights, Elon Musk didn’t say that he looked at what NASA and Boeing had done during the Apollo and Space Shuttle missions and took the next step. Instead, he threw all of that out and started over with first principles; a gutsy move for sure but that is probably why he is a gazillionaire and I am not.

First principles in a designated problem space are so fundamental as to be self-evident; so elementary that no expert in the field can argue against them; so crucial to our understanding that without them, the infrastructure that holds our accepted best practice disintegrates like sand castles against the watery tide. In other words, you get the Russell Paradox. They are atomic. Experts use them like building blocks to derive everything else that is known in the problem domain like Bertrand and Russel needing 80 pages, block by block, to prove a simple math concept. And that is the key. Each building block depends on the previous.

If this way of thinking seems as appealing to you as it does to me, the logical next question then is what is the network defender’s ultimate first principle? Where do we begin? What is the absolute first principle building block for the security professional? What is the foundation that we are going to install in order to build our entire infosec program wall on? As you can imagine, I have some thoughts about that.

Prevent all breaches or prevent successful adversary campaigns?

Back in the dinosaurs days before Apple invented the iPhone and we all used dial-up modems to access the internet and thought we were pretty cool doing it, my peers and I used to think that every security issue was a potential catastrophe. We would run around in the hallways like our hair was on fire screaming at anybody who would listen that the wolf was at the door and if we didn’t do something right now, the world might possibly end. Now that I am older and wiser— my wife would just say that I am just fatter and lazier— I don’t have the energy to do that any more. If I am honest with myself, that wasn’t the right approach anyway.

Many network defenders might be thinking that preventing all breaches is the ultimate first principle. But that is a fool’s errand. By pursuing that strategy, it leaves no flexibility to respond after discovery. And it doesn’t account for how you have protected your important data with your zero trust program. It leaves the defender no mauver room. If you want to go down that road though, it should at least be to prevent all successful adversary campaigns, not all breaches.

We know that cyber adversary groups have to complete a sequence of actions along the intrusion kill chain in order to be successful. If they successfully negotiate 99 out of the 100 actions, but fail the 100th, then who cares? They didn’t succeed. They successfully breached a victim-zero’s laptop but failed to negotiate across the rest of the intrusion kill chain to find the information they have come to steal or destroy. Preventing breaches is important, but it is probably not the most important thing.

If a cyber criminal gang compromised Kevin’s laptop but failed to steal anything from the company before we kicked them out of the network, is that a success story or a failure? By using the prevent-all-breaches metric, the Kevin situation means that I failed. In my mind, the truth is 180 degrees in the opposite direction. In my mind, the infosec team succeeded.

So, let’s not use prevent-all-breaches as our very first principle. But even using prevent-successful-adversary-campaigns as a first principle does not feel quite atomic enough either. It still feels too black and white, too binary. It needs more nuance.

Prevent successful adversary campaigns or reduce the probability of a successful adversary campaign?

What I mean about nuance is that we don’t want a strategy that is similar to the husband point system that my wife tracks at the Howard house. Whenever I do something positive for the family, or my kids, or for her, she updates the ledger in her head in a positive way. Think of it as similar to the Facebook “like” mechanism for the running of the Howard family. If I do something positive, I get another “like.” Where it diverges from the Facebook system is when I do something stupid. If I screw up, which is often and with great effect, my wife immediately reduces the positive entries in my ledger all the way down to zero regardless of how many positive likes were in there before “the incident.” Hey, don’t judge. It works for us. After 35+ years, let’s not argue with success. It is just that a zero tolerance system like that might be good for my marriage but it is not a good model for our infosec program.

Besides being impossible to accomplish, that zero tolerance mentality doesn’t help us build a strong first principle wall. Everything we build on top of that first principle wall would come crashing down as soon as a cyber adversary group successfully completed its campaign. And then what do you tell your boss? Sorry boss, we failed. All of that money we spent on the wall didn’t do what I promised. I don’t want to be in that situation.

Instead of a binary metric that we either did something or did not do something, we should be thinking in terms of a sliding scale; something like a probability range. Our first principle wall should drive us closer to reducing the probability of a cyber adversary running a successful attack campaign against us. That gives us some planning room. We can tell the boss that because we spent x amount of dollars on a new security tool or a new security function, we reduced the probability of an adversary group running a successful cyber campaign against us from 5% to 4%. When we present it in that manner, then leadership can evaluate whether or not the spend for the project was worth the effort. And if it does happen, our first principle building block wall doesn’t crumple. We didn’t tell the board that we would stop all adversary campaigns. We told them that we would reduce the probability of a successful one.

That is getting closer to our absolute first principle. It is no longer a binary question because we have provided a range of probabilities for the leadership to consider. But it is still missing something. It is still too broad and will cause us to spend resources on things that are not important.

Reduce the probability of any successful attack campaign or an attack campaign that is material to the business?

Face it, not everything on your network is essential. If the bad guys compromise Luigi’s laptop and steal the menu for the lunch special in the company cafeteria, maybe we don’t need to call in the FBI for that one. You might be a little embarrassed, but the exfiltration of the lunch menu to the APT’s command and control server in Tajikistan will not cause the company much heartburn. So, why then would we spend a lot of resources trying to protect it?

I don’t know about you, but the volume of resources that I typically get to spend on cybersecurity has never been infinite. If you try to spread that volume thinly over everything, you run out of resources before you run out of things-to-do anyway and the projects that you did spend on are not funded completely enough to solve the entire problem. That is like trying to feed a platoon of neighborhood teenagers with one spoonful of Jif peanut butter, extra crunchy of course, and a loaf of bread. Nobody is going to be satisfied at the conclusion of that exercise. In other words, focus only on what is material to the business. Everything else is nice-to-have.

The risk management team over at Datamaran define materiality this way:

“A material issue can have a major impact on the financial, economic, reputational, and legal aspects of a company, as well as on the system of internal and external stakeholders of that company.”

That is the best, precise, and most compact definition of materiality that I have come across. I want to spend my finite resources on protecting material things, not protecting Luigi’s lunch menu.

The first principle of cybersecurity.

After walking through that analysis, it is clear to me that our foundational first principle block, our cybersecurity cornerstone, must address three elements in order to make it stable for the rest of the first principle building blocks to sit upon. It must focus on preventing successful cyber adversary campaigns not just preventing breaches. It must concentrate on reducing the probability that those successful cyber adversary campaigns could happen, not try to stop them altogether. Finally, it must emphasize attack campaigns that would have a material impact on the company and not the ones that are just embarrassing. With all of that, here is my proposed first principle building block for all network defenders regardless if they are in academia, government service, or commercial entrepreneurship:

Reduce the probability of material impact to my organization due to a cyber event.

That’s it. Nothing else matters. This simple statement is the pillar we can build an entire infosec program on. Which begs the question, what’s next? If reducing the probability of material impact to my organization due to a cyber event is the thing we are trying to do, what are the follow-on first principle building blocks that we will install that will help us do that? Just like Whitehead and Russell, what are the essential concepts that will allow us to prove the equivalent of 1 + 1 = 2 in our network defender world? In future series essays, I will be talking about strategies mentioned in this first essay like zero trust, intrusion kills chains, and DevSecOps. I will also be talking about ideas that I haven’t addressed yet in this essay like resilience, orchestration, intelligence operations, incident response and others as we build the first principle wall of cybersecurity.

Stay tuned.

Cybersecurity first principles.

Prevent all breaches or prevent successful adversary campaigns?

Prevent successful adversary campaigns or reduce the probability of a successful adversary campaign?

Reduce the probability of any successful attack campaign or an attack campaign that is material to the business?

The first principle of cybersecurity.

Recommended reading.