On conversation and the benefits of boasting

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

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

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

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

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

 


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

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

3 – does anybody use this term anymore?

4 – Liberal Arts/Social Sciences.

5 – but included:

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

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

 

My brush with GDPR

I ended up reporting a possible breach of data. My data

Since the first appearance of GDPR[1], I’ve strenuously avoided any direct interaction with it if at all possible.  In particular, I’ve been careful to ensure that nobody is under any illusion that my role involves any responsibility for our company’s implementation of GDPR.  In this I have been largely successful.  I say largely, because the people who send spam don’t seem to have noticed[2]: I suspect that anybody with the word “security” in their title has had a similar experience.

Of course, I have a decent idea what GDPR is supposed to be about: making sure that data that organisations hold about people is only used as it should be, is kept up to date, and that people can find out what exactly what information relating to them exactly is held[3].

This week, I got more involved GDPR than I’d expected: I ended up reporting a possible breach of data.  My data.  As it happens, my experience with the process was pretty good: so good, in fact, that I think it’s worth giving it as an example.

Breach!

A bit of scene-setting.  I live in the UK, which is (curently[4]) in the EU, and which means that, like pretty much all companies and organisations here, it is subject to the GDPR.  Last week, I had occasion to email a department within local government about an issue around services in my area.  Their website had suggested that they’d get back to me within 21 days or so, so I was slightly (and pleasantly) surprised when they replied within 5.

The email started so well: the title referred to the village in which I live.

It went downhill from there.  “Dear Mr Benedict[5]”, it ran.  I should be clear that I had used my actual name (which is not Benedict) for the purposes of this enquiry, so this was something of a surprise.  “Oh, well,” I thought to myself, “they’ve failed to mail merge the name field properly.” I read on.  “Here is the information you have requested about Ambridge…[5][6]”.  I do not live in Ambridge.  So far, this was just annoying: clearly the department had responded to the wrong query.  But it got worse.  “In particular regards to your residence, Willow Farm, Ambridge…[5]”

The department had sent me information which allowed me to identify Mr Benedict and his place of residence.  They had also failed to send me the information that I had requested.  What worried me more was that this might well not be an isolated event.  There was every chance that my name and address details had been sent to somebody else, and even that there was a cascade effect of private details being sent to email address after email address.  I mentioned this in annoyance to my wife – and she was the one to point out that it was a likely breach of GDPR.  “You should report it,” she said.

So I went to the local government office website and had a quick look around it.  Nothing obvious for reporting GDPR breaches.  I phoned the main number and got through to enquiries.  “I’d like to report a possible data breach, please,” I said.  “Could you put me through to whoever covers GDPR?”

To be honest, this was where I thought it would all go wrong.  It didn’t.  The person on the enquiries desk asked for more information.  I explained what department it was, about the email, and the fact that somebody else’s details had been exposed to me, I strongly suspected in breach of GDPR.

“Let me just see if I can find someone in our data team,” she said, and put me on hold.

I don’t know if you’ve ever been put on hold by someone in a local government office, but it’s rarely an event that should be greeted with rejoicing.  I prepared myself for a long wait, and was surprised when I was put through to someone fairly quickly.

The man to whom I spoke knew what he was doing.  In fact, he did an excellent job.  He took my details, he took details of the possible breach, he reassured me that this would be investigated.  He was polite, and seemed keen to get to the bottom of the affair.  He also immediately grasped what the problem was, and agreed that it needed to be investigated.  I’m not sure whether I was the first person ever to call up and so this was an adrenaline-fuelled roller coaster ride into uncharted territory[8] for him, or whether this was a routine conversation in the office, but he pitched his questions and responses at exactly the right level.  I offered to forward the relevant email to him so that he had the data himself.  He accepted.  The last point was the one that impressed me the most.  “Could you please delete the email from your system?” he asked.  This was absolutely the right request.  I agreed and did so.

And how slowly do the wheels of local government grind?  How long would it take me to get a response to my query?

