Madness: Fundamental beliefs about Security

How to approach security in a different way

I have found that with whatever you do in life, there is almost always a framework with which you interpret things -a set of beliefs that often go unsaid, that almost always underpin the decisions you make. I’m not trying to be Sigmund Freud here, but I think that unpacking some of my beliefs will allow us to see how the mechanics of my system support an overall approach. I will probably forget to mention some still unconscious thoughts here, but we can at least start with a few general beliefs and assumptions.

Applying metaphysical view to applications

First, let’s talk some mumbo-jumbo. This is usually where I either lose people, blow their minds and get asked the question “wait, where does this come from?” Part of my security theory involves applying an Aristotelian view on the essential properties of things to applications (and of course any other asset or thing). Now I’m no studied philosopher (I’ve got too much of a smooth brain for that), so understand that I’m applying a simplified version of this philosophical concept.

Simply put, according to Aristotle, a thing has an Accident and a Substance to it, where the Accident is generally the physical properties of a thing, and the substance is that critical essence of what it is. For example, a book is made of paper, ink, some cardboard – these would be Accidents. While a book is all those things, it is more than just a particular arrangement of materials. It has content, information, a story. A book has meaning, and it makes us think and feel. This “stuff” transcends the physical materials of paper and ink, and this is the Substance.

Our assets and our applications are quite similar to a book in this regard. All of our applications are comprised of some real physical stuff (even if some people keep saying “It’s serverless!”). There’s the underlying hardware, the virtual servers, the network, the code, the vulnerabilities, packages, libraries and e.t.c.. I believe that we can often categorise these as the Accidents of an application. But all of that sits within a context that gives our applications meaning. What data is in the application, and who is it about? What service does it provide? How do people use that service? How is it valued to them, and what happens if it’s not available? These questions are all about the Substance.

A bit of security dogma

Now along with this Aristotelian view of “stuff,” I’ve also got some beliefs about how good security works. I’m not sure if they’re just beliefs, or if they’re rules but either way, I think they’re important, and they underpin how I apply security.

First is that No Policy = No Rules. Without policies or standards, you cannot hold people accountable for doing something incorrectly or insecurely. Policies tell people what good looks like, and without them you open security to interpretation, and individual choice. If you want good security, you better establish some good policies and standards, and of course, make them accessible.

However, the first assumption must make consideration of my second belief which is that good security creates the path of least resistance. Generally, people care about their work, and they will happily avoid security hurdles if it means they can do their work better. Most of the time, that’s not because people are malicious, it’s because people are trying to be efficient. If it takes effort to find a policy, or to complete a task a certain “security way,” and if there exists a lower-effort path, then people will generally choose the lower effort path – especially if there’s no incentive to commit more effort than necessary. The goal then of security is to make the “right” way, the easiest way as well.

Admittedly, this is pretty difficult because security is often the natural enemy of efficiency. The process of creating checks and balances inherently slows things down. Regardless, we should understand that it’s still our responsibility to make security as easy as is humanly possible, in order to achieve the best results.

This naturally flows to my third belief which is that pragmatism in security is key. Let’s face it, risk is inevitable, and the most optimal solution that de-risks everything is not always viable. We all have deadlines for delivery and stuff to get done for the business. Without any business, there’s nothing to secure, so we must do our best to enable the business. Which means trying to mitigate risks in a pragmatic, reasonable way, that understands the context of the problem. I often think back to my first job in the UK working under Grant Farquhar, who had some very sage advice which I shall paraphrase: “It doesn’t have to be perfect, just make it better than it was.” Any improvement, no matter how minor is an improvement nonetheless.

The last belief is that security decisions should be grounded in reality. Sometimes the security team can be seen as the “no” team. But really, we shouldn’t be saying “no” to something (whether in policy or in approvals) if that thing does not clearly lead to a material risk. Often this is born out of the fact that we don’t really understand the ask, or understand the technology underpinning the ask, which means we’re saying no because we’re afraid, and we’ve got a “bad feeling” about it. However, it is not the fault of the business that we don’t understand the full context of a solution, the technology that supports it, or any other relevant detail.

It’s up to a security function to inform themselves, and to make sure that security decisions are grounded in reality, and are data driven in so much as is possible. Obviously, because I believe this is a good way to operate, I also believe security is implicitly difficult. As a security function, your expertise must consistently expand to understand more complexity and predict the risks that arise from that complexity. It should go without saying, that no singular security subject matter expert will have all the relevant knowledge in every field allowing them to spot all problems, so it’s important to build up your network within your business and outside to ensure you are getting the correct perspective.

It’s all about Risk

Now you might recall from my earlier post, that I believe good security is all about being risk focused and that’s because I believe risk is the key factor in making good security decisions.

This is where all of this gobbledygook about metaphysics and beliefs tie in together. You see, in my opinion, if you want to understand the risks to an application, you need to have the clear picture of what the properties of that application are, and you need to understand the relationships between them. This means understanding the Accidents and the Substance of an application. An application may accidentally have some vulnerabilities, but substantially have a low impact to the business, due to the data held, or to its value, and we should treat that application differently from an application with the same accidents, but with a much more valuable substance. The point is that the details matter.

However, the metaphysics and beliefs are about more than the immediate impact of that application: it extends into the decisions you make in an overall security strategy. If you want to have effective security, you need effective policies and standards. And if you want to do that, well you’ve got to understand what risks you’re trying to mitigate with those policies. This implies that fundamentally one need to understand one’s risks, and the path to that is understanding the accidents and substance of your environment.

This leads to how you strategically build and progress your security function. Keeping in mind my beliefs around pragmatism and the path of least resistance, the security capabilities you build and implement should be based around the policies that you create, and should support them, creating paths for compliance and good security. You can only do this effectively when you’re grounded in the reality of your applications, your environment, your context. The standards and policies for one business, may not apply to yours, your tech stack, or your risks. You need to optimize for your situation.

Coming Next…

Well, I think we’ve got a good bit of the theory out of the way now and we can start talking about some more practical points in the next installment of this series! In the next one, we’ll discuss using risk as a tool. For those of you wanting to dive into more technical depth of securing an application, we’ll touch on that in due time, though spoilers, I won’t be re-inventing the SSDLC wheel!