8 tips on how to do open source (badly)

Generally, a “build successful” or “build failed” message should be sufficient.

A while ago, I published my wildly popular[1] article How not to make a cup of tea. Casting around for something to write this week, it occurred to me that I might write about something that I believe is almost as important as to world peace, the forward march of progress and brotherly/sisterly love: open source projects. There are so many guides out there around how to create an open source project that it’s become almost too easy to start a new, successful, community-supported one. I think it’s time to redress the balance, and give you some clues about how not to do it.

Throw it over the wall

You know how it is: you’re a large corporation, you’ve had a team of developers working on a project for several years now, and you’re very happy with it. It’s quite expensive to maintain and improve the code, but luckily, it’s occurred to you that other people might want to use it – or bits of it. And recently, some of your customers have complained that it’s difficult to get improvements and new features, and partners complain that your APIs are obscure, ill-defined and subject to undocumented change.

Then you hit on a brilliant idea: why not open source it and tell them their worries are over? All you need to do is take the existing code, create a GitHub or GitLab[2] project (preferably under a Game of Thrones-themed username that happens to belong to one of your developers), make a public repository, upload all of the code, and put out a press release announcing: a) the availability of your project; and b) what a great open source citizen you are.

People will be falling over themselves to contribute to your project, and you’ll suddenly have hundreds of developers basically working for you for free, providing new features and bug fixes!

Keep a tight grip on the project

There’s a danger, however, when you make your project open source, that other people will think that they have a right to make changes to it. The way it’s supposed to work is that your product manager comes up with a bunch of new features that need implementing, and posts them as issues on the repository. Your lucky new contributors then get to write code to satisfy the new features, you get to test them, and then, if they’re OK, you can accept them into the project! Free development! Sometimes, if you’re lucky, customers or partners (the only two parties of any importance in this process, apart from you) will raise issues on the project repository, which, when appropriately subjected to your standard waterfall development process and vetted by the appropriate product managers, can be accepted as “approved” issues and earmarked for inclusion into the project.

There’s a danger that, as you’ve made the project code open source, some people might see this as an excuse to write irrelevant features and fixes for bugs that none of your customers have noticed (and therefore, you can safely assume, don’t care about). Clearly, in this case, you should reject close any issues related to such features or fixes, and reject (or just ignore) any related patched.

Worse yet, you’ll sometimes find developers[2] complaining about how you run the project. They may “fork” the project, making their own version. If they do this, beware setting your legal department on them. There’s a possibility that as your project is open source, they might be able to argue that they have a right to create a new version. Much better is to set your PR department on them, rubbishing the new project, launching ad hominem[4] attacks on them and showing everybody that you hold the moral high ground.

Embrace diversity (in licensing)

There may be some in your organisation who say that an open source project doesn’t need a licence[5]. Do not listen to their siren song: they are wrong. What your open source project needs is lots of licences! Let your developers choose their favourite for each file they touch, or, even better, let the project manager choose. The OSI maintains a useful list, but consider this just a starting point: why not liberally sprinkle different licences through your project? Diversity, we keep hearing, is good, so why not apply it to your open source project code?

Avoid documentation

Some people suggest that documentation can be useful for open source projects, and they are right. What few of them seem to understand is that their expectations for the type of documentation are likely to be skewed by their previous experience. You, on the other hand, have a wealth of internal project documentation and external product marketing material that you accrued before deciding to make your project open source: this is great news. All you need to do is to create a “docs” folder and copy all of the PDF files there. Don’t forget to update them whenever you do a new product version!

Avoid tooling

All you need is code (and docs – see above). Your internal developers have carefully constructed and maintained build environments, and they should therefore have no problems building and testing any parts of the project. Much of this tooling, being internal, could be considered proprietary, and the details must therefore be kept confidential. Any truly useful contributors will be able to work out everything they need for themselves, and shouldn’t need any help, so providing any information about how actually to build the code in the repository is basically redundant: don’t bother.

An alternative, for more “expert” organisations, is to provide build environments which allow contributors to batch builds to see if they compile or not (whilst avoiding giving them access to the tooling themselves, obviously). While this can work, beware providing too much in the way of output for the developer/tester, as this might expose confidential information. Generally, a “build successful” or “build failed” message should be sufficient.

Avoid diagrams

Despite what some people think, diagrams are dangerous. They can give away too much information about your underlying assumptions for the project (and, therefore, the product you’re selling which is based on it), and serious developers should be able to divine all they need from the 1,500 source files that you’ve deposited in the repository anyway.

A few “marketiture” diagrams from earlier iterations of the project may be acceptable, but only if they are somewhat outdated and don’t provide any real insight into the existing structure of the code.

Keep quiet

Sometimes, contributors – or those hoping to become contributors, should you smile upon their requests – will ask questions. In the old days, these questions tended to be sent to email lists[6], where they could be safely ignored (unless they were from an important customer). More recently, there are other channels that developers expect to use to contact members of the project team, such as issues or chat.

It’s important that you remember that you have no responsibility or duty to these external contributors: they are supposed to be helping you. What’s more, your internal developers will be too busy writing code to answer the sort of uninformed queries that are likely to be raised (and as for so-called “vulnerability disclosures“, you can just fix those in your internal version of the product, or at least reassure your customers that you have). Given that most open source projects will come with an issue database, and possibly even a chat channel, what should you do?

