people – Page 6 – Alice, Eve and Bob

5 (Professional) development tips for security folks

… write a review of “Sneakers” or “Hackers”…

To my wife’s surprise[1], I’m a manager these days. I only have one report, true, but he hasn’t quit[2], so I assume that I’ve not messed this management thing up completely[2]. One of the “joys” of management is that you get to perform performance and development (“P&D”) reviews, and it’s that time of year at the wonderful Red Hat (my employer). In my department, we’re being encouraged (Red Hat generally isn’t in favour of actually forcing people to do things) to move to “OKRs”, which are “Objectives and Key Results”. Like any management tool, they’re imperfect, but they’re better than some. You’re supposed to choose a small number of objectives (“learn a (specific) new language”), and then have some key results for each objective that can be measured somehow (“be able to check into a hotel”, “be able to order a round of drinks”) after a period of time (“by the end of the quarter”). I’m simplifying slightly, but that’s the general idea.

Anyway, I sometimes get asked by people looking to move into security for pointers to how to get into the field. My background and route to where I am is fairly atypical, so I’m very sensitive to the fact that some people won’t have taken Computer Science at university or college, and may be pursuing alternative tracks into the profession[3]. As a service to those, here are a few suggestions as to what they can do which take a more “OKR” approach than I provided in my previous article Getting started in IT security – an in/outsider’s view.

1. Learn a new language

And do it with security in mind. I’m not going to be horribly prescriptive about this: although there’s a lot to be said for languages which are aimed a security use cases (Rust is an obvious example), learning any new programming language, and thinking about how it handles (or fails to handle) security is going to benefit you. You’re going to want to choose key results that:

show that you understand what’s going on with key language constructs to do with security;
show that you understand some of what the advantages and disadvantages of the language;
(advanced) show how to misuse the language (so that you can spot similar mistakes in future).

2. Learn a new language (2)

This isn’t a typo. This time, I mean learn about how other functions within your organisations talk. All of these are useful:

risk and compliance
legal (contracts)
legal (Intellectual Property Rights)
marketing
strategy
human resources
sales
development
testing
UX (User Experience)
IT
workplace services

Who am I kidding? They’re all useful. You’re learning somebody else’s mode of thinking, what matters to them, and what makes them tick. Next time you design something, make a decision which touches on their world, or consider installing a new app, you’ll have another point of view to consider, and that’s got to be good. Key results might include:

giving a 15 minute presentation to the group about your work;
arranging a 15 minute presentation to your group about the other group’s work;
(advanced) giving a 15 minute presentation yourself to your group about the other group’s work.

3. Learning more about cryptography

So much of what we do as security people comes down to or includes some cryptography. Understanding how it should be used is important, but equally, being able to understand how it shouldn’t be used is something we should all understand. Most important, from my point of view, however, is to know the limits of your knowledge, and to be wise enough to call in a real cryptographic expert when you’re approaching those limits. Different people’s interests and abilities (in mathematics, apart from anything else) vary widely, so here is a broad list of different possible key results to consider:

learn when to use asymmetric cryptography, and when to use symmetric cryptography;
understand the basics of public key infrastructure (PKI);
understand what one-way functions are, and why they’re important;
understand the mathematics behind public key cryptography;
understand the various expiry and revocation options for certificates, their advantages and disadvantages.
(advanced) design a protocol using cryptographic primitives AND GET IT TORN APART BY AN EXPERT[4].

4. Learn to think about systems

Nothing that we manage, write, design or test exists on its own: it’s all part of a larger system. That system involves nasty awkwardnesses like managers, users, attackers, backhoes and tornadoes. Think about the larger context of what you’re doing, and you’ll be a better security person for it. Here are some suggestions for key results:

read a book about systems, e.g.:
- Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson;
- Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design, ed. Diomidis Spinellis and Georgios Gousios;
- Building Evolutionary Architectures: Support Constant Change by Neal Ford, Rebecca Parsons & Patrick Kua[5].
arrange for the operations folks in your organisation to give a 15 minute presentation to your group (I can pretty much guarantee that they think about security differently to you – unless you’re in the operations group already, of course);
map out a system you think you know well, and then consider all the different “external” factors that could negatively impact its security;
write a review of “Sneakers” or “Hackers”, highlighting how unrealistic the film[6] is, and how, equally, how right on the money it is.

