Tag: people

Volunteering is “in”. Lots of companies – particularly tech companies, it seems – provide incentives to employees to volunteer for charities, NGOs abs other “not-for-profits”. These incentives range from donations matching to paid volunteer days to matching hours worked for a charity with a cash donation.

Then there’s other types of voluntary work: helping out at a local sports club, mowing a neighbour’s lawn or fetching their groceries, and, of course, a open source, which we’ll be looking at in some detail. There are almost countless thousands of projects which could benefit from your time.

Let’s step back first and look at the benefits of volunteering. The most obvious, if course, is the direct benefit to the organisation, group or individual of your time and/or expertise. Then there’s the benefits to the wider community. Having people volunteering their time to help out with various groups – particularly those with whom they would have little contact in other circumstances – helps social cohesion and encourages better understanding of differing points of view as you meet people, and not just opinions.

Then there’s the benefit to you. Helping others feels great, looks good on your CV[1], can give you more skills, and make you friends – quite apart from the benefit I mentioned above about helping you to understand differing points of view. On the issue of open source, it’s something that lots of companies – certainly the sorts of companies with which I’m generally involved – are interested in, or even expect to see on your CV. Your contributions to open source projects are visible – unlike whatever you’ve been doing in most other jobs – they can be looked over, they show a commitment and are also a way of gauging your enthusiasm, expertise and knowledge in particular areas. All this seems to make lots of sense, and until fairly recently, I was concerned when I was confronted with a CV which didn’t have any open source contributions that I could check.

The inequality of volunteering

And then I did some reading by a feminist open sourcer (I’m afraid that I can’t remember who it was[3]), and did a little more digging, and realised that it’s far from that simple. Volunteering is an activity which favours the socially privileged – whether that’s in terms of income, gender, language or any other number of indicator. That’s particularly true for software and open source volunteering.

Let me explain. We’ll start with the gender issue. On average, you’re much less likely to have spare time to be involved in an open source project if you’re a woman, because women, on average, have more responsibilities in the home, and less free time. They are also globally less likely to have access to computing resources with which to contribute. due to wage discrepancies. Even beyond that, they are less likely to be welcomed into communities and have their contributions valued, whilst being more likely to attract abuse.

If you are in a low income bracket, you are less likely to have time to volunteer, and again, to have access to the resources needed to contribute.

If your first language is not English, you are less likely to be able to find an accepting project, and more likely to receive abuse for not explaining what you are doing.

If your name reflects a particular ethnicity, you may not be made to feel welcome in some contexts online.

If you are not neurotypical (e.g. you have Aspergers or are on the autism spectrum, or if you are dyslexic), you may face problems in engaging in the social activities – online and offline – which are important to full participation in many projects.

The list goes on. There are, of course, many welcoming project and communities that attempt to address all of these issues, and we must encourage that. Some people who are disadvantaged in terms of some of the privilege-types that I’ve noted above may actually find that open source suits them very well, as their privilege can be hidden online in ways in which it could not be in other settings, and that some communities make a special effort to be welcoming and accepting.

However, if we just assume – that’s unconscious bias, folks – that volunteering, and specifically open source volunteering, is a sine qua non for “serious” candidates for roles, or a foundational required expertise for someone we are looking to employ, then we set a dangerous precedent, and run a very real danger of reinforcing privilege, rather than reducing it.

What can we do?

First, we can make our open source projects more welcoming, and be aware of the problems that those from less privileged groups may face. Second, we must be aware, and make our colleagues aware, that when we are interviewing and hiring, lack evidence of volunteering is not evidence that the person is not talented, enthusiastic or skilled. Third, and always, we should look for more ways to help those who are less privileged than us to overcome the barriers to accessing not only jobs but also volunteering opportunities which will benefit not only them, but our communities as a whole.

1 – Curriculum vitae[2].

2 – Oh, you wanted the Americanism? It’s “resume” or something similar, but with more accents on it.

