Security at Red Hat Summit

And a little teaser on my session…

I don’t often talk about my job specifically, but I’m very proud to be employed by Red Hat, working as Chief Security Architect, a role based in the Office of the CTO[1], and sometimes it’s the right time to talk about job-related stuff.  Next week is our annual Summit, and this year it’s in Boston[2], starting on Tuesday, 2019-05-07.  If you’re coming – great!  If you’re thinking about coming – please do!  And if you’re not able to come, then rest assured that many of the sessions will be recorded so that you can watch them in the future[3].

There is going to be a lot going on at Summit this year: including, I suspect, some big announcements[4].  There will also be lots of hands-on sessions, which are always extremely popular, and a number of excellent sessions and other activities around Diversity and Inclusion, a topic about which I’m extremely passionate.  As always, though, security is a big topic at Summit, and there are 50 security topic sessions listed in the agenda[5] (here’s the session catalog[ue]):

  • 26 breakout sessions
  • 11 instructor-led labs
  • 7 mini-sessions
  • 4 birds-of-a-feather sessions (“BOFs”)
  • 2 theatre sessions

These include sessions by partners and customers, as well as by Red Hatters themselves.

Many of my colleagues in OCTO will be presenting sessions in the “Emerging Technology” track, as will I.  My session is entitled “Security: Emerging technologies and open source”, and on Tuesday, at 1545 (3.45pm) I’ll be co-presenting it with my (non-OCTO) colleague Nathaniel McCallum.  The abstract is this:

What are some of the key emerging security technologies, and what impact will they have on the open source world? And what impact could open source have on them?

In this session, we’ll look at a handful of up-and-coming hardware and software technologies—from trusted execution environments to multi-party computation—and discuss the strategic impact we can expect them to have on our world. While individual technologies will be discussed (and you can expect a sneak peek demo of one of them), the focus of this session is not a deep-dive on any of them, but rather an architectural, strategic, and business view.

I’m trying to ensure that when I talk about all of these cool technologies, I talk about why open source is important to them, and/or why they are important to open source.

Here’s the particularly exciting bit, though: what’s not clear from the abstract – as it’s a late addition – is that Nathaniel plans to present a demo.  I can’t go into details at the moment, partly because we’re keeping it as a surprise, and partly because exactly what is demoed will depend on what Nathaniel’s frantic coding manages to achieve before Tuesday afternoon.  It’s one of the early results from a project we’re running, and I can tell you: a) that it involves TEEs (trusted execution environments); and b) that it’s really exciting.  I’m hoping that we can soon make more of a noise about it, and our Summit session is the start of that.

I’m hoping that the description above will be enough to convince you to attend Summit, but in case it isn’t, bear in mind the following:

  1. there will be keynotes from Jim Whitehurst (Red Hat CEO), Satya Nadella (Microsoft CEO) and Ginni Rometty (IBM CEO)
  2. the Summit party will feature Neon Trees[6].

There are lots of other great reasons to come as well, and if you do, please track me down and say hello: it’s always great to meet readers of this blog.  See you in Boston next week!


1 – “OCTO” – which, I guess, makes me one of the Octonauts.

2 – the picture at the top of this article is of Fenway Park, a place in Boston where they play baseball, which is like cricket, only quicker.  And you’re allowed to chuck the ball.

3 – in case, for any crazy reason, you’d like to see me speaking at last year’s Summit, here’s a link to the session: Getting strategic about security

4 – this should not be interpreted as a “forward-looking statement”, as I’m not privy to any particular definite decisions as to any such announcements.  Sorry – legal stuff…

5 – I’m indebted to my colleague Lucy Kerner, who’s organised and documented much of the security pieces, and from whom I have stolen copied gratefully reused much of the information in this article.

6 – I’ve only just clocked this, and my elder daughter is going to be very, very jealous when she gets back from school to discover this information.

Trust you? I can’t trust myself.

Cognitive biases are everywhere.

William Gibson’s book Virtual Light includes a bar which goes by the name of “Cognitive Dissidents”.  I noticed this last night when I was reading to bed, and it seemed apposite, because I wanted to write about cognitive bias, and the fact that I’d noticed it so strikingly was, I realised, an example of exactly that: in this case, The Frequency Illusion, or The Baader-Meinhof Effect.  Cognitive biases are everywhere, and there are far, far more of them than you might expect.