5. Read a blog regularly

THIS blog, of course, would be my preference (I try to post every Tuesday), but getting into the habit of reading something security-related[7] on a regular basis means that you’re going to keep thinking about security from a point of view other than your own (which is a bit of a theme for this article). Alternatively, you can listen to a podcast, but as I don’t have a podcast myself, I clearly can’t endorse that[8]. Key results might include:

read a security blog once a week;
listen to a security podcast once a month;
write an article for a site such as (the brilliant) OpenSource.com[9].

Conclusion

I’m aware that I’ve abused the OKR approach somewhat by making a number of the key results non-measureable: sorry. Exactly what you choose will depend on you, your situation, how long the objectives last for, and a multitude of other factors, so adjust for your situation. Remember – you’re trying to develop yourself and your knowledge.

1 – and mine.

2 – yet.

3 – yes, I called it a profession. Feel free to chortle.

4 – the bit in CAPS is vitally, vitally important. If you ignore that, you’re missing the point.

5 – I’m currently reading this after hearing Dr Parsons speak at a conference. It’s good.

6 – movie.

7 – this blog is supposed to meet that criterion, and quite often does…

8 – smiley face. Ish.

9 – if you’re interested, please contact me – I’m a community moderator there.

Of headphones, caffeine and self-care

Being honest about being down.

I travel quite a lot with my job. This is fine, and what I signed up for, and mitigated significantly by the fact that I work from home the rest of the time, which means that (video-calls permitting) I can pop down to see the kids when they get back from school, or share a dog walk with my wife if she’s at home as well. The travel isn’t as easy as it was a couple of decades ago: I’d like to believe that this is because my trips are more frequent, and often longer, but suspect that it’s more to do with the passage of time on my body. There’s more than just the wear and tear, however, and I think it’s worth talking about it, but I’m sure it’s not just me.

I sometimes get down.

I sometimes get sad.

I sometimes get peeved, and cross, and angry for little or no reason.

I’ve never been diagnosed with any mental illness, and I don’t feel the need to medicalise what I’m describing, but I do need to own it: it’s not me at my best, I’m not going to be able to perform my job to the best of my ability, and it’s not healthy. I know that it’s worse when I’m travelling, because I’m away from my family, the dog and the cats, divorced from routine and, given that I tend to travel to North America quite frequently, somewhat jet-lagged. None of these things are specific triggers, and it’s not even that they are necessarily part of the cause, but they can all make it more difficult to achieve and even keel again.

I wanted to write about this subject because I had a day when I had what I think of as “a bit of a wobble”[1] a couple of weeks ago while travelling. On this particular occasion, I managed to step back a bit, and even did some reading around the web for suggestions about what to do. There were a few good blog articles, but I thought it would be honest to my – and others’ – lived experience to talk about it here, and talk about what works and what doesn’t.

Before we go any further, however, I’d like to make a few things clear.

First: if you are having suicidal thoughts, seek help. Now. You are valued, you do have worth, but I am not an expert, and you need to seek the help of an expert. Please do.

Second: I am not an expert in mental health, depression or other such issues. These are some thoughts about what helps me. If you have feelings and thoughts that disturb you or are having a negative impact on you or those around you, seek help. There should be no stigma either to mental illness or to seeking help to battle it.

Third: if you know someone who is suffering from mental illness of any kind, try to be supportive, try to be kind, try to be understanding. It is hard. I know people – and love people – with mental health issues. Help to support them in getting help for themselves, if that’s what they need you to do, and consider getting help for yourself, too.

Things that do and don’t work (for me)

Alcohol (and over-eating) – NO