The answer is simple: fall back to email. Insist that the only channel which is guaranteed attention[7] is email. Don’t make the mistake of failing to create an email address to which people can send queries: contributors are much more likely to forget that they’re expecting an answer to an email if they get generic auto-response (“Thanks for your email: a member of the team should get back to you shortly”) than if they receive a bounce message. Oh, and close any issues that people create without your permission for “failing to follow project process”[8].

Post huge commits

Nobody[9] wants to have to keep track of lots of tiny changes to code (or, worse, documentation – see above), or have contributors picking holes in it. There’s a useful way to avoid much of this, however, which is to train your developers only to post large commits to the open source project. You need to ensure that your internal developers understand that code should only be posted to the external repository when the project team (or, more specifically, the product team) deems it ready. Don’t be tempted to use the open source repository as your version control system: you should have perfectly good processes internally, and, with a bit of automation, you can set them up to copy batches of updates to the external repository on a regular basis[10].

1 – well, lots of you read it, so I’m assuming you like it.

2 – other public repositories may be available, but you won’t have heard of them, so why should you care?

3 – the canonical term for such people is “whingers”: they are invariably “experts”. According to them (and their 20 years of security experience, etc., etc.).

4 – or ad mulierem – please don’t be sexist in your attacks.

5 – or license, depending on your spelling choice.

6 – where they existed – a wise organisation could carefully avoid creating them.

7 – “attention” can include a “delete all” filter.

8 – you don’t actually need to define what the process is anywhere, obviously.

9 – in your product organisation, at least.

10 – not that “regular” does not equate to “frequent”. Aim for a cadence of once every month or two.

5 security tips from Santa

Have you been naughty or nice this year?

If you’re reading this in 2019, it’s less than a month to Christmas (as celebrated according to the Western Christian calendar), or Christmas has just passed.  Let’s assume that it’s the former, and that, like all children and IT professionals, it’s time to write your letter to Santa/St Nick/Father Christmas.  Don’t forget, those who have been good get nice presents, and those who don’t get coal.  Coal is not a clean-burning fuel these days, and with climate change well and truly upon us[1], you don’t want to be going for the latter option.

Think back to all of the good security practices you’ve adopted over the past 11 or so months.  And then think back to all the bad security practices you’ve adopted when you should have been doing the right thing.  Oh, dear.  It’s not looking good for you, is it?

Here’s the good news, though: unless you’re reading this very, very close to Christmas itself[2], then there’s time to make amends.  Here’s a list of useful security tips and practices that Santa follows, and which are therefore bound to put you on his “good” side.

Use a password manager

Santa is very careful with his passwords.  Here’s a little secret: from time to time, rather than have his elves handcraft every little present, he sources his gifts from other parties.  I’m not suggesting that he pays market rates (he’s ordering in bulk, and he has a very, very good credit rating), but he uses lots of different suppliers, and he’s aware that not all of them take security as seriously as he does.  He doesn’t want all of his account logins to be leaked if one of his suppliers is hacked, so he uses separate passwords for each account.  Now, Santa, being Santa, could remember all of these details if he wanted to, and even generate passwords that meet all the relevant complexity requirements for each site, but he uses an open source password manager for safety, and for succession planning[3].

Manage personal information properly

You may work for a large company, organisation or government, and you may think that you have lots of customers and associated data, but consider Santa.  He manages, or has managed, names, dates of birth, addresses, hobby, shoe sizes, colour preferences and other personal data for literally every person on Earth.  That’s an awful lot of sensitive data, and it needs to be protected.  When people grow too old for presents from Santa[4], he needs to delete their data securely.  Santa may well have been the archetypal GDPR Data Controller, and he needs to be very careful who and what can access the data that he holds.  Of course, he encrypts all the data, and is very careful about key management.  He’s also very aware of the dangers associated with Cold Boot Attacks (given the average temperature around his relevance), so he ensures that data is properly wiped before shutdown.

Measure and mitigate risk

Santa knows all about risk.  He has complex systems for ordering, fulfilment, travel planning, logistics and delivery that are the envy of most of the world.  He understands what impact failure in any particular part of the supply chain can have on his customers: mainly children and IT professionals.  He quantifies risk, recalculating on a regular basis to ensure that he is up to date with possible vulnerabilities, and ready with mitigations.

Patch frequently, but carefully

Santa absolutely cannot afford for his systems to go down, particularly around his most busy period.  He has established processes to ensure that the concerns of security are balanced with the needs of the business[5].  He knows that sometimes, business continuity must take priority, and that on other occasions, the impact of a security breach would be so major that patches just have to be applied.  He tells people what he wants, and listens to their views, taking them into account where he can. In other words, he embraces open management, delegating decisions, where possible, to the sets of people who are best positioned to make the call, and only intervenes when asked for an executive decision, or when exceptions arise.  Santa is a very enlightened manager.

Embrace diversity

One of the useful benefits of running a global operation is that Santa values diversity.  Old or young (at heart), male, female or gender-neutral, neuro-typical or neuro-diverse, of whatever culture, sexuality, race, ability, creed or nose-colour, Santa takes into account his stakeholders and their views on what might go wrong.  What a fantastic set of viewpoints Santa has available to him.  And, for an Aging White Guy, he’s surprisingly hip to the opportunities for security practices that a wide and diverse set of opinions and experiences can bring[6].


