Diversity in IT security: not just a canine issue

“People won’t listen to you or take you seriously unless you’re an old white man, and since I’m an old white man I’m going to use that to help the people who need it.” —Patrick Stewart, Actor

A couple of weeks ago, I wrote an April Fool’s post: “Changing the demographic in IT security: a radical proposal“.  It was “guest-written” by my dog, Sherlock, and suggested that dogs would make a good demographic from which to recruit IT professionals.  It went down quite well, and I had a good spike of hits, which was nice, but I wish that it hadn’t been necessary, or resonated so obviously with where we really are in the industry*.

Of special interest to me is the representation of women within IT security, and particularly within technical roles.  This is largely due to the fact that I have two daughters of school age**, and although I wouldn’t want to force them into a technical career, I want to be absolutely sure that they have as much chance both to try it – and then to succeed – as anybody else does, regardless of their gender.

But I think we should feel that other issues of under-representation should be of equal concern.  Professionals from ethnic minorities and with disabilities are also under-represented within IT security, and this is, without a doubt, a Bad Thing[tm].  I suspect that the same goes for people in the LGBTQ+ demographics.  From my perspective, diversity is something which is an unalloyed good within pretty much any organisation.  Different viewpoints don’t just allow us to reflect what our customers see and do, but also bring different perspectives to anything from perimeter defence to user stories, from UX to threading models.  Companies and organisations are just more flexible – and therefore more resilient – if they represent a wide ranging set of perspectives and views.  Not only because they’re more likely to be able to react positively if they come under criticism, but because they are less likely to succumb to groupthink and the “yes-men”*** mentality.

Part of the problem is that we hire ourselves.  I’m a white male in a straight marriage with a Western university education and a nuclear family.  I’ve got all of the privilege starting right there, and it’s really, really easy to find people like me to work with, and to hire, and to trust in business relationships.  And I know that I sometimes get annoyed with people who approach things differently to me, whose viewpoint leads them to consider alternative solutions or ideas.  And whether there’s a disproportionate percentage of annoyances associated with people who come from a different background to me, or that I’m just less likely to notice such annoyances when they come from someone who shares my background, there’s a real danger of prejudice kicking in and privilege – my privilege – taking over.

So, what can we do?  Here are some ideas:

  • Go out of our way to read, listen to and engage with people from different backgrounds to our own, particularly if we disagree with them, and particularly if they’re in our industry
  • Make a point of including the views of non-majority members of teams and groups in which you participate
  • Mentor and encourage those from disparate backgrounds in their careers
  • Consider positive discrimination – this is tricky, particularly with legal requirements in some contexts, but it’s worth considering, if only to recognise what a difference it might make.
  • Encourage our companies to engage in affirmative groups and events
  • Encourage our companies only to sponsor events with positive policies on harassment, speaker and panel selection, etc.
  • Consider refusing to speak on industry panels made up of people who are all in our demographic****
  • Interview out-liers
  • Practice “blind CV” selection

These are my views. The views of someone with privilege.  I’m sure they’re not all right.  I’m sure they’re not all applicable to everybody’s situation.  I’m aware that there’s a danger of my misappropriating a fight which is not mine, and of the dangers of intersectionality.

But if I can’t stand up from my position of privilege***** and say something, then who can?


*Or, let’s face it, society.

**I’m also married to a very strong proponent of equal rights and feminism.  It’s not so much that it rubbed off on me, but that I’m pretty sure she’d have little to do with me if I didn’t feel the same way.

***And I do mean “men” here, yes.

****My wife challenged me to put this in.  Because I don’t do it, and I should.

*****“People won’t listen to you or take you seriously unless you’re an old****** white man, and since I’m an old white man I’m going to use that to help the people who need it.” —Patrick Stewart, Actor

******Although I’m not old.*******

*******Whatever my daughters may say.

But I don’t know what a container is!

… containers are both very much like and very much unlike VMs…

I want to talk about security in DevOps – also known as “DevSecOps”* – on this blog, but it’s going to have to wait for a subsequest post. I’ve been speaking at a few conferences and seminars recently on this topic, and I’ve started to preface the discussion with a quick question: “Who here understands what a container is?”. And you don’t get that many hands going up**. So I’ve started giving a little explanation of what containers*** are before going much further.

To be clear: can you do DevOps without containers? Can you do DevSecOps without containers? The answer to both is “yes”. But containers lend themselves so well to the DevOps approach – and to DevSecOps, it turns out – that even though it’s possible to do DevOps without them, I’m going to assume that most people will use them.

What is a container?

I was in a meeting with a number of colleagues a few months ago, and one of them was presenting on containers. Not everybody around the table was particularly expert in the technology, so he was starting simple. He made a statement, which said something like “There’s no mention of containers in the Linux kernel source code”. This, it turned out, was a dangerous statement to make, given some of the attendees, and within a few seconds, both my boss (sitting next to me) and I were downloading the recent kernel source tarballs and performing a count of the exact number of times that the word “container” occurred. It turned out that his statement wasn’t entirely correct. To give you an idea, I’ve just tried it on an old version that I happened to have on my laptop (4.9.2), and I got a result of 15,273 lines including the word “container”****. My boss and I had a bit of a smirk and ensured that we corrected him at the next break.