One article I read pointed out that having a few drinks or eating a tub of ice cream when you’re travelling and feeling down “because you deserve it” isn’t self-care: it’s self-medication. I like this dictum. Alcohol, though a dis-inhibitor, is also a depressant, and even if it makes you feel better for a while, you’re not going to be thanking last-night-you for the hangover you have in the morning. Particularly if you’ve got a meeting or presentation in the morning.

Exercise – YES

I never used to bother much with exercise, particularly when I was travelling. But the years have taken their toll, and now I try to hit the gym when I’m staying in a hotel, maybe every other day. However, I also find that there are often opportunities to walk to meetings instead of taking a taxi, or maybe making my own way to a restaurant in the evening, even if I catch a cab back. I track the steps I do, and aim for 10,000 a day. This can be difficult when you’re in a meeting all day, but little things like taking the stairs, not the lift (elevator) can get you closer to your goal.

If you have a free day in a city, particularly at the weekend, do a search for “walking tours”. I’ve done a few of these, particularly food-based ones, where you get to stretch your legs whilst being given a tour of the sites and trying some local cuisine. You also get to meet some people, which can be good.

People – YES and NO

Sometimes what I need to pull myself out of a gloomy mood is to spend some time with people. Even if it’s just on the edges of a conversation, not engaging too much, being around people I know and value can be a positive thing.

On other occasions, it’s exactly the opposite of what I need, and I crave solitude. On occasion, I won’t know until I turn up for dinner, say, that I’m really not in the right head-space for company. I’ve found that if you plead jet-lag, colleagues are generally very understanding, and if there’s a loud-mouthed colleague who is very insistent that you stay and join in, find a quieter colleague and explain that you need to get back to the hotel early.

Reading – YES

Books are great to escape to. Whether you carry a paperback in your laptop bag, have a Kindle (or other e-reader) or just read something that you’ve downloaded onto your phone, you can go “somewhere else” for a bit. I find that having a physical book is helpful, or at least using an e-reader, as then you’re slightly protected from the temptation to check that email that’s just come in.

Headphones – YES

What did we do before headphones? I try keep a set in my pocket wherever I’m going and connect my phone when I get a chance. I may wander the floor of an Expo with music on, sit down with some music for a cup of tea (of which more below) in a five minute break during a meeting, or wait for a session to start with something soothing in my ears. In fact, it doesn’t need to be soothing: I can be in the mood for classical, upbeat, loud, quiet, downbeat, indie, New Orleans jazz, bluegrass[2] or folk[3]. That’s one of the joys of having music available at pretty much all times now. Insulating myself from the world and allowing myself to take a metaphorical breath before rejoining it, can make a big difference.

Caffeine – YES (with care)

I don’t drink coffee (I just don’t like the taste), but I do drink tea. It can be difficult to find a good cup of tea in North America[4], but I’ve discovered that when I can source one, the very act of sitting down and drinking it grounds me. Smell and taste are such important senses for us, and I associate the smell and taste of tea so strongly with home and safety that a good cup of tea can do wonders for me. That said, if I drink too much tea, I can get cranky (not to mention the fact that it’s a diuretic), and then I miss it if I can’t get it, so there’s a balance there.

Breathing – YES

Breathing is helpful, obviously. If you don’t breathe, you’re going to die[5], but there’s a real power to stopping what you’re doing, and taking a few deep, purposeful breaths. I’m sure there’s lots of science (and probably pseudo-science) around this, but try it: it can be really fantastic.

Conclusion

I know that I’m not alone in finding life difficult sometimes when I travel. Please look after yourself and find whatever actions which help you. My intention with this article isn’t to provide fixes for other people, but more to share a few things that help me, and most important, to acknowledge the problem. If we do this, we can recognise the need for action in ourselves, but also for support in our family, friends and colleagues, too.

Last: if you become ill – physically, emotionally or mentally – you are not going to be functioning as well as you might when well. It is in your and you organisation’s best interests for you to be well and healthy. Many companies, organisations and unions provide (often free) help for those who are struggling. If you keep experiencing feelings such as those described in this article, or you are in acute need, please seek professional help.

1 – because I’m British, and that’s the sort of language I use.

2 – one of my little guilty pleasures.