The problem is that we think of ourselves as rational beings, and it’s quite clear from decades – in some cases, centuries – of research that we’re anything but.  We’re very likely to tell ourselves that we’re rational, and it’s such a common fallacy that The Illusion of Validity (another cognitive bias) will help us believe it.  Cognitive biases are, according to Wikipedia, “systematic patterns of deviation from norm or rationality in judgment” or put maybe more simply, “our brains managing to think things which seem sensible, but aren’t.”[1]

The Wikipedia entry above gives lots of examples of cognitive bias – lots and lots of examples – and I’m far from being an expert in the field.  The more I think about risk and how we consider risk, however, the more I’m convinced that we – security professionals and those with whom we work – need to have a better understanding of our own cognitive biases and those of the people around us.  We like to believe that we make decisions and recommendations rationally, but it’s clear from the study of cognitive bias that:

  1. we generally don’t; and
  2. that even if we do, we shouldn’t expect those to whom we present them to consider them entirely rationally.

I should be clear, before we continue, that there are opportunities for abuse here.  There are techniques beloved of advertisers and the media to manipulate our thinking to their ends which we could use to our advantage and to try to manipulate others.  One example is the The Framing Effect.  If you want your management not to fund a new anti-virus product because you have other ideas for the earmarked funding, you might say:

  • “Our current product is 80% effective!”

Whereas if you do want them to fund it, you might say:

  • “Our current product is 20% ineffective!”

People react in different ways, depending on how the same information is presented, and the way the two statements above are framed aims to manipulate your listeners to the outcome you want.  So, don’t do this, and more important, look for vendors[2] who are doing this, and call them out on it.  Here, then, are a three of the more obvious cognitive biases that you may come across:

  • Irrational escalation or Sunk cost fallacy – this is the tendency for people to keep throwing money or resources at a project, vendor or product when it’s clear that it’s no longer worth it, with the rationale that to stop spending money (or resources) now would waste what has already been spent – when it’s actually already gone.  This often comes over as misplaced pride, or people just not wanting to let go of a pet project because they’ve become attached to it, but it’s really dangerous for security, because if something clearly isn’t effective, we should be throwing it out, not sending good money after bad.
  • Normalcy bias – this is the refusal to address a risk because it’s never happened before, and is an interesting one in security, for the simple reason that so many products and vendors are trying to make us do exactly that.  What needs to happen here is that a good risk analysis needs to be performed, and then measures put in place to deal with those which are actually high priority, not those which may not happen, or which don’t seem likely at first glance.
  • Observer-expectancy effect – this is when people who are looking for particular results find it, because they have (consciously or unconsciously) misused the data.  This is common in situations such as those where there is a belief that a particular attack or threat is likely, and the data available (log files, for instance) are used in a way which confirms this expectation, rather than analysed and presented in ways which are more neutral.

I intend to address more specific cognitive biases in future articles, tying them even more closely to security concerns – if you have any particular examples or war stories, I’d love to hear them.


1 – my words

2 – or, I suppose, underhand colleagues…

AI, blockchain and security – huh? Ahh!

There’s a place for the security community to be more involved AI and blockchain.

Next week, I’m flying to the US on Tuesday, heading back on Thursday evening, arriving back in Heathrow on Friday morning, and heading (hopefully after a shower) to Cyber Security & Cloud Expo Global to present a session and then, later in the afternoon, to participate in a panel.  One of the reasons that I’m bothering to post this here is that I have a feeling that I’m going to be quite tired by the end of Friday, and it’s probably a good idea to get at least a few thoughts in order for the panel session up front[1].  This is particularly the case as there’s some holiday happening between now and then, and if I’m lucky, I’ll be able to forget about everything work-related in the meantime.

The panel has an interesting title.  It’s “How artificial intelligence and blockchain are the battlegrounds for the next security wars“.  You could say that this is buzzwordy attempt to shoehorn security into a session about two unrelated topics, but the more I think about it, the more I’m glad that the organisers have put this together.  It seems to me that although AI and blockchain are huge topics, have their own conference circuits[2] and garner huge amounts of interest from the press, there’s a danger that people whose main job and professional focus is security won’t be the most engaged in this debate.  To turn that around a bit, what I mean is that although there are people within the AI and blockchain communities considering security, I think that there’s a place for people within the security community to be more involved in considering AI and blockchain.

AI and security

“What?” you may say.  “Have you not noticed all of the AI-enabled products being sold by vendors in the security community?”

To which I reply, “pfft.”

It would be rude[3] to suggest that none of those security products have any “Artificial Intelligence” actually anywhere near them.  However, it seems to me (and I’m not alone) that most of those products are actually employing much more basic algorithms which are more accurately portrayed as “Machine Learning”.  And that’s if we’re being generous.