Here’s my advice.  Be like Santa, and adopt at least some of his security practices yourself.  You’ll have a much better opportunity of getting onto his good side, and that’s going to go down well not just with Santa, but also your employer, who is just certain to give you a nice bonus, right?  And if not, well, it’s not too late to write that letter directly to Santa himself.

1 – if you have a problem with this statement, then either you need to find another blog, or you’re reading this in the far future, where all our climate problems have been solved. I hope.

2 – or you dwell in one of those cultures where Santa visits quite early in December.

3 – a high-flying goose in the face can do terrible damage to a fast-moving reindeer, and if the sleigh were to crash, what then…?

4 – not me!

5 – Santa doesn’t refer to it as a “business”, but he’s happy for us to call it that so that we can model our own experience on his.  He’s nice like that.

6 – though Santa would never use the phrase “hip to the opportunities”.  He’s way too cool for that.

How not to make a cup of tea

This is an emotive topic.

A few weeks ago, I wrote an article entitled “My 7 rules for remote-work sanity“. This was wildly successful, caused at least one email storm on our company servers, and caused a number of readers to ask me to tackle the question of how to make a cup of tea. Because that isn’t contentious at all.

I’ve resisted that, partly because this is (supposed to be) mainly a security blog, and partly because it would be too easy. Instead, I’ve written this article, which is full of advice and guidance about how not to make a cup of tea or, more accurately, how to make a bad cup of tea. This isn’t hugely related to security either, but as I’ve been writing it, it’s reminded me of how strong the idea of “anti-patterns” is, particularly in security. Sometimes it’s hard to explain to people how they should apply security controls to system, and it’s easier to explain what not to do, so that people can learn from that. This is my (very tenuous) link to security in this article. I hope it (and the rest of the article) serve you well.

I am British, but I travel quite frequently to the United States and to Canada. During my travels, I have been privileged to witness many, many attempts to make tea which have been catastrophic failures. This article is an attempt to celebrate these failures so that people, like me, who have learned over many years how to make tea properly, can celebrate the multitude of incorrect ways in which tea can be ruined.

This is an emotive topic. There are shades of opinion across many issues (upon some of which we will touch during this article), across class lines, geographical lines and even moral lines (I’m thinking here in particular of the question of whether to use cow’s milk – an ethical point for vegans). And, so you understand that I’m not overstating the divides that can occur over this important skill, I’d point out that an entire war was started solely over the belief of a certain group of people who believed that the correct way to make tea was to dump an entire shipment of leaves into a salt-water harbour[1] in a small settlement named after a town in Lincolnshire[2].

Without further ado, let us launch into our set of instructions for how not to make tea (by which I mean “hot black tea” in this context), but with a brief (yet important) digression.

De minimis

There are certain activities associated with the making of tea which I am going to declare “de minimis” – in other words, of minimal importance to the aim of creating a decent cup of tea. These may be areas of conflict within the tea drinking community, but I would argue that the majority of Real Tea Drinkers[tm] would accept that a cup of tea would not be ruined by following any of the options for any of the practices noted below. As this article aims to provide a beginner’s guide to how not to make tea, I contend that your choice of any of the options below will not (at least on its own) cause you to be making not-Tea.

  • Milk, not milk or lemon: I drink my tea with milk. Some drink it without, and some with lemon. Tea can be tea in any of these states.
  • Sugar or not sugar: I used to drink my tea with sugar, but now do not. Tea can be tea with or without sugar.
  • Cup or mug: I prefer a mug for most tea drinking opportunities, but a cup (with saucer) can make a nice change.
  • Bag or loose leaf: we’re getting into contentious territory here. I have recently moved to a strong preference for loose leaf, partly because it tends to be higher quality than bags, but if bags are what you’ve got, then you can make a decent cup of tea with them.
  • In the pot or in the mug: if you’re using loose leaf tea, then it’s in the pot. If it’s in a mug, then it’s a bag. You can, however, make tea in a pot with a bag.
  • Milk first or afterwards: there’s evidence to suggest that putting the milk in first means that it won’t scald, but I’m with George Orwell[3] on this: if you put the tea in first, you can add milk slowly to ensure the perfect strength.
  • Warming the pot: you only need to warm the pot if you’re using bone china. End of.

You might think that I’ve just covered all the important issues of contention above, and that there’s not much point in continuing with this article, but please remember: this article is not aimed at those who wish to make an acceptable cup of tea, but to those who do not wish to make the same. Those who wish to make a cup of non-tea will not be swayed by the points above, and neither should they be. If you belong in this group: whether (for example) a person of North American descent looking to cement your inability to make a cup of tea, or (again, for example) a person of British descent looking for guidance in how to be accepted into North American society by creating a representative cup of non-tea, then, dear reader, please read on.


Tea (actual)

The easiest way to fail to make a cup of tea is to choose something which isn’t tea. I’m going to admit to a strong preference to black tea here, and this article is based on how to make a cup of black tea, but I admit to the existence of various other tea types (yellow, white, green, oolong). All of them, however, come from the tea plant, Camellia sinensis. If it doesn’t, then it isn’t tea. Retailers and manufacturers can label it “herbal tea”[4]. Anything which doesn’t come from from the tea plant is an infusion or a tisane.

To be clear, I absolutely include Rooibos or “Red Bush” tea. I tried this once, under the mistaken belief that it was actual tea. The experience did not end well. I’m sure there’s a place for it, but not in my mug (or cup), and it’s not tea. I mean: really.

