Cybersecurity first principles: end of season summary.

By Rick Howard

Jun 29, 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: end of season summary.

Listen to the podcast episode.

Note: This is the eighth and final essay in this series that discusses 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.

These essays are companion pieces to the CyberWire podcast of the same name called CSO Perspectives. I mention this because we have come to the conclusion of the podcast's first season. We’re pausing for a bit to give us a chance to prepare the second season. In a few weeks, we will pick up right where we left off. For this last essay in the series though, I thought I’d take a moment and summarize how we got here and why. In both, the essays and the podcasts, I have attempted to build a strategy wall, brick by brick, for a cyber security infosec program based on first principles.

At this point, eight essays and podcasts in, you might be asking yourself why? Why did I go to the trouble? Why is first principle thinking so important to the network defender community? Why is this a better way to build an infosec program than say the NIST Cybersecurity Framework or any of these other frameworks that currently exist?

CCPA: California Consumer Privacy Act for California consumers.
CIS: Center for Internet Security: volutneer-expert coalition of 20 controls.
COBIT: Control Objectives for Information and Related Technologies framework for IT systems used in financial accounting. It’s a core part of compliance with the Sarbanes Oxley Act.
GDPR: European Union’s General Data Protection Regulation that protects personal information.
HIPAA: Health Insurance Portability and Accountability Act, a set of regulations and a framework, designed to protect patients’ privacy.
ISA 62443: Industrial Society of Automation for industrial automation and control systems.
ISO 27002: International Organization for Standardization, specifications for an information security management system (ISMS).
NIST SP 800-53: Security and privacy controls for federal information systems and organizations.
PCI DSS: Payment Card Industry Data Security Standard controls.

I’m glad you asked.

The NIST Cybersecurity Framework success story.

Let me say up front that the NIST Cybersecurity Framework document is a remarkable piece of research and statement of best practices. It’s probably one of the finest examples of a coordinated public-private partnership that the network defender community has ever manifested. One of its keys to success is the collaboration between the U.S. Government and other thought leaders and stakeholders from the commercial sector and the academic community.

With Executive Order 13636, President Obama tasked NIST, the U.S. Government’s National Institute of Standards and Technology, to build a cybersecurity framework for the country’s critical infrastructure that focused on information sharing and risk management. NIST’s approach to building that framework was to be inclusive with the network defender community. Within a very short year, the NIST team organized a traveling road show that went around the country to conduct five in-person workshops and accompanying webinars designed to collect pertinent information about the subject and, later, to comment on the draft work product. In February 2014, NIST published version 1.0 of the document and updated it to version 1.1 in April 2018.

In 2016, a survey conducted by Tenable of over 300 IT and security professionals found that over 40% of respondents had adopted the framework as a best practice. In my wanderings around the world, I have found that most network defenders believe it represents the industry’s current best practice even if they haven’t adopted it. In every measure, that is a success and the thing that makes the NIST Framework unique compared to the laws and other standards work listed above is the cultivated public-private partnership.

The NIST Cybersecurity Framework as a strategy.

In the very first essay of this series, I said that the network defender community has been incrementally improving itself since its inception back in the 1990s. We saw what others were doing, tried to emulate them, and then we took the next step. The NIST Cybersecurity Framework is a culmination of that kind of thinking. The NIST researchers polled a bunch of us and crafted a consensus document regarding the best ideas around what everybody was doing. That is fabulous. It represents the network defender community’s current best guess as to what an infosec program should look like. My only issue with it is that it doesn’t pause long enough to contrast what everybody is doing to what everybody should be doing.

Don’t get me wrong. If you pursue nothing but the NIST Cybersecurity Framework to enhance the security posture of your organization, your program will be strong, and better than most others. But what I’m trying to avoid is the cybersecurity equivalent of Russell’s Paradox in mathematics (see the first podcast and essay in the series), deploying strategies that are accepted best practices, but give you inconsistent results. It all comes down to what, exactly, we’re trying to achieve with our infosec program.

Buried in the executive summary of version 1.1 of the NIST Cybersecurity Framework, I found this line as a statement of purpose:

