Security Distilled: Building a First-Principles Approach to Understanding Security

By Nathan Davis

This body of work also appears in the form of a webinar, which can be accessed here.

What is security?

This is a question that struck me some time ago, and I realized that I didn’t have a concrete answer. For context, this question actually came about as a derivation of a separate issue I’ve previously had to deal with, “What makes an organization secure?” Of course, this same form of question could be asked of anything else — “What makes a network secure?” “What makes my home secure?”

These questions prompted a deep dive into the concept of what security is, which is not an immediately apparent concept. Like anybody else might do, I searched for answers in search engines, literature, videos, podcasts. For good measure, I asked ChatGPT, but still didn’t get the answer I was looking for.

The most commonly observed answer consistently related back to confidentiality, integrity, and availability: the CIA triad. Some answers extended this to incorporate authenticity, utility, and possession (which form the Parkerian Hexad when combined with the CIA triad). But even these answers appear to be obfuscated, as they correspond to information. Consequently, my search for answers tended to only produce results that corresponded to information or cyber security. Why is this a problem? Because security fundamentally exists in a human context (physical, mental, etc.) that is extended to incorporate logical space; not the other way around.

So where do we begin? A look to the past is always a valuable starting point, and if we look to past philosophers I believe we have a valid framework as our starting point. In Aristotle’s work, Physics (Book I), he asserts:

“For we do not think that we know a thing until we are acquainted with its primary conditions or first principles, and have carried our analysis as far as its simplest elements.”[1]

Re-framing this statement, one might say that we do not know security until we have analyzed it as far as its simplest elements; the first principles of security. Rene Descartes, in his Principles of Philosophy, further carries this definition of first principles:

“Now, these principles must possess two conditions: in the first place, they must be so clear and evident that the human mind, when it attentively considers them, cannot doubt their truth; in the second place, the knowledge of other things must be so dependent on them as that though the principles themselves may indeed be known apart from what depends on them, the latter cannot nevertheless be known apart from the former. It will accordingly be necessary thereafter to endeavor so to deduce from those principles the knowledge of the things that depend on them…”[2]

Aristotle and Descartes both establish that in order to reach the point of a first principle, any analysis must carry the concept to its most basic level such that it can no longer be broken down. Given this idea of first principles, I will make the assumption that security can be broken down into such simple elements from which the rest of security is derived, agnostic of any prefix qualifiers (e.g., physical, information, cyber, etc.).

So, what is security?

What is Security?

“There is no greater impediment to the advancement of knowledge than the ambiguity of words.”[3]

-Thomas Reid

If we want to discuss something from the ground up, I find it’s best to always start with proper definitions in place. In this case, what is the definition of security? Merriam-Webster defines security as, “The quality or state of being secure.”[4] Similarly, the Cambridge Dictionary[5] and Oxford Learner’s Dictionaries[6] share similar definitions (for the sake of semantic dispute). As a next step, I find the best approach is to start enlarging this definition and consider both what it means, and what it expands to. The quality or state of being secure has to do with a couple of things: freedom from danger, affording safety, and being free from risk or loss.[7] Now, we can expand these even further into the concepts of:

· Impact — or the limiting of impact to something we’re trying to protect

· Harm (or Damage) — or the mitigation of harm impacting something we’re trying to protect

· Preservation — preserving something we have in a known-good state

· Defense — or the establishment of defense that ensures a known-good state

Understanding some of these fundamental concepts of the definition of security, I propose a model for looking at security in a simplified manner. Consider a ring model where security sits at the center — the fundamental, atomic concept here. Beyond this, and given our discussion of definition, I believe the next concept must account for the prevention of harm to whatever it is we’re protecting. I’ll call this an “asset” hereafter. Therefore, the next fundamental concept here is, “Prevent Harm to an Asset.” This may also be understood to be the preservation of a desired quality or state.