More importantly, however, I think that what’s really important to discuss here is security in a world where AI (or, OK, ML) is the key element of a product or service, or in a world where AI/ML is a defining feature of how we live at least part of our world.  In other words, what’s the impact of security when we have self-driving cars, AI-led hiring practices and fewer medical professionals performing examinations and diagnoses?  What does “the next battleground” mean in this context?  Are we fighting to keep these systems from overstepping their mark, or fighting to stop malicious actors from compromising or suborning them to their ends?  I don’t know, and that’s part of why I’m looking forward to my involvement on the panel.

Blockchain and security

Blockchain is the other piece, of course, and there are lots of areas for us to consider here, too.  Three that spring to my mind are:

Whether you believe that blockchain(s) is(are) going to take over the world or not, it’s a vastly compelling topic, and I think it’s important for it to be discussed outside its “hype bubble” in the context of a security conference.

Conclusion

While I’m disappointed that I’m not going to be able to see some of the other interesting folks speaking at different times of the conference, I’m rather looking forward to the day that I will be there.  I’m also somewhat relieved to have been able to use this article to consider some of the points that I suspect – and hope! – will be brought up in the panel.  As always, I welcome comments and thoughts around areas that I might not have considered (or just missed out).  And last, I’d be very happy to meet you at the conference if you’re attending.


1 – I’ve already created the slides for the talk, I’m pleased to say.

2 – my, do they have their own conference circuits…

3 – not to mention possibly actionable.  And possibly even incorrect.

3 tips to avoid security distracti… Look: squirrel!

Executive fashions change – and not just whether shoulder-pads are “in”.

There are many security issues to worry about as an organisation or business[1].  Let’s list some of them:

  • insider threats
  • employee incompetence
  • hacktivists
  • unpatched systems
  • patched systems that you didn’t test properly
  • zero-day attacks
  • state actor attacks
  • code quality
  • test quality
  • operations quality
  • underlogging
  • overlogging
  • employee-owned devices
  • malware
  • advanced persistent threats
  • data leakage
  • official wifi points
  • unofficial wifi points
  • approved external access to internal systems via VPN
  • unapproved external access to internal systems via VPN
  • unapproved external access to internal systems via backdoors
  • junior employees not following IT-mandated rules
  • executives not following IT-mandated rules

I could go on: it’s very, very easy to find lots of things that should concern us.  And it’s particularly confusing if you just go around finding lots of unconnected things which are entirely unrelated to each other and aren’t even of the same type[2]. I mean: why list “code quality” in the same list as “executives not following IT-mandated rules”?  How are you supposed to address issues which are so diverse?

And here, of course, is the problem: this is what organisations and businesses do have to address.  All of these issues may present real risks to the functioning (or at least continued profitability) of the organisations[3].  What are you supposed to do?  How are you supposed to keep track of all these things?

The first answer that I want to give is “don’t get distracted”, but that’s actually the final piece of advice, because it doesn’t really work unless you’ve already done some work up front.  So what are my actual answers?

1 – Perform risk analysis

You’re never going to be able to give your entire attention to everything, all the time: that’s not how life works.  Nor are you likely to have sufficient resources to be happy that everything has been made as secure as you would like[4].  So where do you focus your attention and apply those precious, scarce resources?  The answer is that you need to consider what poses the most risk to your organisation.  The classic way to do this is to use the following formula:

Risk = Likelihood x Impact

This looks really simple, but sadly it’s not, and there are entire books and companies dedicated to the topic.  Impact may be to reputation, to physical infrastructure, system up-time, employee morale, or one of hundreds of other items.  The difficulty of assessing the likelihood may range from simple (“the failure rate on this component is once every 20 years, and we have 500 of them”[5]) to extremely difficult (“what’s the likelihood of our CFO clicking on a phishing attack?”[6]).  Once it’s complete, however, for all the various parts of the business you can think of – and get other people from different departments in to help, as they’ll think of different risks, I can 100% guarantee – then you have an idea of what needs the most attention.  (For now: because you need to repeat this exercise of a regular basis, considering changes to risk, your business and the threats themselves.)

2 – Identify and apply measures