There are some teas which are made from the tea plant, and have flavourings added. I’m thinking in particular of Earl Grey tea, which has oil of bergamot added to it. I’m not a fan, but that’s partly due to a very bad experience one morning after the imbibing of a significant amount of beverages which definitely weren’t ever pretending to be tea, the results of which also lead to my not drinking gin and tonic anymore[5].

To clarify, then:

  • tea: yes, tea.
  • Earl Grey: yes, tea.
  • rooibos: not tea.
  • fruit tea: not tea.
  • lemon tea: not tea.
  • rhubarb and orange tea: not tea
  • raspberry and old sticks tea: not tea.
  • vanilla tea: not tea.
  • etc., etc.

The very easiest way not to make tea, then, is to choose something which isn’t derived directly from the Camellia sinensis plant. If you’re looking for more adventurous or expert ways not to make tea, however, carry on.

Use non-boiling water

Beyond the obvious “not actually using tea” covered above, the easiest way to fail to make a cup of tea is to use water which is not sufficiently hot. And by “sufficiently hot”, I mean “has just come off the boil”. There’s actual science[6] showing that lots of the important tea-making processes cannot take place at temperatures below 90°C (194°F). To be sure that you’re going to make a cup of bad tea, just be sure not to go with boiling water.

I’ve recently visited a number of establishments in the USA where they offered to make tea with water designed for coffee-making at temperatures of 175°F and 183°F. That’s 79.4°C and 83.9°C. A member of staff at one of these establishments explained that it would be “dangerous” to use water at a higher temperature. I kid you not. They knew that they didn’t need to aim for just off the boil: well under 99°C should do nicely for something almost but not quite like a cup of tea. A warning: many (but not all) outlets of Peet’s Coffee do provide water which is hot enough (often 211-212°F) , if you ask them. You are in significant danger of getting a proper cup of tea if you’re not very careful. This, in my experience, is entirely unique for a coffee chain anywhere in the USA.

Many US hotels will offer to make you a cup of tea in the morning, if you ask nicely enough and sound (passive-aggressively) British enough. You might think that you would be guaranteed a proper cup, but worry not: they will almost certainly use really bad tea, the water will be insufficiently hot and they will definitely not bother to pour it directly over the tea-bag anyway. Hotels are great places to find a really bad cup of tea in the USA.

As a minor corollary of this, another way to fail to make a cup of tea is to boil the water at altitude (e.g. up a mountain) or in an airplane. Because air pressure is reduced in both cases, the boiling point of water is reduced, and so you’re not likely to be able to get the water hot enough, so that’s another great option.

Boil the water incorrectly

What: you didn’t know that you could boil water incorrectly? Oh, but you can. Proper tea is made from water boiled once in a kettle, because if you boil it more than once, something happens: you’ve removed oxygen that was originally dissolved in the water, and this turns out to make it taste bad.

Use the wrong type(s) of milk

The easy way out is to use 2% (semi-skimmed) or 4% (whole fat) cow’s milk, but you don’t want to do that: that’ll give you proper tea. In order not to make tea properly, try UHT milk, almond milk, soy milk or similar. I haven’t tried ewe’s or goat’s milk, but I’m sure it’s easy to mess up a good cup of tea with those.

Condensed milk is an interesting option. I’ve had this in India – where I think they add it instead of sugar – and, well, it didn’t taste like tea to me.

Let it go cold

I’m not even talking about so called “iced tea” here. I’m just talking about tea which has been brewed, then poured, then left to go cold. Yuck.

Brew for too long

Quite apart from the fact that it may go cold, it’s possible to make tea just too strong. There’s a range that most people will accept as proper tea, but you can leave most tea too long, and it will be too strong when you pour it. How long that is will depend partly on preference, and partly on the type of tea you’re using. If you want to ensure you make a bad cup of tea, tune these carefully.

Don’t brew for long enough

Again, it’s easy to get this wrong. Some types of tea brew very quickly, and you’re in danger, for these types, of pouring a decent cup despite your best interests. Use this technique with care, and preferably in conjunction with others of the approaches listed.

Use a little strainer

It is possible to make a decent cuppa with one of those little strainers into which you place your tea leaves, but it’s difficult. The problem seems to be that in order to make a properly strong cup of tea, you’re going to need to put quite a lot of tea leaves into the strainer. This means that the water won’t be able to interact with most of them, as they’ll be stuffed in, and not able to circulate properly. You can try swishing it around a bit, but by the time you’ve got to this, the water will probably be too cold (see above).


Microwave your water. This is wrong on so many levels (do a search online).

Use bad tea

Mainly, I think, because most US citizens have no idea how to make a cup of tea properly, they are willing to accept the stuff that passes for “tea bags” in the US as actual tea. There are exceptions, but the standard fare that you’ll find on supermarket shelves isn’t anything like actual tea, so it’s very simple to make a bad cup even if you’ve done everything else right.

My preferred cup of tea

After all of the above, you may be wondering what my preferred cup of tea looks like. Here’s a brief algorithm, which I’m happy to open source:

  1. freshly drawn water in the kettle
  2. kettle boiled
  3. a teaspoon of tea into a small pot (how heaped depends on the type), current favourites include:
  4. pour the boiling water into pot (I tend to use pots with built-in strainers)
  5. allow to brew (how long depends on the type of tea)
  6. pour from the pot into a large mug (not too large, or the tea will get too cold to drink before you get to the bottom)
  7. add semi-skimmed (2%) milk (not UHT)
  8. drink as soon as its cooled enough not to blister the inside of the mouth
  9. leave the bottom few millimetres to avoid ingesting any leaves which may have made their way into the mug.