What my colleague meant to say – and he clarified later – is that the concept of a container doesn’t really exist as a clear element within the Linux kernel. In other words, containers use a number of abstractions, components, tools and mechanisms from the Linux kernel, but there’s nothing very special about these: they can be used for other purposes as well. So, there’s “no such thing as a container, according to the Linux kernel”.

What, then, is a container? Well, I come from a virtualisation – hypervisor and VM – background, and the way that I tend to think of it is that containers are both very much like and very much unlike VMs. I realise that this may initially not sound very helpful, but let me explain.

How is a container like a VM?

The main way in which a container is like a container is like a VM is that it’s a unit of execution.  You bundle something up – an image – which you can then run on a suitably equipped host platform.  Like a VM, it’s a workload on a host, and like a VM, it runs at the mercy of that host.  Beyond providing workloads with the resources that they need to do their job (CPU cycles, networking, storage access, etc.), the host has a couple of jobs that it needs to do:

  1. protect workloads from each other, and make sure that a malicious, compromised or poorly written workload cannot affect the operation of any others;
  2. protect itself (the host) from workloads, and make sure that a malicious, compromised or poorly written workload cannot affect the operation of the host.

The ways that this is achieved for VMs and containers is fundamentally different, with isolation, with VMs being kept isolated by hypervisors making use of hardware capabilities, and containers being kept isolated via software controls provided by the Linux kernel******.  These controls revolve around various “namespaces” which ensure that one container can’t see other containers’ files, users, network connections, etc. – nor those of the host.  These can be supplemented by tools such as SELinux, which provide capabilities controls for further isolation of containers.

How is a container unlike a VM?

The problem with the description above is that if you’re even vaguely hypervisor-aware, you probably think that a container is just like a VM, and it really isn’t.

A container is, first and foremost *******, a packaging format.  “WHAT?” you’re saying, “but you just said it was something that was executed.”  Well, yes, but much of the reasons containers are so interesting is that it’s very easy to create the images from which they’re instantiated, and those images are typically much, much smaller than for VMs.  For this reason, they take up very little memory, and can be spun up and spun down very, very quickly.  Having a container that sits around for just a few minutes, or even seconds (OK, milliseconds, if you like) is an entirely sensible and feasible idea.  For VMs, not so much.

Given that containers are so lightweight and easy to replace, people have started using them to create micro-services – minimal components split out of an application which can be used by one or many other micro-services to built whatever you want.  Given that you only plan to put what you need for a particular function or service within a container, you’re now free to make it very small, which means that writing new ones and throwing away the old ones becomes very practicable.  We’ll follow up on this when we talk about DevOps next time.  We’ll also talk about some of the impacts this might have on security, and hence DevSecOps.

Hopefully this has been a useful intro, and you feel excited and motivated to learn more about DevSecOps next time.  (And if you don’t, just pretend.)


*I think because SecDevOps reads oddly, and DevOpsSec tends to get pluralised, and then you’re on an entirely different topic.

**I should note that this isn’t just to British audiences, who are reserved and don’t like drawing attention to themselves: this is to Canadian and US audiences who, well … are different in that regard.

***I’m going to be talking about Linux containers: I’m aware there’s history here, so it’s worth noting. In case of pedantry.

**** I used grep -ir container linux-4.9.2 | wc -l in case you’re interested*****.

***** to be fair, a number of those uses, at a quick glance, have nothing to do with containers in the way we’re discussing them “Linux containers”, but refer to abstractions which can be said to container other elements, and are, therefore, logically referred to as containers.

****** there are clever ways to combine VMs and containers to benefit from the strengths of each – I’m not going to go into those today.

******* well, apart from the execution bit that we just covered, obviously.

Being commercial

… given that I probably wouldn’t be writing this blog if I weren’t paid by my employer, I don’t feel to bad about mentioning our Summit…

I get paid*.  By Red Hat.  Not to write these blog posts, but to do a job of work.  The musings which make up this blog aren’t necessarily directly connected to the views of my employer (see standard disclaimer), but given that I try to conduct my work with integrity and to blog about stuff I believe in, there’s a pretty good correlation**.

Anyway, given that I probably wouldn’t be writing this blog if I weren’t paid by my employer, I don’t feel to bad about mentioning our Summit this week.  It’s my first one, and I’m involved in two sessions: one on moving to a hybrid (or multi-) cloud model, and one about the importance of systems security and what impact Open Source has on it (and vice versa).  There’s going to be a lot of security-related content, presented by some fantastic colleagues, partners and customers, and, depending on quite how busy things are, I’m hoping to post snippets here.

In the meantime, I’d like to invite anybody who reads this blog and will be attending the Red Hat Summit to get in touch – it would be great to meet you.

 


*which is, in my view, a Good Thing[tm].

**see one of my favourite xkcd cartoons.