3 – another.

4 – you need decent tea to start with, and boiling or just off-boiling water: that’s close to 100C, or 212F.

5 – I’m not a medical expert, but I know that.

Equality in volunteering and open source

Volunteering favours the socially privileged

Volunteering is “in”. Lots of companies – particularly tech companies, it seems – provide incentives to employees to volunteer for charities, NGOs and 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.

3 – a friend reminded me that it might have been this: https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community

Cryptographers arise!

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.

Merry “sorting out relatives’ IT problems” Day

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.

Merry Christmas, and a Happy New Year to you all.

1 – this, folks, is how to stay married for 23 and a half years[2].

2 – and counting.

On being acquired – a personal view

It’s difficult to think of a better fit than IBM.

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.

1 – because, well, lawyers, the SEC, etc., etc.

2 – if it does, then, well, could somebody please contact me?

3 – doing its own thing independently.

Knowing me, knowing you: on Russian spies and identity

Who are you, and who tells me so?

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 conversation and the benefits of boasting

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.

1 – I gave a talk based on my blog article Why I love technical debt. I found it interesting…

2 – based on this definition, it may surprise regular readers – and people who know me IRL[3] – that I’d even consider participating, let alone facilitating.

3 – does anybody use this term anymore?

4 – Liberal Arts/Social Sciences.

5 – but included:

the impact of different open source licences
how legal teams engage with open source questions
how to encourage more conversation between technical and legal folks
the importance of systems engineering
how to talk to customers and vendors
how to build teams through social participation[6]
the NIST 800 series and other models to consider security
risk: how to talk about it, measure it, discuss it with other functions within the organisation.

6 – the word “beer” came up. From somebody else, on this occasion.

16 ways in which users are(n’t) like kittens

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.

10 – see picture.

11 – unused.

12 – intentionally left blank.

13 – unintentionally left blank.

The gift that keeps on giving: passwords

A Father’s Day special

There’s an old saying: “if you give a man a fish, he’ll eat for a day, but if you teach a man to fish, he’ll eat for a lifetime.” There are some cruel alternatives with endings like “he’ll buy a silly hat and sit outside in the rain”, but the general idea is that it’s better to teach someone something rather than just giving them something.

With Father’s Day coming up this Sunday in many parts of the world, I’d like to suggest the same for passwords. Many people’s password practices are terrible. There are three things that people really don’t get about passwords:

what they should look like
how they should be stored
how they should be communicated.

Let’s go through each of these in turn, and I’ll try to give brief tips that you can pass onto your father (or, indeed, mother, broader family, friends or colleagues) to help them with password safety.

What should passwords look like?

There’s a famous xkcd comic called password strength which aims to help you find a useful password. This is great advice if you only have a few passwords, but about twenty years ago I got above ten, and then started re-using passwords for certain levels of security. This was terrible at the time, and even worse now. Look at the the number of times a week we see news about information being lost when companies or organisations are hacked. If you share passwords between accounts, there’s a decent chance that your login details for one will be exposed, which means that all your other accounts that share that set are compromised.

I know some people who used to have permutations of passwords. Let’s say the base was “p4ssw0rd”: they would then add a suffix for the website or account, such as “p4ssw0rdNetflix”. This might be fine if we believed that all passwords are stored in hashed form, but, well, we know they’re not, so don’t do this, either. Extrapolating from one account to another is too easy.

What does a good password look like, then? Here’s one: “W9#!=_twXhRb” And another? This one is 16 characters long: “*Wdb_%|#N^X6CR_b” What are the chances of a human guessing these? Pretty slim. And a computer? Not much better, to be honest. They are randomly generated by software, and as long as I use a different one for each account, I’m pretty safe against password-guessing attacks.

“But,” you say, “how am I supposed to remember them? I’ve got dozens of accounts, and I can’t remember one of those, let alone fifty!”

How should you store passwords?