“… the Cybersecurity Enhancement Act of 2014 (CEA) updated the role of the National Institute of Standards and Technology (NIST) to include identifying and developing cybersecurity risk frameworks for voluntary use by critical infrastructure owners and operators. Through CEA, NIST must identify “a prioritized, flexible, repeatable, performance based, and cost-effective approach, including information security measures and controls that may be voluntarily adopted by owners and operators of critical infrastructure to help them identify, assess, and manage cyber risks.”

Is that what we’re trying to do? Help critical infrastructure operators identify, assess, and manage cyber risks? Perhaps. But is that the most important thing? It’s crucial for sure, but is it the most essential thing to do? I don’t think so.

First principles to build a strategy.

The first essay in this series walked the reader through my thinking about the concept of first principles as it applies to cybersecurity. The idea is that if you want to build something grand, like a cybersecurity framework, you have to first reduce it down to its essence, and then build it up from there. This essence becomes the foundation of the entire thing, the expression of purpose, the aspiration. In the essay I said this:

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.”

It is not that the NIST Cybersecurity Framework and the others don’t have the proper ingredients for a good infosec program. They do. They have many of them. But they are not atomic and interlocking. They don’t represent a strategy because they don’t build on each other to accomplish something. They don’t place a stake in the ground in front of us to guide us on our infosec journey. They are essentially an endless todo list that many security professionals have trouble finishing. Collectively they provide the network defender community with little insight to describe what we are trying to accomplish. And that is the reason to think about frameworks through a first principle lens.

In the first essay, I proposed that the essence of what every cybersecurity professional is trying to do with their infosec program, the foundation, the reason for it to exist, is this:

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

In every essay and podcast in the series, I have reiterated that simple statement. That’s it. Nothing else matters. It is the pillar on which we can build an entire infosec program.

The first principle infosec wall, brick by brick.

The next essays and podcasts in the series continued with the infosec wall metaphor. If reducing the probability of material impact is the absolute first principle for our program, what are the essential strategies we should use to support it. What are the first bricks we are going to lay on that foundation? What are the interlocking and essential capabilities required to build that strong infosec wall? We talked about six to start.

Zero trust: A network design philosophy about where we store our data and who should have access to it. In the last five years, the number of places organizations store their data outside of their traditional perimeter has exploded. We have data center space. We have mobile users. We have SaaS applications, a lot of them. We have cloud environments (IaaS/PaaS). In many cases, we have hybrid cloud environments (multiple cloud providers like Google, Microsoft, and Amazon.) And we still have data behind the perimeter. I call these storage areas data islands. The zero trust brick is passive. In other words, everything we do to implement our zero trust program has nothing to do with how adversaries actually attack our systems. Any zero trust control we install is general-purpose, designed to defeat a generic adversary. The idea of zero trust is that the act of employees logging into the network in the morning should not willy nilly grant them access to all of our data islands. There should be some notion of “need to know.” Network architects design employee access with the assumption that the network is already compromised and limits employee access in order to reduce the probability of data destruction or data theft. In other words, if hackers compromise the credentials of an employee, they can’t use those credentials to cause material damage.

Intrusion Kill Chains: The mastery to deploy prevention controls at each phase of the attack sequence for all known adversary campaigns. When you realize that there are less than a hundred adversary groups running less than 500 adversary campaigns on the internet on any given day, you understand that it’s possible to build defensive campaigns designed specifically to defeat every one of them. Contrast that to the passive zero trust approach. This strategy is active. We know that cyber adversaries have to string a series of actions across the intrusion kill chain (recon - delivery - exploitation - command and control - lateral movement - exfiltration) to accomplish their mission. It is conceivable that you could deploy prevention and detection controls at every stage. Instead of simply deploying a prevention control for some technical weakness with no relation to how the adversary operates, we deploy prevention and detection controls designed to specifically defeat all known adversaries. This will exponentially decrease the probability of material impact due to a cyber event because even if the adversary gets around one of your controls, they’ll run into the very next one in the intrusion kill chain defensive campaign.