For example, if you happen to be sitting on your porch, tired of neighboring kids walking all over your grass — you’ll want to find a way to secure your lawn. Consequently, not securing your lawn means that anybody can walk all over it, and the beautiful state that it’s in can be altered. Similarly, sunlight can dry it out, altering the state. To prevent such harm, you need to water it and care for it so that there is some preservation of the desired state. The metaphor carries to physical assets, enterprise networks, and your personal identity. On that note, I’ll add that further discussion of “asset” can be anything from a secret document, an encrypted file, a building, or an organization, to name a few alternatives.

Given this identification of our atomic element of security, we can start to expand upon this concept by considering the attributes of this element. Let’s consider security as if it were a spectrum: on opposing ends we have either absolute security, or no security at all. For the sake of this discussion, think of absolute security like absolute zero (0 degrees Kelvin) where motion theoretically stops (I understand the disputes here regarding energy and quantum mechanics; bear with me). Similarly, absolute security would imply a state in which an asset is absolutely secure and unable to be harmed. In terms of preventing harm, one could only wish that such security could be achievable. However, such a state would also imply that the asset can no longer be accessed — again, think in terms of absolution.

This leads us to the point where security intersects with the real world. For the purpose of emphasizing what we do as security practitioners, this is where security interacts with business operations (hereafter, operations). In this context, an asset is entirely worthless in a state of absolute security. Short of the business being responsible for the securing of Pandora’s box, there are likely few, if any, businesses that must secure an asset to the point of absolute security as I describe it here.

For operations to succeed, then, we must establish some facts and make some assumptions. First, we’ll look at the issue of access — everybody who needs access must be granted access to ensure operations can take place. To consider a previous metaphor, the lawn must be exposed to the sunlight if you want it to grow and thrive. Thus, compromise must be made between security and operations: access must be granted when access is required. However, as a safeguard, “no access” must be the default for all users or systems. From there, we can establish a need for roles to be designated that have access rights. Ideally, these roles allow access only when required, and default back to “no access” when access is no longer required, thus achieving a state of security that prevents harm to an asset. But how do we build upon this?

Building Block 1

We’ll start with first identifying what this concept is. The idea of granting access and permissions to an individual has to do with an extension of Trust. Trust that an individual requires some access to do some form of an action. Of course, “access” by itself isn’t sufficient, so this requires additional elaboration. If you’ve spent some time working with computer systems, you’re probably familiar with the terms, “Read,” “Write,” “Create, “Delete,” or some variation of these. I find that these summarize the types of access that somebody could take on an asset, with a minor modification of label for the purpose of further discussion:

· Read = Access

· Write = Modify (modification of whatever one has access to)

· Create = State Modify (generating something that does not exist)

· Delete = State Modify (destroying something that exists)

For the purpose of identifying the simplest elements, as mentioned earlier, I will further group “State Modify” into “Modify,” as it is a variation of modification of an asset (even if the asset has not been created, in the case of “Create”). Given these specifications, “Access” and “Modify,” I will add that any security actions involving Trust then require an extension of these Trust Actions to someone so that they can perform their required operations.

To frame all of that more succinctly, as we attempt to optimize security within the context of operations, we: 1) want to prevent harm to an asset, but 2) we must provide access to individuals for the purpose of carrying out operations, therefore 3) we must extend Trust, which comes in the form of 4) Trust Actions that are characterized as “Access” and “Modify.”

Now that we’ve established the concept of Trust as a security fundamental, let me present what I see as the next and complementary block within this security wall we’re building: Accountability. If you’ll recall the ring-model above, I discuss how the ring around security is “Prevent Harm to an Asset,” but noted that it may also be described as preserving or maintaining a desired quality or state. In order to maintain a desired state, however, we must be able to account for whatever that state is that we desire.

Building Block 2

Thus, we come to the second building block in the security fundamentals concept. Now, Accountability is like Trust in a few ways, as there are secondary components that it depends upon. As Trust relates to the previously mentioned Trust Actions, Accountability depends upon knowledge that is answered through some fundamental questions. These include the following:

· What is it?

· Where is it?

· How much/many?

· Why?

These will further be described as the concepts of Identification, Location, Quantity, and Purpose, respectively.