You have a list of risks.  What to do?  Well, a group of people – and this is important, as one person won’t have a good enough view of everything – needs to sit[7] down and work out what measures to put in place to try to reduce or at least mitigate the various risks.  The amount of resources that the organisation should be willing to apply to this will vary from risk to risk, and should generally be proportional to the risk being addressed, but won’t always be of the same kind.  This is another reason why having different people involved is important.  For example, one risk that you might be able to mitigate by spending a £50,000 (that’s about the same amount of US dollars) on a software solution might be equally well addressed by a physical barrier and a sign for a few hundred pounds.  On the other hand, the business may decide that some risks should not be mitigated against directly, but rather insured against.  Other may require training regimes and investment in t-shirts.

Once you’ve identified what measures are appropriate, and how much they are going to cost, somebody’s going to need to find money to apply them.  Again, it may be that they are not all mitigated: it may just be too expensive.  But the person who makes that decision should be someone senior – someone senior enough to take the flak should the risk come home to roost.

Then you apply your measures, and, wherever possible, you automate them and their reporting.  If something is triggered, or logged, you then know:

  1. that you need to pay attention, and maybe apply some more measures;
  2. that the measure was at least partially effective;
  3. that you should report to the business how good a job you – and all those involved – have done.

3 – Don’t get distracted

My final point is where I’ve been trying to go with this article all along: don’t get distracted.  Distractions come in many flavours, but here are three of the most dangerous.

  1. A measure was triggered, and you start paying all of your attention to that measure, or the system(s) that it’s defending.  If you do this, you will miss all of the other attacks that are going on.  In fact, here’s your opportunity to look more broadly and work out whether there are risks that you’d not considered, and attacks that are coming in right now, masked by the one you have noticed.
  2. You assume that the most expensive measures are the ones that require the most attention, and ignore the others.  Remember: the amount of resources you should be ready to apply to each risk should be proportional to the risk, but the amount actually applied may not be.  Check that the barrier you installed still works and that the sign is still legible – and if not, then consider whether you need to spend that £50,000 on software after all.  Also remember that just because a risk is small, that doesn’t mean that it’s zero, or that the impact won’t be high if it does happen.
  3. Executive fashions change – and not just whether shoulder-pads are “in”, or the key to the boardroom bathroom is now electronic, but a realisation that executives (like everybody else) are bombarded with information.  The latest concern that your C-levels read about in the business section, or hears about from their buddies on the golf course[9] may require consideration, but you need to ensure that it’s considered in exactly the same way as all of the other risks that you addressed in the first step.  You need to be firm about this – both with the executive(s), but also yourself, because although I identified this as an executive risk, the same goes for the rest of us. Humans are generally better at keeping their focus on the new, shiny thing in front of them, rather than the familiar and the mundane.

Conclusion

You can’t know everything, and you probably won’t be able to cover everything, either, but having a good understanding of risk – and maintaining your focus in the event of distractions – means that at least you’ll be covering and managing what you can know, and can be ready to address new ones as they arrive.


1 – let’s be honest: there are lots if you’re a private individual, too, but that’s for another day.

2- I did this on purpose, annoying as it may be to some readers. Stick with it.

3 – not to mention the continued employment of those tasked with stopping these issues.

4 – note that I didn’t write “everything has been made secure”: there is no “secure”.

5 – and, to be picky, this isn’t as simple as it looks either: does that likelihood increase or decrease over time, for instance?

6 – did I say “extremely difficult”?  I meant to say…

7 – you can try standing, but you’re going to get tired: this is not a short process.

8 – now that, ladles and gentlespoons, is a nicely mixed metaphor, though I did stick with an aerial theme.

9 – this is a gross generalisation, I know: not all executives play golf.  Some of them play squash/racketball instead.

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.

What is a password for, anyway?

Which of my children should I use as my password?

This may look like it’s going to be one of those really short articles, because we all know what a password is for, right?  Well, I’m not sure we do.  Or, more accurately, I’m not sure that the answer is always the same, or has always been the same, so I think it’s worth spending some time looking at what passwords are used for, particularly as I’ve just seen (another) set of articles espousing the view that either a) passwords are dead; or b) multi-factor authentication is dead, and passwords are here to stay.

History

Passwords (or, as Wikipedia points out, “watchwords”) have been used in military contexts for centuries.  If you wish to pass the guard, you need to give them a word or phrase that matches what they’re expecting (“Who goes there?” “Friend” doesn’t really cut it).  Sometimes there’s a challenge and response, which allows both parties to have some level of assurance that they’re on the same side.  Whether one party is involved, or two, this is an authentication process – one side is verifying the identity of another.

Actually, it’s not quite that simple.  One side is verifying that the other party is a member of a group of people who have a particular set of knowledge (the password) in order to authorise them access to a particular area (that is being guarded).  Anyone without the password is assumed not to be in that group, and will be denied access (and may also be subject to other measures).