Cryptography is a strange field, in that it’s both concerned with keeping secrets, but also has a long history of being kept secret, as well. There are famous names from the early days, from Caesar (Julius, that is) to Vigenère, to more recent names like Diffie, Hellman[1], Rivest, Shamir and Adleman. The trend even more recently has been away from naming cryptographic protocols after their creators, and more to snappy names like Blowfish or less snappy descriptions such as “ECC”. Although I’m not generally a fan of glorifying individual talent over collective work, this feels like a bit of a pity in some ways.

In fact, over the past 80 years or so, more effort has been probably put into keeping the work of teams in cryptanalysis – the study of breaking cryptography – secret, though there are some famous names from the past like Al-Kindi, Phelippes (or “Phillips), Rejewski, Turing, Tiltman, Knox and Briggs[2].

Cryptography is difficult. Actually, let me rephrase that: cryptography is easy to do badly, and difficult to do well. “Anybody can design a cipher that they can’t break”, goes an old dictum, with the second half of the sentence, “and somebody else can easily break”, being generally left unsaid. Creation of cryptographic primitives requires significant of knowledge of mathematics – some branches of which are well within the grasp of an average high-school student, and some of which are considerably more arcane. Putting those primitives together in ways that allow you to create interesting protocols for use in the real world doesn’t necessarily require that you understand the full depth of the mathematics of the primitives that you’re using[3], but does require a good grounding in how they should be used, and how they should not be used. Even then, a wise protocol designer, like a wise cryptographer[4], always gets colleagues and others to review his or her work. This is one of the reasons that it’s so important that cryptography should be in the public domain, and preferably fully open source.

Why am I writing about this? Well, partly because I think that, on the whole, the work of cryptographers is undervalued. The work they do is not only very tricky, but also vital. We need cryptographers and cryptanalysts to be working in the public realm, designing new algorithms and breaking old (and, I suppose) new ones. We should be recognising and celebrating their work. Mathematics is not standing still, and, as I wrote recently, quantum computing is threatening to chip away at our privacy and secrecy. The other reasons that I’m writing about this is because I think we should be proud of our history and heritage, inspired to work on important problems, and to inspire those around us to work on them, too.

Oh, and if you’re interested in the t-shirt, drop me a line or put something in the comments.

1 – I’m good at spelling, really I am, but I need to check the number of ells and ens in his name every single time.

2 – I know that is heavily Bletchley-centric: it’s an area of history in which I’m particularly interested. Bletchley was also an important training ground for some very important women in security – something of which we have maybe lost sight.

3 – good thing, too, as I’m not a mathematician, but I have designed the odd protocol here and there.

4 – that is, any cryptographer who recognises the truth of the dictum I quote above.

Today’s the day – or the season – when your mother-in-law asks you to fix her five year old laptop, unclog the wifi (it’s usually her husband, “stealing it all”) or explain why her mouse mat is actually easily large enough – she just needs to lift the mouse up and place it back in the middle if she can’t get the cursor to go any further right.

Lucky me: I didn’t even have to wait till Christmas Day this year: my m-in-law called us at home a couple of days ago to complain that “the email thingy isn’t working on my tablet and the Chrome has gone”. After establishing that her Chrome Book (upstairs) was fine, and she just couldn’t be bothered to ascend the stairs to use it for the two days before we came to visit and I could debug her tablet problem in person, I proceeded to debug the problem over the crackly wireless DECT phone they keep attached to their land line, instead[1].

Despite the difficulty in making out approximately 25% of the words down the line, I became more and more convinced that even if her tablet was having problems, then a reboot of her router was probably due.

Me: so you know which one the router is?

Her: umm…

Me: it’s the little box where the Internet comes in.

Her: is it in the hall?

Me, to the wife, who’s smirking, since she managed to offload this call to me: could it be in the hall?

Wife: yes, it’s in the hall.

Me: yes, it’s in the hall.

Mother-in-law: OK.

Me: there should be a power button on the front or the back, or you can just pull the power lead out if that’s easiest.

Her, clearly bending over to look at it: shall I just turn it off at the wall? That might be simplest?

Me: well, OK.

Her: Right, I’m doing that n… BEEEEEEEEEEEEEEP.