So there you have it. That’s how I make a cup of tea.

1 – yes, that’s how to spell it.

2 – I’m assuming this was the sole reason. I’m a little hazy on the details, but it all seems to have turned out OK for both sides.

3 – who, given that he wrote both the books Animal Farm and 1984, knew a thing or two about how not to do things.

4 – yes, there’s an “h”, yes it’s aspirated. “‘erbal?” Not unless dropping aitches is part of your general dialect and accent, in which case, fine.

5 – I still drink gin, only not with tonic. It’s the tonic water that I’ve managed to convince my taste buds was the cause of the resulting … problem.

6 – Really, look!

16 ways in which security folks are(n’t) like puppies

Following the phenomenal[1] success of my ground-breaking[2] article 16 ways in which users are(n’t) like kittens, I’ve decided to follow up with a yet more inciteful[3] article on security folks. I’m using the word “folks” to encompass all of the different types of security people who “normal”[4] people think of “those annoying people who are always going on about that security stuff, and always say ‘no’ when we want to do anything interesting, important, urgent or business-critical”. I think you’ll agree that “folks” is a more accessible shorthand term, and now that I’ve made it clear who we’re talking about, we can move away from that awkwardness to the important[5] issue at hand.

As with my previous article on cats, I’d like my readers to pretend that this is a carefully researched article, and not one that I hastily threw together at short notice because I got up a bit late today.

Note 1: in an attempt to make security folks seem a little bit useful and positive, I’ve sorted the answers so that the ones where security folks turn out actually to share some properties with puppies appear at the end. But I know that I’m not really fooling anyone.

Note 2: the picture (credit: Miriam Bursell) at the top of this article is of my lovely basset hound Sherlock, who’s well past being a puppy. But any excuse to post a picture of him is fair game in my book. Or on my blog.

Research findings

Hastily compiled table

Property Security folks Puppies
Completely understand and share your priorities
No No
Everybody likes them
No Yes
Generally fun to be around No Yes
Generally lovable No Yes
Feel just like a member of the family No Yes
Always seem very happy to see you No Yes
Are exactly who you want to see at the end of a long day No Yes
Get in the way a lot when you’re in a hurry
Yes Yes
Make a lot of noise about things you don’t care about Yes Yes
Don’t seem to do much most of the time
Yes Yes
Constantly need cleaning up after
Yes Yes
Forget what you told them just 10 minutes ago Yes Yes
Seem to spend much of their waking hours eating or drinking Yes Yes
Wake you up at night to deal with imaginary attackers Yes Yes
Can turn bitey and aggressive for no obvious reason
Yes Yes
Have tickly tummies Yes[6] Yes

1 – relatively.

2 – no, you’re right: this is just hype.

3 – this is almost impossible to prove, given quite how uninciteful the previous one was.

4 – i.e., non-security.

5 – well, let’s pretend.

6 – well, I know I do.

6 reasons to go (and not go) to a security conference

…the parties – don’t forget the many, many parties.

I’m at the annual RSA Conference this week in San Francisco. There are a number of RSA Conferences around the world, but this is the big one. There will be thousands – in fact, tens of thousands – of people attending, probably hundreds of exhibitors, and I’ve just pored through the many, many sessions available just on the first day to identify the ones I want to attend.

RSA – as other conferences – comes under fire for just being an opportunity for security vendors to pitch their wares, rather than a conference about security, and there is some truth in that. To be fair, though, they’re the ones sponsoring the show[1], and making it all work, and many of them will pay, as part of that sponsorship, to have sessions where they will pitch their products. And people attend these talks[3] – it’s really not my thing (and I’ve written about it in the past), but I’ve noticed that this year, there are clues in the session title that a particular talk will be sponsor-led, so more opportunities to avoid them if you’re not interested.

There are, however, lots and lots of talks that aren’t just product pitches. These range from the uber-technical academic cryptography talks[4] to “how we managed to deal with this problem in my company”, “what we’ve learned over 5/10/20/100 years of X” and innumerable talks on DevSecOps, Agile, security for/within/outside/above the Cloud by vendors, airlines, software companies, banks, insurance companies and very few start-ups.

I’ve been a little harsh in the previous paragraph, but I reckon there’s actually going to be something (probably many things – choosing between the multiple sessions scheduled at the same time can be challenging) for everybody. I always get a little annoyed that there’s not enough talk about systems security and complexity, but there actually seems to be a little more of that this year – though I’m willing to bet that the expo hall will be somewhat light on the same, with the usual SIEM, email security, storage, authentication, authorisation, logging and network tools being very much in evidence, alongside big consultancies and some a few small companies, not-for-profits and educational institutions.

6 reasons to attend a security conference

What, then, are some good reasons to attend a security conference? Here are my top 6 – in no particular order:

  1. sessions which will teach you something new – or help you see something from somebody else’s perspective;
  2. catching up with colleagues who you don’t otherwise get to see;
  3. the hallway track – meeting people between sessions, at meals or parties, in the lift[5] at your hotel and striking up a conversation;
  4. being able to check out vendors at their booths in the expo, and get demos of their products;
  5. swag and give-aways[6];
  6. the parties.