I received a response the next day, from the department concerned.  They assured me that this was a one-off problem, that my personal data had not been compromised, and that there had not been a widespread breach, as I had feared.  They even sent me the information I had initially requested.

My conclusions from this?  They’re two-fold:

  1. From an individual’s point of view: yes, it is worth reporting breaches.  Action can, and should be taken.  If you don’t get a good response, you may need to escalate, but you have rights, and organisations have responsibilities: exercise those rights, and hold the organisations to account.  You may be pleasantly surprised by the outcome, as I was.
  2. From an organisation’s point of view: make sure that people within your organisation know what to do if someone contacts them about a data breach, whether it’s covered by statutory regulations (like GDPR) or not.  This should include whoever it is answers your main enquiry line or receives messages to generic company email accounts, and not just your IT or legal departments.  Educate everybody in the basics, and make sure that those tasked with dealing with issues are as well-trained and ready to respond as the people I encountered.

1 – General Data Protection Regulation, wouldn’t it be more fun if it were something like “Good Dogs Pee Regularly?”

2 – though GDPR does seem to have reduced the amount of spam, I think.

3 – if you’re looking for more information, I did write an article about this on Opensource.com earlier this year: Being open about data privacy.

4 – don’t start me.

5 – I’ve changed this information, for reasons which I hope are obvious.

6 – “dum-di-dum-di-dum-di-dum, dum-di-dum-di-da-da”[7]

7 – if you get this, then you either live in the UK (and probably listen to Radio 4), or you’re a serious Anglophile.

8 – hopefully not so uncharted for the designers and builders of the metaphorical roller coaster.

Top 5 resolutions for security folks – 2018

Yesterday, I wrote some jokey resolutions for 2018 – today, as it’s a Tuesday, my regular day for posts, I decided to come up with some real ones.

1 – Embrace the open

I’m proud to have been using Linux[1] and other open source software for around twenty years now.  Since joining Red Hat in 2016, and particularly since I started writing for Opensource.com, I’ve become more aware of other areas of open-ness out there, from open data to open organisations.  There are still people out there who are convinced that open source is less secure than proprietary software.  You’ll be unsurprised to discover that I disagree.  I encourage everyone to explore how embracing the open can benefit them and their organisations.

2 – Talk about risk

I’m convinced that we talk too much about security for security’s sake, and not about risk, which is what most “normal people” think about.  There’s education needed here as well: of us, and of others.  If we don’t understand the organisations we’re part of, and how they work, we’re not going to be able to discuss risk sensibly.  In the other direction, we need to be able to talk about security a bit, in order to explain how it will mitigate risk, so we need to learn how to do this in a way that informs our colleagues, rather than alienating them.

3 – Think about systems

I don’t believe that we[2] talk enough about systems.  We spend a lot of our time thinking about functionality and features, or how “our bit” works, but not enough about how all the bits fit together. I don’t often link out to external sites or documents, but I’m going to make an exception for NIST special publication 800-160 “Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”, and I particularly encourage you to read Appendix E “Roles, responsibilities and skills: the characteristics and expectations of a systems security engineer”.  I reckon this is an excellent description of the core skills and expertise required for anyone looking to make a career in IT security.

4 – Examine the point of conferences

I go to a fair number of conferences, both as an attendee and as a speaker – and also do my share of submission grading.  I’ve written before about how annoyed I get (and I think others get) by product pitches at conferences.  There are many reasons to attend the conferences, but I think it’s important for organisers, speakers and attendees to consider what’s most important to them.  For myself, I’m going to try to ensure that what I speak about is what I think other people will be interested in, and not just what I’m focussed on.  I’d also highlight the importance of the “hallway track”: having conversations with other attendees which aren’t necessarily directly related to the specific papers or talks. We should try to consider what conferences we need to attend, and which ones to allow to fall by the wayside.

5 – Read outside the IT security discipline