It turns out that her DECT phone hub is plugged into the same socket. Of course. This is my life. This is OUR life.

First off, today is one of those days when I need to point you at the standard disclaimer that the views expressed in this post are my own, and not necessarily those of my employers. That said, I think that many of them probably align, but better safe than sorry[1]. Another note: I believe that all of the information in this article is public knowledge.

The news came out two days ago (last Sunday, 2018-10-28) that Red Hat, my employer, is being acquired by IBM for $34bn. I didn’t know about it the deal in advance (I’m not that exalted within the company hierarchy, which is probably a good thing, as all those involved needed to keep very tight-lipped about it, and that would have been hard), so the first intimation I got was when people started sharing stories from various news sites on internal chat discussions. They (IBM) are quite clear about the fact that they are acquiring us for the people, which means that each of us (including me!) is worth around $2.6m, based on our current headcount. Sadly, I don’t think it works quite like this, and certainly nobody has (yet) offered to pay me that amount[2]. IBM have also said that they intend to keep Red Hat operating as a separate entity within IBM.

How do I feel? My initial emotion was shock. It’s always a surprise when you get news that you weren’t expecting, and the message that we’d carried for a long time was the Red Hat would attempt to keep ploughing its own furrow[3] for as long as possible. But I’d always known that, as a public company, we were available to be bought, if the money was good enough. It appears on this occasion that it was. And that emotion turned to interest as to what was going to happen next.

And do you know what? It’s difficult to think of a better fit than IBM. I’m not going to enumerate the reasons that I feel that other possible acquirers would have been worse, but here are some of the reasons that IBM, at least in this arrangement, is good:

they “get” open source, and have a long history of encouraging its use;

they seem to understand that Red Hat has a very distinctive culture, and want to encourage that, post-acquisition;

they have a hybrid cloud strategy and products, Red Hat has a hybrid cloud strategy and products: they’re fairly well-aligned;

we’re complementary in a number of sectors and markets;

they’re a much bigger player than us, and suddenly, we’ll have access to more senior people in new and exciting companies.

What about the impact on me, though? Well, IBM takes security seriously. IBM has some fantastic research and academic connections. The group in which I work has some really bright and interesting people in it, and it’s difficult to imagine IBM wanting to break it up. A number of the things I’m working on will continue to align with both Red Hat’s direction and IBM’s. The acquisition will take up to a year to complete – assuming no awkward regulatory hurdles along the way – and not much is going to change in the day-to-day. Except that I hope to get even better access to my soon-to-be-colleagues working in similar fields to me, but within IBM.

Will there be issues along the way? Yes. Will there be uncertainty? Yes. But do I trust that the leadership within Red Hat and IBM have an honest commitment to making things work in a way that will benefit Red Hatters? Yes.

And am I looking to jump ship? Oh, no. Far too much interesting stuff to be doing. We’ve got an interesting few months and years ahead of us. My future looked red, until Sunday night. Then maybe blue. But now I’m betting on something somewhere between the two: go Team Purple.

Who are you, and who tells me so? These are questions which are really important for almost any IT-related system in use today. I’ve previously discussed the difference between identification and authentication (and three other oft-confused terms) in Explained: five misused security words, and what I want to look at in this post is the shady hinterland between identification and authentication.

There has been a lot in the news recently about the poisoning in the UK of two Russian nationals and two British nationals, leading to the tragic death of Dawn Sturgess. I’m not going to talk about that, or even about the alleged perpetrators, but about the problem of identity – their identity – and how that relates to IT. The two men who travelled to Salisbury, and were named by British police as the perpetrators, travelled under Russian passports. These documents provided their identities, as far as the British authorities – including UK Border Control, who allowed them into the country – were aware, and led to their being allowed into the country.

When we set up a new user in an IT system or allow them physical access to a building, for instance, we often ask for “Government-issued ID” as the basis for authenticating the identity that they have presented, in preparation for deciding whether to authorise them to perform whatever action they have requested. There are two issues here – one obvious, and one less so. The first, obvious one, is that it’s not always easy to tell whether a document has actually been issued by the authority by which it appears to be have been issued – document forgers have been making a prosperous living for hundreds, if not thousands of years. The problem, of course, is that the more tell-tale signs of authenticity you reveal to those whose job it is to check a document, the more clues you give to would-be forgers for how to improve the quality of the false versions that they create.