6 reasons not to attend a security conference

It only seems fair to provide the flipside, so here we go, this time in a particular order:

  1. sessions which won’t teach you anything new – or which show you something from the perspective of a speaker who you suspect has never worked in the real world, or is a complete idiot;
  2. catching up with colleagues who you’ve managed to avoid for the past 12 months, but who realise that you’re going to be at the show, and who you can’t politely put off meeting;
  3. the hallway track – being accosted by people between sessions who’ve seen your badge, have heard of your company, and have a particular feature that they really, really want you to implement, despite the fact that a) you’re not on the product team and b) they only buy one licence/subscription from your company a year;
  4. being subjected to demos by vendors at their booths in the expo because you didn’t move away fast enough, despite the fact that you only moved close to find out what their swag was;
  5. swag and give-aways – too many t-shirts (never enough in womens’ sizes, I’m told), and realisation that you’ve got so many that you’re going to have to check in extra hold luggage on the way back home to get it back to your children, who will have no interest in it, anyway;
  6. the parties – in particular the standard of the wine (poor) and beer (either so hoppy it makes your teeth retract into your gums or so gassy that you swell up to the size of a beachball) – and how you feel after them.

So, make your choices, and decide whether to go or not. I’ll keep an eye out for you in the lift at the hotel…

1 – and the parties – don’t forget the many, many parties[2].

2 – painkillers and heartburn medication are must-pack items for any serious attendees.

3 – not always on purpose – there are times when you’ll see an early exodus of people as they realise what they turned up to.

4 – all credit if you manage to get past the first slide of mathematics.

5 – I don’t care if it’s in the US, I’m not calling it an escalator.

6 – I reckon that the standard of swag at a conference is directly proportional to the strength of the market in that the sector 6 months ago – there’s a delay in marketing budgets.

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.

The Twelve Days of Work-Life Balance

12 tips for working at home over the holidays

Disclaimer: the author refuses to take any blame for any resulting disciplinary or legal action taken against readers who follow any of the suggestions in this article.

There’s a good chance that things slow down for the holiday season at your organisation or company[1], and as they do, there’s a corresponding[2] chance that you may end up not going into the office for some of the upcoming days.  Some workplaces expect you to turn up to work in the office unless you’re officially on holiday, while others allow or encourage workers to be based at home and perform their duties there for all or some of the period.  It’s those people who will be spending time at home who are targeted by this article.

Working from home is an opportunity to bunk off and is a complete wheeze a privilege and responsibility to be taken seriously.  There are, however, some important techniques that you should take on board to ensure not only that you continue to be productive but, even more important, that you continue to be seen to be productive.  I’ve split my tips up into helpful headings for your ease of use.

Video calls

Tip 1 (for those who shave): you don’t need to.  Yes, the resolution on webcams has increased significantly, but who’s going to care if it looks like you’ve just rolled out of bed?  The fact that you’ve even bothered shows your commitment to the meeting you’re attending.

Tip 2 (for those who wear make-up): far be it from me to dictate whether you wear make-up or not to meetings.  But if you choose to, there’s no need to refresh last night’s make-up in the morning.  If you’ve staggered home late, you may not have got round to removing your party lipstick and mascara, and it may even have smudged or run a bit: don’t worry.  It’ll look “festive” in the morning, and will encourage a relaxed atmosphere at the meeting.

Tip 3 (for coffee drinkers): you may need an extra cup of coffee in the afternoon, to get you through the day.  Who’s going to know if you add a shot to it?  It’ll keep you warm, and possibly upright.  My wife swears by Baileys.  Or Irish Whiskey.  Or gin.  Pretty much anything, in fact.

Tip 4 (for non-coffee drinkers): cocktails are a no-no for video conferences, unless approved by management (sorry).  However, there are a number of other options to explore.  A Long Island Iced Tea looks like, well, an iced tea.  Whisky (or whiskey) can look like normal tea, and my personal favourite, cherry brandy, looks like a child’s fruit cordial that you didn’t dilute sufficiently.  And tastes fairly similar.

Tip 5 (for clothes wearers): few organisations (of which I’m aware, anyway) have adopted a non-clothing policy for video-calls.  Clothes are required.  My favourite option is to wear a festive jumper, but this is only fun if it has woven-in flashing lights which can distract your fellow participants[3].  Coordinating the periodicity of the flashing with colleagues gets you bonus points.

Tip 6 (also for clothes wearers): wear something on your bottom half.  I know you think you may not be getting up during the call, but when a small child vomits in the background, the postal worker arrives at the door, or you just need another cup of coffee or “beverage” (see tips 3 & 4) to get you through the next two hours, you’ll be grateful for this advice.

Teleconferences (non-video)

Tip 7: use a chat channel to have a side conversation with your peers. You can have hilarious discussions about the intellectual capacity and likely parentage of your management, or even better, play a game of meeting bingo.

Tip 8: the mute button is for cowards.  Yes, wind can be a problem after an over-indulgence at the pub, club or party the night before, and microphones can be quite sensitive these days, but who’s to know it’s you[4]?


Tip 9: the best time to respond to an email is when you receive it, right?  This will show everybody how devoted you are to your job.  So if it arrives after you’ve already partaken of a brew or two down the pub, or sampled the herbal opportunities recently decriminalised in your state in your bedroom, then replying immediately will almost certainly be considered responsible and professional.  And auto-correct will almost certainly act in your favour: after all, your boss really is a complete duck, yes?