First, Identification: what is it? What is the asset for which we are trying to maintain Accountability? This could be a network or set of hosts, in the case of cybersecurity. It could also be an application, a server, a server room, a showroom full of cars, or one of endless other possibilities. In any case, Identification must take place if we are going to attempt to maintain Accountability of whatever the asset is.

Second, Location: where is it? It is one thing to know what we’re securing, but if we don’t know where it is (and consequently, where it’s supposed to be), Accountability degrades. For example, you may know that you own a car. But if you don’t know where that car is, the fact that you own a car doesn’t do you much good. Therefore, understanding where the asset we’re trying to secure is located becomes a critical component as we develop our understanding of security.

Third, Quantity: how much/many? It may seem obvious, especially in the case of a single asset, but this still requires definition. To carry the previous example, if you only have one car (and hopefully the title to the car), that does you no good if that one car is missing and you now have no car available to you. To use another example, if you’re defending a network, visibility of endpoints is important — disappearing endpoints could be an indication that something is broken; newly appearing endpoints could be an indication that somebody has found a way to join your network. If you don’t know how many endpoints should exist, however, you wouldn’t be able to identify whether this is inherently problematic or normal behavior. Therefore, understanding how much of whatever asset we’re trying to protect is critical to our ability to account for it properly.

Fourth and finally, Purpose: why? Why must the asset be secured? Why must your car be locked? So that somebody doesn’t break into it. Why must you keep your keys secure? Because somebody could use them to steal your car. You would have no reason to secure your keys, or your car, if there was no reason to. This question is also a bridging question between security and operations that contextualizes the priority for the security of something. For example, if a government organization has a set of top secret and secret documents, both must be accounted for because of their level of classification. But their underlying Purpose is slightly different; one is a higher level of classification than the other, and therefore requires some level of priority when being secured. The same is true of any other types of assets we may be responsible for protecting.

To recap this second building block, we have Accountability, which complements Trust by ensuring that those assets for which we wish to prevent harm to are properly accounted for. This is done by understanding the concepts of Identification, Location, Quantity, and Purpose. And this complements Trust by ensuring that those things for which individuals have Trust Actions are properly accounted for.

And now we have our bases covered. Almost.

Building Block 3

Something is still missing, however. We can properly extend Trust Actions to individuals, ensuring they can only employ these when they are supposed to. And we can ensure Accountability by maintaining awareness of Identification, Location, Quantity, and Purpose. But we don’t live in a vacuum. Your car can be locked, and your keys can be secured, but this doesn’t prevent a malicious actor from breaking open your window and jump-starting your car. No Trust is granted here; technically, it is abused as you did not permit the action. And Accountability is exploited, as you perceived a false awareness of its components.

So what else remains in the building blocks of security? What simple concept must fall into place when we have to account for existence outside of a vacuum?

Deterrence. And this being the idea that we can do something that deters harmful action from being taken on whatever asset it is that we are trying to protect. To conceptualize this, consider a bank that uses a vault to protect financial assets and safety deposit boxes. If you want to think about security in the form of preserving a desired state, think about your car. You may have multiple deterrents in place. It may be parked in a garage, blocking view from outside and providing a barrier that somebody would have to break through to access it. Or it may have a blinking red light on the dashboard indicating the presence of a car alarm, causing a malicious actor to think twice before breaking in.

Of course, not all harmful actions are necessarily intentional. I just described how a threat actor may be deterred from taking what we will refer to here as “Active” harmful actions, but what about harm that occurs in the form of somebody accidentally driving into your bumper? Or, consider an even more neutral event — a hailstorm pummels your car with hail and scratches the paint, breaks the glass, and shatters your driver-side mirror. No willful intent exists here, and consequently this takes place without a threat actor taking action. We will refer to these as “Passive” harmful actions.