The second, and less obvious problem, is that just because a document has been issued by a government authority doesn’t mean that it is real. Well, actually, it does, and there’s the issue. Its issuance by the approved authority makes it real – that is to say “authentic” – but it doesn’t mean that it is correct.Correctness is a different property to authenticity. Any authority may decide to issue identification documents that may be authentic, but do not truly represent the identity of the person carrying them. When we realise that a claim of identity is backed up by an authority which is issuing documents that we do not believe to be correct, that means that we should change our trust relationship with that authority. For most entities, IDs which have been authentically issued by a government authority are quite sufficient, but it is quite plausible, for instance, that the UK Border Force (and other equivalent entities around the world) may choose to view passports issued by certain government authorities as suspect in terms of their correctness.

What impact does this have on the wider IT security community? Well, there are times when we are accepting government-issued ID when we might want to check with relevant home nation authorities as to whether we should trust them[1]. More broadly than that, we must remember that every time that we authenticate a user, we are making a decision to trust the authority that represented that user’s identity to us. The level of trust we place in that authority may safely be reduced as we grow to know that user, but it may not – either because our interactions are infrequent, or maybe because we need to consider that they are playing “the long game”, and are acting as so-called “sleepers”.

What does this continuous trust mean? What it means is that if we are relying on an external supplier to provide contractors for us, we need to keep remembering that this is a trust relationship, and one which can change. If one of those contractors turns out to have faked educational qualifications, then we need to doubt the authenticity of the educational qualifications of all of the other contractors – and possibly other aspects of the identity which the external supplier has presented to us. This is because we have placed transitive trust in the external supplier, which we must now re-evaluate. What other examples might there be? The problem is that the particular aspects of identity that we care about are so varied and differ between different roles that we perform. Sometimes, we might not care about education qualifications, but credit score, or criminal background, or blood type. In the film Gattaca[2], identity is tied to physical and mental ability to perform a particular task.

There are various techniques available to allow us to tie a particular individual to a set of pieces of information: DNA, iris scans and fingerprints are pretty good at telling us that the person in front of us now is the person who was in front of us a year ago. But tying that person to other information relies on trust relationships with external entities, and apart from a typically small set of inferences that we can draw from our direct experiences of this person, it’s difficult to know exactly what is truly correct unless we can trust those external entities.

1 – That assumes, of course, that we trust our home nation authorities…

2 – I’m not going to put a spoiler in here, but it’s a great film, and really makes you think about identity: go and watch it!

On Monday and Tuesday this week I’m attending DevSecCon in Boston – a city which is much more pleasant when it’s not raining or snowing, which it often seems to be doing while I’m here. There are a bunch of interesting talks[1] and workshops, and I was asked, at the last minute, to facilitate an “Open Space Discussion” at the end of the first day (as two people hadn’t arrived as expected). Facilitating discussions is about not talking all the time, but encouraging other people to talk[2]: my approach to this is to tell a story, and then encourage them to share stories.

People enjoy listening to stories, and people enjoy telling stories, and there is a type of story that is particularly useful and important in the world of work: “war-stories”. Within the IT industry, at least, this refers to stories about experiences – usually bad experiences – from our day-to-day working lives. They are often used to illustrate a point or lend experiential weight to an opinion being put forward. But they are also great learning experiences.

What I learned yesterday – or re-learned – is the immense value of conversation with our peers in a neutral setting, with no formal bounds or difference in “rank”. We had at least one participant who was only two years out of college, participants with 25-30 years of experience, a CISO of a major healthcare provider, a CEO, DevOps engineers, customer-facing people, security people, non-security people, people with Humanities[4] degrees, people with Computer Science degrees. We were about twelve people, and everybody contributed, to greater or lesser degrees. I hope that we managed to maintain a conversation where age and numbers of years in the industry were unimportant, but the experiences shared were.