Resilience: The dexterity to continuously deliver the intended outcome despite adverse cyber events. Having the capability to continue supporting internal and external customers in the middle of a withering cyber attack demonstrates to the world that even though the attack is damaging, it is not material to the business in total. In other words, even if a ransomware attack encrypts our finance information stored in an Amazon S3 bucket, we can still operate the business because we have a hot copy of that data stored somewhere else. We design the network so that there is no material impact to this kind of risk because the business runs on a system of systems that is redundant and consistent.

Risk Assessment: A precise forecast regarding the current probability of material impact due to a cyber event to our organization. Since our atomic first principle involves reducing probability, it becomes imperative that we have a means to calculate what the existing probability is. In order to do that, network defenders must expand their understanding of probability. It’s more than counting marbles of a specific color coming out of an urn that we learned in our probabilities and stats class back in college. We take our lead here from Doctor Ron Howard and his theory of decision making. His concept of probability is that it is a precise definition for what we know about a problem domain. From my perspective, I know that the risk question we answer must have three components. It must first have a precise quantitative probability estimate, not an imprecise qualitative assessment like high, medium, or low. It then must focus on things that will be material to the business. Anything else is not necessary. Finally, it must be time bound. As we expand our notion of probability, we must remember what George Box, the famous British statistician has said, “All models are wrong, Some are useful.” Choose a simple model first and then continue to enhance it to make it even more useful.

Cyber Intelligence Operations: The methodology of turning raw information into intelligence products that leaders use to make decisions. The process itself is simple: get leadership’s guidance on what information they need to make decisions, break this guidance down into smaller and more manageable questions, seek information to answer those questions, develop products to answer those questions with the information at hand, deliver those products to leadership, and finally, get guidance from leadership about whether the products were useful or not. This can and should be used to inform all of the other essential security bricks on the infosec wall but the most likely use is to inform the intrusion kill chain brick. If we’re going to devise defensive campaigns for all the known adversary attack campaigns, then we need a way to collect the latest developments across the attack sequence from the likes of Panda Bear, craft prevention controls to defeat it, and coordinate the deployment of those controls to the security stack across all data islands.

DevSecOps: The competence to run your digital business with code. Manual processes are brittle and break on a regular basis. They accumulate technical debt. They require humans to stop what they are doing to enhance the business in order to spend time fixing a broken or degraded system. The key is deploying infrastructure as code. This paradigm shift from managing the network by manual processes to relying on an engine of an autonomous system-of-systems enables the organization to deploy layers of consistency and security across the entire enterprise. Those layers provide the mechanism, the levers so to speak, to reduce the probability of material impact across the other pillars in the first principle infosec wall. It is one thing to manually install your zero trust policy in one of your key SaaS applications. It is quite another to be able to do it across all SaaS applications at the push of a button. It is one thing to deploy new handcrafted firewall rules designed to defeat Panda Bear across the intrusion kill chain. It is quite another to build software systems that reads the current state of the Panda Bear attack campaign, generates prevention controls for every phase of the attack sequence, and deploys them to the security stack across all data islands automatically. It is one thing to spend weeks manually calculating the current probability of material impact due to a cyber event. It is quite another to have a daily recalculation based on the current state of the network and new evidence about the changes to the Panda Bear attack campaign. It is one thing to resiliently and manually swing your systems away from a compromised data set to an uncorrupted data set. It is quite another to have an DevSecOps system discover the situation and automatically pivot to the clean data set before anybody notices. It’s one thing to have your intelligence team track the Panda Bear attack campaign and make recommendations to the network operations team about what prevention controls to deploy. It’s quite another to build a system that collects the latest intelligence about Panda Bear, builds the correct prevention controls for the current security stack across all data islands, and then deploys them automatically.

First principles as a new way to think.

In this fist season of podcasts and essays, I’ve made an argument that the way the network defender community has incrementally improved itself might need a reboot. Every year, cyber adversaries improve their craft and every year, the network defender community responds to the new methods. In the tweny-five years I’ve been doing this, we never seem to be on top. It’s almost like our method is not working but it is the only thing we know, so we keep doing it. This kind of thinking has led us to focus on the tactical prevention of malicious technical things from penetrating our networks instead of concentrating our efforts on more strategic goals like protecting the business. Rethinking our strategies through a first principle lens will help us do that. It allows us to decide what the most important thing is for our organization and build the supporting infrastructure from there.