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.
Alice, Eve and Bob - a security blog 