And I learned about other people’s opinions, their viewpoints, their experiences, their tips for what works – and doesn’t work – and made, I hope, some new friends. Certainly some new peers. What we talked about isn’t vitally important to this article[5]: the important thing was the conversation, and the stories they told that brought their shared wisdom to the table. I felt, by the end of the session, that we had added something to the commonwealth of knowledge within the industry

I was looking for a way to close the session as we were moving to the end, and hit upon something which seemed to work: I encouraged everybody to spend 30 seconds or so to tell the group about an incident in their career that they are proud of. We got some great stories, and not only did we learn from them, but I think it’s really important that we get the chance to express our pride in the things that we’ve done. We rarely get the chance to boast, or to let people outside our general circle know why we think we should be valued. There’s nothing wrong with being proud of the things we’ve done, but we’re often – usually – discouraged from doing so. It was great to have people share their various experiences of personal expertise, and to think about how they would use them to further their career. I didn’t force everybody to speak – and was thanked by one of the silent participants later – and it’s important to realise that not everybody will be happy doing so. But I think that the rapport that we’d built as a group meant that more people were happy to contribute something than would have considered it at the beginning of the session. I left with a respect for all of the participants, and a realisation of the importance of shared experience.

I’m going to exploit you all with an article about kittens and security.

It’s summer[1], it’s hot[2], nobody wants to work[3]. What we all want to do is look at pictures of cute kittens[5] and go “ahhh”. So I’m going to exploit you all with an article about kittens and (vaguely about) security. It’s light-hearted, it’s fluffy[6], and it has a picture of two of our cats at the top of it. What’s not to like?

Warning: this article includes extreme footnoting, and may not be suitable for all readers[7].

Now, don’t get me wrong: I like users. realise the importance of users, really I do. They are the reason we have jobs. Unluckily, they’re often the reason we wish we didn’t have the jobs we do. I’m surprised that nobody has previously bothered to compile a list comparing them with kittens[7.5], so I’ve done it for you. For ease of reading, I’ve grouped ways in which users are like kittens towards the top of the table, and ways in which they’re unlike kittens towards the bottom[7.8].

Please enjoy this post, share it inappropriately on social media and feel free to suggest other ways in which kittens and users are similar or dissimilar.

Research findings

Hastily compiled table

Property

Users

Kittens

Capable of circumventing elaborate security measures

Yes

Yes

Take up all of your time

Yes

Yes

Do things they’re not supposed to

Yes

Yes

Forget all training instantly

Yes

Yes

Damage sensitive equipment

Yes

Yes

Can often be found on Facebook

Yes

Yes

Constantly need cleaning up after

Yes

Yes

Often seem quite stupid, but are capable of extreme cunning at inopportune moments

Yes

Yes

Can turn savage for no obvious reason

Yes

Yes

Can be difficult to tell apart[10]

Yes

Yes

Fluffy

No[8]

Yes

Fall asleep a lot

No[8]

Yes

Wake you up at night

No[9]

Yes

Like to have their tummy tickled

No[8]

Yes

Generally fun to be around

No[8]

Yes

Generally lovable

No[8]

Yes

1 – at time of writing, in the Northern Hemisphere, where I’m currently located. Apologies to all those readers for whom it is not summer.

2 – see 1.

3 – actually, I don’t think this needs a disclaimer[4].

4 – sorry for wasting your time[4].

5 – for younger readers, “kittehs”.

6 – like the kittens.

7 – particularly those who object to footnotes. You know who you are.

7.5 – actually, they may well have done, but I couldn’t be bothered to look[7.7]

7.7 – yes, I wrote the rest of the article first and then realised that I needed another footnote (now two), but couldn’t be bothered to renumber them all. I’m lazy.

7.8 – you’re welcome[7.9].

7.9 – you know, this reminds me of programming BASIC in the old days, when it wasn’t easy to renumber your program, and you’d start out numbering in 10s, and then fill in the blanks and hope you didn’t need too many extra lines[7.95].

7.95 – b*gger.

8 – with some exceptions.

9 – unless you’re on support duty. Then you can be pretty sure that they will.