We all need downtime.  One way to get that is to read – on an e-reader, online, on your phone, magazines, newspapers or good old-fashioned books.  Rather than just pick up something directly related to work, choose something which is at least a bit off the beaten track.  Whether it’s an article on a topic to do with your organisation’s business,  a non-security part of IT[3], something on current affairs, or a book on a completely unrelated topic[4], taking the time to gain a different perspective on the world is always[5] worth it.

What have I missed?

I had lots of candidates for this list, and I’m sure that I’ve missed something out that you think should be in there.  That’s what comments are for, so please share your thoughts.


1 GNU Linux.

2 the mythical IT community

3 – I know, it’s not going to be as sexy as security, but go with it.  At least once.

4 – I’m currently going through a big espionage fiction phase.  Which is neither here nor there, but hey.

5 – well, maybe almost always.

Getting started in IT security – an in/outsider’s view

… a basic grounding in cryptography is vital …

I am, by many measures, almost uniquely badly qualified* to talk about IT security, given that my degree is in English Literature and Theology (I did two years of each, finishing with the latter), and the only other formal university qualification I have is an MBA.  Neither of these seem to be great starting points for a career in IT security.  Along the way, admittedly, I did pick up a CISSP qualification and took an excellent SANS course on Linux and UNIX security, but that’s pretty much it.  I should also point out in my defence that I was always pretty much a geek at school***, learning Pascal and Assembly to optimise my Mandelbrot set generator**** and spending countless hours trying to create simple stickman animations.

The rest of it was learnt on the job, at seminars, meetings, from colleagues or from books.  What prompted me to write this particular post was a post over at IT Security guru, 9 out of 10 IT Security Pros Surveyed Favour Experience over Qualifications – FireMon, a brief analysis of a survey disclosed on Firemon’s site.

This cheered me, I have to say, given my background, but it also occurred to me that I sometimes get asked what advice I have for people who are interested in getting involved in IT Security.  I’m wary providing a one-size-fits-all answer, but there’s one action, and three books, that I tend to suggest, so I thought I’d share them here, in case they’re useful to anyone.

An action:

  • get involved in an Open Source project, preferably related to security.  Honestly, this is partly because I’m passionate about Open Source, but also because it’s something that I know I and others look for on an CV*****.  You don’t even need to be writing code, necessarily: there’s a huge need for documentation, testing, UI design, evangelism****** and the rest, but it’s great exposure, and can give you a great taster of what’s going on.  You can even choose a non-security project, but considering getting involved in security-related work for that project.

Three books******* to give you a taste of the field, and a broad grounding:

  1. Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson. I learned more about security systems from this book than any other. I think it gives a very good overview of the field from a point of view that makes sense to me.  There’s deep technical detail in here, but you don’t need to understand all of it on first reading in order to get a lot of benefit.
  2. Practical Cryptography, by Bruce Schneier. Schneier has been in the field of security for a long time (many of his books are worth reading, as is his monthly email, CRYPTO-GRAM), and this book is a follow-up to his classic “Applied Cryptography”. In Practical Cryptography, he admitted that security was more than just mathematics, and that the human element is also important. This book goes into quite a lot of technical depth, but again, you don’t have to follow all of it to benefit.
  3. Cryptonomicon, by Neal Stephenson. This is a (very long!) work of fiction, but it has a lot of security background and history in it, and also gives a good view into the mindset of how many security people think – or used to think!  I love it, and re-read it every few years.

I’m aware that the second and third are unashamedly crypto-related (though there’s a lot more general security in Cryptonomicon than the title suggests), and I make no apology for that.  I think that a basic grounding in cryptography is vital for anyone wishing to make a serious career in IT Security.  You don’t need to understand the mathematics, but you do need to understand, if not how to use crypto correctly, then at least the impact of using it incorrectly********.

So, that’s my lot.  If anyone has other suggestions, feel free to post them in comments.  I have some thoughts on some more advanced books around architecture which I may share at some point, but I wanted to keep it pretty simple for now.


*we could almost stop the sentence here**, to be honest.

**or maybe the entire article.

***by which I mean “before university”.  When Americans ask Brits “are you at school?”, we get upset if we’ve already started university (do we really look that young?).

