Layer 8: musings on security at the “Human” layer
What does engineering look like at Improbable Defence?
As you might expect, it’s complex, multifaceted, and a big part of what we do. Our engineers comprise a broad and diverse range of expertise, from front end, back end and platform engineering to applied science, quality testing and model engineering.
We’re all working to the same ends: shaping the future of synthetic environments that help governments and defence organisations transform how they plan, train and operate.
In this blog series, we’ll highlight some of the most intractable – and exciting – challenges that our engineers tackle every day in pursuit of this goal.
Chris Clarkson, Security Engineering Lead, kicks off the series with his thoughts on Layer 8 security and the potential pitfalls of mixing man with machine. Subjectivity is the enemy of the secure, in Chris’s eyes – and security is easy if we only wrap user choice in controlled, measured objectives.
Because we’re helping governments tackle some of the world’s most urgent threats, security is a big deal here. And though security may not be everyone’s job, it is everyone’s responsibility.
By Chris Clarkson, Security Engineering Lead
If, like me, you have a presence in info or cyber security social media, you’ll undoubtedly have seen at some point a tweet or post asking: “What are the main causes of security issues in your organisations?”
What usually follows is an avalanche of opinions, “learned outcomes”, autosuggestion, and FUD. Of all the answers given, a common thread is that humans are the cause of most, if not all, security issues in an organisation. And let’s be fair – if you throw enough mud, some will stick.
Layer 8 is the term often used to refer to this problem, a trite extension of the Open Systems Interconnection (OSI) model used to identify humans as the additional layer of a system. And since humans tend to be pretty closely involved in computer systems (building them, maintaining them, using them), Layer 8’s pretty important from a security perspective.
There are rarely times that an unused, unpowered, disconnected computer is the victim of a security issue. So in any circumstance that a security issue occurs, humans were, at some point or other, involved.
“What a fun introduction,” I hear you say. But fear not: this isn’t a bash piece for our users. What follows will be a few movie references, a little bit of controversy, a new triad, and a sprinkling of ‘been there, seen/done that’.
Hot take: security is easy
A bold statement I know. But I make it with a whole host of caveats and addendums. Security in its rawest form is the identification and treatment of risk. We dress it up with triads and architectures, policies and procedures, baselines and standards, but ultimately it comes down to risk and control, and that’s actually the easy part.
Confused? Asking “if it’s that easy, why are there security breaches costing millions of dollars every year, and the problem’s only getting worse”? We’ll come to that, but first I want to dig deeper into the meaning of my heretical ravings.
Security is easy. I keep repeating it so that one day all sides of the debate will believe it. Identifying Risk is easy. There are specialists in all walks of life that spend their time and careers on it. It’s their reason for being, their ikigai, and they do it very well. As security professionals we’re counted amongst these people – we identify risks for a living and work out how to handle them. Like all skills, it’s one that you can master with practice.
Security Engineering is a specialism of security whose ikigai is to implement controls on those risks. For example, we take the risk that ‘someone may compromise a vulnerable service and exfiltrate user data’. We apply controls to that risk to minimise the likelihood and impact of that compromise. Meanwhile, we maximise our chances of detecting and preventing compromise attempts. From a purism perspective, it’s that easy – no esoterica, no secret knowledge, just fundamental engineering principles applied to a problem. Like any problem, you work through it objectively and solve the component parts. In doing so, you solve it and move on to the next.
The elephant in the room is that engineering purism is not the only game in town. Business priorities, cost, personnel, and skillsets all have a part to play. There are inevitable conflicts that affect just how much of that purism you have licence to run with.
I’ll let you in on a secret: that elephant is a distraction. There’s a deeper problem that needs to be discussed and hopefully solved, one more important than why there’s an elephant in the office with buzzwords tattooed on its hide.
The problem is choice
As Neo and the Architect wax philosophical about the matrix, their conversation mirrors that of security in the context of The Layer 8 Conundrum. There are systems of control, and they are often undermined by ‘choice’. A choice of password, a choice of tooling, a choice of language, a choice of pattern. At face value, this conversation affirms the opinions of our social media brain trust in identifying the root of our security woes as Layer 8.
However, what if the reality is that the choice was poorly made because the options available were inadequate, or even harmful?
For example, Security and IT Operations teams have spent more than 25 years conditioning users to create passwords that are hard to remember but easy for a computer to calculate. Think a minimum of 8 characters, one uppercase, one lowercase, one number, and one symbol. The user options are to create a ‘policy compliant’ password that’s easy to remember eg Hunter2! (and increment the number every 90 days) or write the more complex variations on a Post-it note. How are they expected to do things securely with those as the options? Check out the xkcd comic – it makes a lot of sense.
I wonder just how many organisations that blame their regular security issues on users are also at fault for giving those same users the worst of the possible options.
Guardrails and the paved road
I’ve always been a fan of the guardrails approach to security engineering capabilities. I have a set of security objectives for engineers to meet and we provide a set of capabilities to assist teams in meeting them.
Guardrails are a common concept among security engineers. They allow us to prescribe ways of working while empowering engineering teams to make a choice that best suits their needs. It depends on the security engineer you speak to as to how they perceive those guardrails. Personally, I see them as the walls of a luge track at the Winter Olympics. Others consider them safety rails on the edges of paved roads. Both are nice analogies in this area and both allude to the benefits you get from low-friction controls.
Take a look at these images.
On the luge track, the options are limited but you can go quickly. A failure rarely sends you outside of the track.
A wider mountain road, with more options for where you drive, but also more options to crash. That rail has a small chance of stopping you hurtling down the mountainside.
Hopefully, you can see the point I’m alluding to using the luge vs road analogy. Leaving the track/road would be analogous to a risk-control failing. The logical outcome is that limiting choice reduces the chance of a control failure, and limited choice naturally lends itself towards lower-friction (and thus higher-velocity) work patterns.
So if we limit the choices provided to the narrowest possible options, and efforts are taken to make sure that all of them will meet the security objectives, why is choice still the problem?
Because there’s always the possibility that a choice to shirk all options and go wildly off track is not only available – it’s the one taken. The values we hold dear at Improbable – aim for the impossible, and action over fear – can be a detriment if they empower a choice to go outside of the lines.
Securing Layer 8 together
While perfection is the enemy of good, subjectivity is the enemy of secure. In my experience, subjectivity manifests itself in many guises as experience grows and those manifestations are often where The Three Cs of Choice are realised: convention, conviction, and contrarianism.
Early in an engineer’s career, they’re told how to solve a problem by more experienced colleagues, in the best way possible, with the best tools to hand, to the best of their knowledge. This breeds a convention, or default choice, for solving that problem. Often this isn’t challenged until the engineer learns enough to challenge that convention through experimentation, exasperation, or experience.
Later on, when that engineer is more experienced, their conviction is used to support decisions. This conviction holds that the conventional way is somehow faulty or inhibitive. This often leads to the engineer having to prove their assertions and so finding the evidence to assert or refute that conviction. With proof, their conviction spreads. If it spreads far enough, a new convention is formed.
Later in their career, the engineer is considered a leader and has battle scars from experience. If they’re not careful their subjectivity sometimes manifests as contrarianism, providing opinions on something by setting themselves up in opposition to it. Less experienced engineers may see contrarianism as advice and not simply a critical thinking device, and take it as a convention to use going forward, thus perpetuating a cycle.
I made the statement before that subjectivity is the enemy of secure. I stand by that opinion, largely because of my experience in observing the 3 Cs, and how choices are made by engineers of different experiences. It’s a common theme: a belief that their way is better than the prescribed way, leading to a security issue that has to be cleaned up later.
I don’t ascribe to the idea that the engineer made the choice and as such it’s solely on their head. As a security engineer, I provided the options. Any outcome where a subjective opinion overrode those options to cause a failure of a control is a fault in the capabilities. It’s something to review and address. Much like the password problems of recent decades, littered with faulty advice and poor options, redressing the issue with things like password managers is the best response and gives a better option for our users.
Identifying the security gap highlighted by subjectivity also shines a light on the user gap. I urge you to make choices based on objective evidence, not personal philosophies. Remove the likes and dislikes from your decision-making process. If you object to a course of action, think about it in such a way that removes personal feelings.
Instead ask: does the use of tool X, pattern Y, or process Z meet the objective that I am set, in a way that doesn’t inhibit my work? If so, follow up with: do I really need to work at odds with the established patterns to achieve my goals? If after that critical analysis of how you work and how you wish to achieve that security outcome you still feel the need to go off-piste, come and speak to us. We’ll happily change our views based on what we observe, and if your option is better, we’ll adopt it.
Final thoughts
Security is easy. Identifying risk and applying the engineering mindset and tenacity to control it makes it that way.
Subjectivity, or choice, is where we’re exposed to vulnerability in our risk treatment approach. By keeping our feelings out of decisions wherever possible, we can reason about how in a mechanical sense, and avoid philosophical traps that breed doubt, uncertainty, and ultimately risk a security control failure.
I strongly challenge any assertion that users are the main cause of security problems at an organisation. When the choices they’re given are sane and safe by default, and they have the right coaching on how and why decisions were made, users are a boon to our security objectives and a vital part of our defence strategy. Security isn’t everyone’s job, but it is everyone’s responsibility – so it should be made as easy, accessible, and frictionless as possible.
Join Improbable Defence as an engineer to solve problems and deliver solutions at the very edge of technology, research and simulation.
Check out our open roles to find your perfect fit.