Tip 10: pepper your emails with poor festive puns[5].  It’s just what you do.


Tip 11: you may have agreed to “work” over this period as an excuse to avoid spending too much time with the family[6], but there’s always the chance that they will barge into your office, throw up in the hall (see tip 6), or just fall asleep on your keyboard[7].  Invest in a lock on your office door, or work somewhere out of range[8].  Your work is important, and you must guard against unwanted interruptions, such as being awoken from an important doze.


Tip 12: it’s your responsibility, when working from home, to ensure that you maintain your productivity.  But breaks are important.  There’s a tricky balance here between protecting your time from the family (you don’t want them to notice that you’re not online 100% of the time) and taking sensible amounts of breaks.  Assuming that you’ve taken my advice about locking your office door, then placing an XBox or similar gaming console on your desk next to your work computer is a great way of allowing yourself some downtime without risking the wrath of your family (assuming careful monitor placement and controller handling).

Tip 12a (extra tip!): if you’re not careful, too much time hidden away from the family will get you in trouble.  My piece of advice here is to offer to help.  But on your own terms.  Rushing out of your office[9], looking harried and then announcing “I’ve got ten minutes until my next call, and I’m feeling guilty: is there anything I can do?” can gain you useful credit without the risk of your having to do anything too taxing.


You can maintain a productive and professional workplace at home if called to do so by your organisation.  It is your responsibility to balance the needs of work with your needs and, of course, the needs of your family.

Have a Merry Christmas (or other festival) and a Happy New Year (whenever it falls for you)!

1 – this is generally a Judaeo-Christian set of holidays, but I hope that this article is relevant to most holidays: religious, national, regional or secular.

2 – and possibly correlateable, though check out one of my favourite XKCD comics: https://xkcd.com/552/.

3 – owners of luxuriant beards or heads of hair may prefer to weave flashing fairy lights into their hair for a similar effect.

4 – except for the small matter of the little indicator against each participant’s name which shows who’s “talking”.

5 – “Your presents is requested.”  “But wait—there’s myrrh.” You get the idea.

6 – “Sorry, darling, I know your parents are here, but a really critical bug came in, and I’m the only one who can look at it in time…”

7 – mainly a problem for owners of cats or teenagers.

8 – try searching for “Where’s a pub near me that’s open now?”.

9 – don’t forget to lock it again, in case a child notices and purloins that gaming console.

10 – in the Southern Hemisphere, at least.  Sorry: see [5].


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.

Happy 4th of July – from Europe

If I were going to launch a cyberattack on the US, I would do it on the 4th July.

There’s a piece of received wisdom from the years of the Cold War that if the Russians[1] had ever really wanted to start a land war in Europe, they would have done it on Christmas Day, when all of the US soldiers in Germany were partying and therefore unprepared for an attack.  I’m not sure if this is actually fair – I’m sure that US commanders had considered this eventuality – but it makes for a good story.

If I were going to launch a cyberattack on the US, I would do it on the 4thof  July.  Now, to be entirely clear, I have no intentions of performing any type of attack – cyber or not – on our great ally across the Pond[2]: not today (which is actually the 3rd July) or tomorrow.  Quite apart from anything else, I’m employed by[5] a US company, and I also need to travel to the US on business quite frequently.  I’d prefer to be able to continue both these activities without undue attention from the relevant security services.

The point, however, is that the 4th of July would be a good time to do it.  How do I know this?  I know it because it’s one of my favourite holidays.  This may sound strange to those of you who follow or regularly read this blog, who will know – from my spelling, grammar and occasional snide humour[6] – that I’m a Brit, live in the UK, and am proud of my Britishness.  The 4th of July is widely held, by residents and citizens of the USA, to be a US holiday, and, specifically, one where they get to cock a snook at the British[7].  But I know, and my European colleagues know – in fact, I suspect that the rest of the world outside the US knows – that if you are employed by, are partners of, or otherwise do business with the US, then the 4th of July is a holiday for you as well.

It’s the day when you don’t get emails.  Or phone calls.  There are no meetings arranged.

It’s the day when you can get some work done.  Sounds a bit odd for a holiday, but that’s what most of us do.

Now, I’m sure that, like the US military in the Cold War, some planning has taken place, and there is a phalanx of poor, benighted sysadmins ready to ssh into servers around the US in order to deal with any attacks that come in and battle with the unseen invaders.  But I wonder if there are enough of them, and I wonder whether the senior sysadmins, the really experienced ones who are most likely to be able to repulse the enemy, haven’t ensured that it’s their junior colleagues who are the ones on duty so that they – the senior ones – can get down to some serious barbecuing and craft beer consumption[8].  And I wonder what the chances are of getting hold of the CISO or CTO when urgent action is required.

I may be being harsh here: maybe everything’s completely under control across all organisations throughout the USA, and nobody will take an extra day or two of holiday this week.  In fact, I suspect that many sensible global organisations – even those based in the US – have ensured that they’ve readied Canadian, Latin American, Asian or European colleagues to deal with any urgent issues that come up.  I really, really hope so.  For now, though, I’m going to keep my head down and hope that the servers I need to get all that work done on my favourite holiday stay up and responsive.