Let’s step forward to the first computer recorded as having had a password.  This was the Compatible Time-Sharing System (CTSS) at MIT around 1961, and its name gives you a clue as to the reason it needed a password: different people could use the computer at the same time, so it was necessary to provide a way to identify them and the jobs they were running.

Here, the reason for having a password seems a little different to our first use case.  Authentication is there not to deny or allow access to a physical area – or even a virtual area – but to allow one party to discriminate[1] between different parties.

Getting more modern

I have no knowledge of how military uses of passwords developed, other than to note that by 1983, use of passwords on military systems was well-known enough to make it into the film[2] Wargames.  Here, the use of a password is much closer to our earlier example: though the area is virtual, the idea is to restrict access to it based on a verification of the party logging on.  There are two differences, however:

  1. it is not so much access to the area that is important, and more access to the processes available within the area;
  2. each user has a different password, it seems: the ability to guess the correct password gives instant access to a particular account.

Now, it’s not clear whether the particular account is hardwired to the telephone number that’s called in the film, but there are clearly different accounts for different users.  This is what you’d expect for a system where you have different users with different types of access.

It’s worth noting that there’s no sign that the school computer accessed in Wargames has multiple users: it seems that logging in at all gives you access to a single account – which is why auditing the system to spot unauthorised usage is, well, problematic.  The school system is also more about access to data and the ability to change it, rather than specific processes[3 – SPOILER ALERT].

Things start getting interesting

In the first few decades of computing, most systems were arguably mainly occupied with creating or manipulating data associated with the organisations that owned it[4].  That could be sales data, stock data, logistics data, design data, or personnel data, for instance.  It then also started to be intellectual property data such as legal documents, patent applications and the texts of books.  Passwords allowed the owners of the systems to decide who should have access to that data, and the processes to make changes.  And then something new happened.

People started getting their own computers.  You could do your own accounts on them, write your own books.  As long at they weren’t connected to any sort of network, the only passwords you really needed were to stop your family from accessing and changing data that wasn’t theirs.  What got really interesting, though, was when those computers started getting connected to networks, which meant that they could talk to other computers, and other computers could talk to them.  People started getting involved in chatrooms and shared spaces, and putting their views and opinions on them.

It turns out (and this should be of little surprise to regular readers of this blog) that not all people are good people.  Some of them are bad.  Some of them, given the chance, would pretend to be other people, and misrepresent their views.  Passwords were needed to allow you to protect your identity in a particular area, as well as to decide who was allowed into that area in the first place.  This is new: this is about protection of the party associated with the password, rather than the party whose resources are being used.

Our data now

What does the phrase above, “protect your identity” really mean, though?  What is your identity?  It’s data that you’ve created, and, increasingly, data that’s been created about you, and is associated with that data.  That may be tax accounts data that you’ve generated for your own use, but it may equally well be your bank balance – and the ability to pay and receive money from and to an account.  It may be your exercise data, your general health data, your fertility cycle, the assignments you’ve written for your university course, your novel or pictures of your family.  Whereas passwords used to be to protect data associated with an organisation, they’re now increasingly to protect data associated with us, and that’s  a big change.  We don’t always have control over that data – GDPR and similar legal instruments are attempts to help with that problem – but each password that is leaked gives away a bit of our identity.  Sometimes being able to change that data is what is valuable – think of a bank account – sometimes just having access to it – think of your criminal record[5] – is enough, but control over that access is important to us, and not just the organisations that control us with which we interact.

This is part of the reason that ideas such as self-sovereign identity (where you get to decide who sees what of the data associated with you) are of interest to many people, of course, but they are likely to use passwords, too (at least as one method of authentication).  Neither am I arguing that passwords are a bad thing – they’re easy to understand, and people know how to use them – but I think it’s important for us to realise that they’re not performing the task they were originally intended to fulfil – or even the task they were first used for in a computing context.  There’s a responsibility on the security community to educate people about why they need to be in control of their passwords (or other authentication mechanisms), rather than relying on those who provide services to us to care about them.  In the end, it’s our data, and we’re the ones who need to care.

Now, which of my children should I use as my password: Joshua or Rache…?[6]


1 – that is “tell the difference”, rather than make prejudice-based choices.

2 – “movie”.

3 – such as, say, the ability to start a global thermonuclear war.

4 – or “them”, if you prefer your data plural.

5 – sorry – obviously nobody who reads this blog has ever run a red light.

6 – spot the popular culture references!

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.