Likewise, we can characterize Deterrence as either Active or Passive, building our knowledge of the security concept here. In such a case, Active Deterrence can be seen as deterrence which can actively take a form of action against a threat. Consider how an armed guard could take action against a threat actor trying to break into a building. The guard can actively prevent that threat actor by removing the threat actor (through some level of escalation of force). Alternatively, a system that locks a user out after three failed password attempts could be viewed this way, as it actively prevents something like password guessing. Concerning Passive Deterrence, this is anything else that does not actively prevent harm. A lock on a door, for example, is a deterrent in that it serves to diminish a threat actor’s ability to break in. Similarly, a door and a wall do not actively respond when broken or destroyed.

As a point of clarification, I will note that we may find what appears to be some overlap between Active and Passive Deterrence. A guard may perform a Passive Deterrence role, observing people approaching a building. But that guard performs an Active Deterrence role when a potential threat draws near. Likewise, your car’s blinking red light is a Passive Deterrence that doesn’t do anything besides notify a threat actor that a car alarm is in place. However, the car alarm system will take an Active Deterrence role and respond when the car is broken into.

This final concept of Deterrence serves to account for the portion of security for which we cannot control, but rather those areas where we are susceptible to external actions. As I mentioned, we do not live in a vacuum and must therefore account for those things outside of our control. And as a complement to Trust and Accountability, Deterrence serves as the third and final building block on our wall of security.

Conclusion

So, what is security?

As we’ve covered here, security is that which prevents harm to an asset, which involves the preservation of a desired quality or state. This is achieved through the concepts of Trust, which is extended in the form of Trust Actions that include “Access” and “Modify.” This is complemented by Accountability, which incorporates the concepts of Identification, Location, Quantity, and Purpose. Accountability and Trust form the base of security within the scope of what we control, but we must also account for those things which we cannot control. This is where deterrence is responsible for preventing harm and preserving a desired state through both Active and Passive deterrence mechanisms. Collectively, these all form a trifecta or tripod that serves as the base for security in its various derivations and prefix qualifiers across the domains of physical, information, cyber, and others.

Hopefully by now I’ve been able to help provide a foundation for your own perspective on what security is. Even more, I hope to spur a more thoughtful approach to what security is, what security means, and how it is implemented in our own organizations. By distilling the concept of security and establishing a first-principles approach, I hope to enable others in their own journeys as security practitioners — regardless of any prefix qualifiers that we all may encounter.

Finally, a few challenges for you, the reader:

• I challenge you to consider these fundamentals in your own organization — where are they strong? Where do they fall short?
• I challenge you to build upon the foundation I’ve laid here. Or, to disprove what I’ve laid out. My analysis goes only so far as my experience combined with my research, and so I acknowledge there may be an unintended omission.
• I challenge you to consider security as the underlying discipline for which you, a security practitioner, are responsible to learn fundamentally, understand, and apply.

Remarks

Thank you to Brandon Scullion for helping me bring this effort to reality — it wouldn’t have happened without his support and encouragement. Thank you to Russel Van Tuyl for a keen eye and for drawing attention to what I realized constituted my most critical gap. And a final thank you to Rick Howard, from whom I formed a basis for my approach here after hearing his work on first principles in cybersecurity.

[1] Physics (Book I), Aristotle, http://classics.mit.edu/Aristotle/physics.1.i.html

[2] The Principles of Philosophy, Rene Descartes, https://cdn.fulltextarchive.com/wp-content/uploads/wp-advanced-pdf/1/The-Principles-of-Philosophy.pdf

[3] Essays on the Intellectual Powers of Man, Thomas Reid, https://www.cambridge.org/core/books/abs/essays-on-the-intellectual-powers-of-man/preliminary/BF1EA3B2E985AA7A76CB7F87D6C955D0

[4] Security, Merriam-Webster Dictionary, https://www.merriam-webster.com/dictionary/security

[5] Security, Cambridge Dictionary, https://dictionary.cambridge.org/us/dictionary/english/security

[6] Security, Oxford Learner’s Dictionaries, https://www.oxfordlearnersdictionaries.com/definition/english/security

[7] Security, Merriam-Webster Dictionary, https://www.merriam-webster.com/dictionary/secure

---

Security Distilled: Building a First-Principles Approach to Understanding Security was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.