Oh, and roll on Thanksgiving.

1 – I suppose it should really be “the Soviet Union”, but it was also “the Russians”: go figure.

2 – the Atlantic ocean – this is British litotes[3].

3 – which is, like, a million times better than hyperbole[4].

4 – look them up.

5 – saying “I work for” sets such a dangerous precendent, don’t you think?

6 – litotes again.

7 – the probably don’t cock a snook, actually, as that’s quite a British phrase.

8 – I’m assuming UNIX or Linux sysadmins: therefore most likely bearded, and most likely craft beer drinkers.  Your stereotypes may vary.


Security at conferences – a semi-humorous view

Next week, I’ll be attending and speaking at Red Hat Summit in San Francisco.   I’ve written before about how annoying I find it when people don’t stay on topic at conferences, so rest assured that I won’t be making any product pitches: in fact, I plan to hold a vote during the session to determine some of what I talk about, so if you’re attending, too, please come along and help choose.

In anticipation of the event and associated travel, I thought I’d compile a semi-humorous list of tangentially-security-related advice for anyone planning on attending a conference or associated exhibition/expo in the near future.  I’ve been to way too many in my *cough* 20+ years in the industry: here are some tips for conferences.

Oh, and before we start, if you’re at DEFCON, be more paranoid even than this, or even more paranoid than you think you need to be.  At most conferences, you don’t need to worry too much that someone might be spoofing the cell towers, for instance.  At DEFCON, well…

  • wifi – if you’re going to use wifi, use official hotel / conferences access points, rather than random ones which have names like “useme” or “theNSA” or “notRussianSpies” or “dataCollectionforFB”.  And even when you’re using the official ones, don’t trust them: use HTTPS and/or a VPN.  You know this: don’t forget it just because you’re at a conference.
  • what happens in Vegas makes it back to your boss – maybe not your family members, but definitely your boss.  I’ve been to conferences in Vegas.  I’ve seen … things.
  • bluetooth – your safest option?  Turn off bluetooth, particularly on your phone.  If you must leave it on (so that you can use your watch/headphones/other cool accessories), then never accept unsolicited pairing requests.
  • conversations – do you want to be talked to by random strangers?  Some people prefer to be left alone, and a growing number of conferences allow you to put a sticker onto your badge which will tell other attendees whether or not you’re happy to be addressed.   These are typically:
    • green: I’m so gregarious I’m probably not in a technical job, and am more likely to be in marketing
    • red: please, please don’t talk to me, or even glance in my direction
    • yellow: I’m in two minds about it.  If you’re going to offer me a job, make a pass at me or we’ve already met, then it’s probably OK.
    • (I have a serious question about this, by the way: what if you’re red/green colourblind and either very shy or very gregarious?  This approach seems seriously flawed.)
  • don’t leave your phone on the booth table – unless you want it to be stolen.  I’m always astonished by this, but see it all the time.
  • decide whether you’re going to give out your email address – for most shows, you give your email address out whenever you have your badge scanned.  So you need to decide whether you want to be scanned.  There are lots of other ways of giving out your email address, of course, and one is to drop your business card into those little glass bowls in the hopes of winning a prize.  That you never win[1].
  • getting pwned by booth staff – how do you get enough information about a company to decide whether actually to visit the booth and maybe talk to the staff?  Well, you’re going to need to approach it, and you may have to slow down in order to read the marketing messages.  There’s a set of rules that you need to be aware of around this behaviour, and it’s that staff on the booth can engage you in conversation if they catch you doing any of the following:
    • stepping on the coloured carpet tiles around the booth;
    • making eye contact[2];
    • dawdling[3].
  • languages – if you’re attending a conference in a foreign environment, you may wish to include a sticker on your badge to let people know in which languages you’re conversant.  US English is standard, but other favourites include Java, Python, UML and, in some circles, COBOL[4].
  • beware too much swag – I’ve only had to do it once, but I did once buy an extra case to take swag back in.  This was foolish.  There really is such a thing as too much swag, and as we all know, once you have more than three vaguely humorous techie t-shirts, you can rotate them through the washing[6] until you get the chance to visit another conference and pick up some new ones.
  • useful phrases – not even vaguely security-related, and this really relates to the languages point, but I was told a long time ago by a wise person[7] that you only need five phrases in the language of any foreign country[8] that you’re visiting:
    • yes;
    • no;
    • please;
    • thank you;
    • I’ll have five beers, and my colleague’s paying.

1 – except once, when I won a large drone which was really, really difficult to get home from the US and then turned out to be almost impossible to control in the windy part of the UK in which I live.

2 – do you know nothing?

3 – this is the tricky one: I reckon anything over half a second is fair game, but exact timing is culturally-specific, based on my observations.

4 – if you find yourself at a conference where lots of people are going around with stickers saying “COBOL” on them, or, more dangerous still, wearing t-shirts with “I know COBOL, and I’m not ashamed”, you have two options: a) run, fast; b) stick around, learn to converse with the natives and end up with a job for life making shockingly large amounts of money maintaining legacy banking code[5].

5 – but getting invited to a vanishingly small number of dinner parties or other social engagements.

6 – if you don’t wash your t-shirts, you’re not going to need to worry to much about [5] becoming a problem for you.

7 – I can’t remember when, exactly, or by whom, in fact, but they must have been pretty wise: it’s good advice.

8 – I include the North of England in the “foreign countries” category.