Well, you shouldn’t try to remember passwords, in the same way that you shouldn’t try to generate them. Oh, there will be a handful that you might remember – maybe low-importance ones like the wifi key to your home AP – but most of them you should trust to a password manager. These are nifty pieces of software that will generate and then remember hundreds of passwords for you. Some of them will even automatically fill website fields for you if you ask them to. The best ones are open source, which means that people have pored over their code (hopefully) to check they’re trustworthy, and that if you’re not entirely sure, then you can pore of their code, too. And make changes and improvements and generally improve the world bit by bit.

You will need to remember one password, though, and that’s the one to unlock the password manager. Make it really, really strong: it’s about the only one you mustn’t lose (though most websites will help you reset a password if you forget it, so it’s just a matter of going through each of the several hundred until they’re done…). Use the advice from the xkcd cartoon, or another strong password algorithm that’s easy to remember.

To make things more safe, store the (password protected) key store somewhere that is not easily accessed by other people – not a shared drive at work, for instance, but maybe on your phone or on some cloud-based storage that you can get to if you lose your phone. Always set the password manager to auto-lock itself after some time, in case you leave your computer logged on, or your phone gets stolen.

How to communicate passwords

Would you send a password via email? What about by SMS? Is post[2] better? Is it acceptable to reveal a password over the phone in a crowded train carriage[4]? Would you give your laptop password to a random person conducting a survey on a railway station for the prize of a chocolate bar?

In an ideal world, we would never share passwords, but there are times when we need to – and times when it’s worthwhile for material rewards[5]. There are some accounts which are shared – TV or film streaming accounts for the family – or that you’ve set up for somebody else, or which somebody urgently needs to access because you’re on holiday, for instance. So you may need to give out passwords from time to time. What’s the best mechanism? What’s the worst?

This may sound surprising, but I’d generally say that the worst (marginally) is post. What you’re trying to avoid happening is a Bad Person[tm] from marrying two pieces of information: the username and the password. If someone has access to your post, then there’s a good chance that they might be able to work out enough information about you that they can guess the account name. The others? Well, they’re OK as long as you’re not also sending the username via the same channel. That, in fact, is the key test: you should never provide the two pieces of information in such a way that a person with access to one channel can put them together. So, telling someone a password in a crowded train carriage may be rude in relation to all of the other people in the carriage[6], but it may be very secure in terms of account safety.

The reason I posed the question about the survey is that every few months a survey company in the UK asks people at mainline railway stations to tell them their password in exchange for a chocolate bar, and then write a headline about how awful it is that many people will give them their password. This is a stupid headline, for a stupid survey, for two reasons:

I’d happily lie and tell them a false password in order to get a free chocolate bar AND
even if I gave them the correct password, how are they going to marry that with my account details?

Conclusion

If you’re the sort of person reading there’s a fairly high chance that you’re the sort of person who’s asked to clear up the mess what family, friends or colleagues get their accounts compromised[7]. Here are four rules for password security:

don’t reuse passwords – use a different one for every single account
don’t think up your own passwords – get a password manager to generate them for you
use a password manager to store your passwords – if they’re strong enough in the first place, you won’t be able to remember them
never send usernames and passwords over the same channel – you want to avoid the situation where an attacker has access to both and can use them.

I’ll add a fifth one for luck: feel free to use underhand tactics to get chocolate bars from people performing poorly-designed surveys on railway stations.

1 – I thought about changing the order, as they do impact on each other, but it made my head hurt, so I stopped.

2 – note for younger readers: there used to be something called “snail mail”. It’s nearly dead[3].

3 – unless you forget to turn on “electronic statements” for your bank account. Then you’ll get loads of it.

4 – whatever the answer to this is from a security point of view, the correct answer is “no”, because a) you’re going to annoy me by shouting it repeatedly down the phone because reception is so bad on the train that the recipient can’t hear it and b) because reception is so bad on the train that the recipient can’t hear it (see b)).

5 – I like chocolate.

6 – I’m not a big fan of phone conversations in railway carriages, to be honest.

7 – Or you’ve been sent a link to this because you are one of those family, friends or colleagues, and the person who sent you the link is sick and tired of doing all of your IT dirty work for you.