****the Pascal didn’t help, because BBC BASIC was so fast already, and floating point was so difficult in Assembly that I frankly gave up.

*****”Curriculum Vitae”.  If you’re from North America, think “Resumé”, but it’s Latin, not French.

******I know quite a lot about evangelism, given my degree in Theology, but that’s a story for another time.

*******All of these should be available from a decent library.  If your university/college/town/city library doesn’t have these, I’d lobby for them.  You should also be able to find them online.  Please consume them legally: authors deserve to be paid for their work.

********Spoiler: it’s bad.  Very bad.

Ignorance as a virtue: being proud to say “I don’t know”

“I am the wisest man alive, for I know one thing, and that is that I know nothing.” Socrates

In order to be considered an expert in any field, you have to spend a lot of time learning things.  In fact, I’d argue that one of the distinguishing traits of someone who is – or could become – an expert is their willingness and enthusiasm to learn, and keep learning.  The ability to communicate that knowledge is another of those traits: you can’t really be an expert if you have no way to communicate that knowledge.  Though that doesn’t mean that you need to be a great speaker, or even a great writer: by “communicate” I’m thinking of something much broader.  In the field of security and IT, that communication may be by architecture diagram, by code writing, by firewall rule instantiation, or by GUI, database or kernel module design, to name just a few examples.  These are all ways by which expertise can be communicated, instantiated or realised: the key is that the knowledge that has been gained is not contained, but can be externalised.

There’s another trait that, for me, betrays a true expert, and that’s the ability to say “I don’t know”.  And it’s difficult.  We enjoy and cultivate our expert status and other’s recognition of it: it’s part of our career progression, and it hits the “esteem” block in Maslow’s Hierarchy of Needs[1].  We like people asking our opinion, and we like being able to enlighten them: we take pride in our expertise, and why wouldn’t we?  We’ve earned it, after all, with all that hard graft and studying.  What’s more, we’ve all seen what happens when people get asked a question to which they don’t know the answer to something – they can become flustered, embarrassed, and they can be labelled stupid.*  Why would we want that for ourselves?

The problem, and very particularly in the security field, is that you’ll always get found out if you fake it.  In my experience, you’ll go into a customer meeting, for instance, and there’s either the sandal-wearing grey-beard, the recently-graduated genius or just the subject matter expert who’s been there for fifteen years and knows this specific topic better than … well, possibly anybody else on the planet, but certainly better than you.  They may not be there in the first meeting, but you can bet your bottom dollar*** that they’ll be in the second meeting, or the third – and you’ll get busted.  And when that happens, everything else you’ve said is called into question.  That may not seem fair, but that’s the way it goes.  Your credibility is dented, possibly irreparably.

The alternative to faking it is to accept that awkward question and simply to say, “I don’t know”.  You may want to give the question a moment’s thought – there have been times when I’ve plunged into an response and then stopped myself to admit that I just can’t give a full or knowledgeable answer, and when I could have saved myself bother by just pausing and considering it for a few seconds.  And you may want to follow up that initial acknowledgement of ignorance by saying that you know somebody else who does (if that happens to be true), or “I can find out” (if you think you can) or even “do you have any experts who might be able to help with that?”

This may not impress people who think you should know, but they’re generally either asking because they don’t (in which case they need a real answer) or because they’re trying to trip you up (in which case you don’t want to oblige them).  But it will impress those who are experts, because they know that nobody knows everything, and it’s much better to have that level of self-awareness than to dig yourself an enormous hole from which it’s difficult to recover.  But they’ll also understand, from your follow-up, that you want to find out: you want to learn.  And that is how one expert recognises another.


* it’s always annoyed me when people mock Donald Rumsfeld for pointing out that there are “unknown unknowns”: it’s probably one of the wisest soundbites in recent history**, for my money.

** and for an equivalently wise soundbite in ancient history, how about “I am the wisest man alive, for I know one thing, and that is that I know nothing”, by Socrates
*** other currencies and systems of exchange are available