risk – Alice, Eve and Bob – a security blog

Organisational suppleness

Growing the ability to react to the unexpected is a valuable skill.

“In preparing for battle I have always found that plans are useless but planning is indispensable.”
Dwight D. Eisenhower

Much of this blog is about security – cybersecurity – in one way or another, but on occasion I do try to take a broader view. Cybersecurity is often modelled or described in military terms, talking about “fighting battles”, “wars of attrition” and “arms races” with “attackers”. These can be useful metaphors (and it’s why I started this article with a quote from a general), but there is a broader set of responsibilities that many of us in the sector need to consider, which is the continued (and hopefully healthy) functioning of our businesses and organisations. In particular, I like to talk about risk and how it relates not just to security, but to how businesses work and plan. One theme that I’ve visited before is that known or planned degradation of a service is often significantly better than failure, or even planned closure (see Service degradation: actually a good thing). My argument is that there are many occasions where keeping a service or business function running, albeit at reduced capacity, or with reductions in known capabilities, allows for better continuity than just stopping it.

Keeping a service running requires work. You can’t just hope that everything is installed and will run as you expect: what happens when your administrator is ill, your fibre-optic cable gets severed by a back hoe, or a DDoS attack is directed at you? You need to plan and practice what to do in these situations. What I’d like to explore in this article goes somewhat beyond the expectation of that planning in three directions. Let’s call them scenario coverage, muscle memory and organisational suppleness.

Scenario coverage

The first, and most obvious of the three directions, is about understanding eventualities. The more scenarios that we model and practice, the more we reduce our risk, simply because we have reduced the number of unknown eventualities in the probability space. There is a actually a side benefit to modelling lost of scenarios, which is that the more situations you consider, the more will come to mind. Every situation involves sets of choices or probabilities – “after the door closes, will it lock or not?” or “if the coolant fails, will the system turn off or burst into flames?” – and the more scenarios you consider, the more questions will arise. This can be daunting – and it’s almost impossible to consider every eventuality – but the more options are covered, the better your opportunities to mitigate the various risks they present.

Muscle memory

Muscle memory is what comes with training and practice. Assuming that you are including your teams in the scenario planning

And I’m assuming here that the planning isn’t solely a paper exercise. Theoretical planning, while useful, only goes so far, for a couple of important reasons:

systems will always fails in unexpected ways
people will do unexpected things.

What the first of these means is that however much you assume that your back-up generator will kick in if there’s a power outage, until you test it, you can’t be sure that it will. The second of these relates to the fact that however much you tell people what to do, when it actually comes to the doing of it, they’re unlikely to as you expect. This is likely to be even worse if there’s been no training, and you’re just assuming that person X will know how to operate a fire extinguisher, or that team Y will, of course, exit the building in an orderly manner via exit Z (rather than find fourteen different exits, or not even leave the building at all).

For both of these reasons, getting people together to work through possible scenarios, and then, where possible, actually practising what to do, means that you have a higher assurance that when one of the situations you’ve considered does arrive, that they will know what to do, and act as you expect.

Organisational suppleness

While you cannot, as we’ve noted, plan for every eventuality or know exactly how an employee or team will react when things go wrong, there is another benefit to involving a broad group of people in your scenario planning and training. This is that their very involvement gives them practice in dealing with uncertainty, working out how they will react, and giving them experience in how those around them will act. While I may not know exactly what to do if the payroll system goes down an hour before it is due to run, if I have worked with colleagues on scenarios where the sales processing system fails, I’ve got a better chance of making some sensible choices about who to contact, initial steps to take and information to collect than if this is the first time I’ve ever seen anything like it. Likewise, we may not have modelled our response to a physical failure of one of our network links, but our shared experience of practising our response to a DDoS attack means that we have an idea of what to do.

And it is not just having an idea of what to do that is important, but also having gathered and practised the cognitive skills associated with investigating failures, collating data, sharing information and working with others to ameliorate the situation which allows a team or an organisation to respond better to new, maybe unexpected situations. We can think of this as suppleness, as it means that rather than just failing, or cracking, an organisation can react as a tree does to strong winds, or a gymnast does to a new exercise. Growing the ability to react to the unexpected is a valuable skill for an organisation, and knowing that it is supple allows its leaders to plan with more certainty and mitigate more risk.

3 types of application security

There are security applications and there are applications which have security.

I’m indebted to my friend and colleague, Matt Smith, for putting me on the road to this article: he came up with a couple of the underlying principles that led me to what you see below. Thanks, Matt: we’ll have a beer (and maybe some very expensive wine) – one day.

There are security applications and there are applications which have security: specifically, security features or functionality. I’m not saying that there’s not a cross-over, and you’d hope that security applications have security features, but they’re used for different things. I’m going to use open source examples here (though many of them may have commercial implementations), so let’s say: OpenVPN is a security product, whose reason for existence is to provide a security solution, where as Kubernetes is not a security application, though it does include security features. That gives us two types of application security, but I want to add another distinction. It may sound a little arbitrary, at least from the point of the person designing or implementing the application, but I think it’s really important for those who are consuming – that is, buying, deploying or otherwise using an application. Here are the three:

security application – an application whose main purpose is to solve a security-related problem;
compliance-centric security – security within an application which aims to meet certain defined security requirements;
risk-centric security – security within an application which aims to allow management or mitigation of particular risk.

Types 2 and 3 are subsets of the non-security application (though security applications may well include them!), and may not seem that different, until you look at them from an application user’s point of view. Those differences are what I want to concentrate on in this article.

Compliance-centric

You need a webserver – what do you buy (or deploy)? Well, let’s assume that you work in a regulated industry, or even just that you’ve spent a decent amount of time working on your risk profile, and you decide that you need a webserver which supports TLS 1.3 encryption. This is basically a “tick box” (or “check box” for North American readers): when you consider different products, any which do not meet this requirement are not acceptable options for your needs. They must be compliant – not necessarily to a regulatory regime, but to your specific requirements. There may also be more complex requirements such as FIPS compliance, which can be tested and certified by a third party – this is a good example of a compliance feature which has moved from a regulatory requirement in certain industries and sectors to a well-regarded standard which is accepted in others.

I think of compliance-centric security features as “no” features. If you don’t have them, the response to a sales call is “no”.

Risk-centric

You’re still trying to decide which webserver to buy, and you’ve come down to a few options, all of which meet your compliance requirements: which to choose? Assuming that security is going to be the deciding factor, what security features or functionality do they provide which differentiate them? Well, security is generally about managing risk (I’ve written a lot about this before, see Don’t talk security: talk risk, for example), so you look at features which allow you to manage risks that are relevant to you: this is the list of security-related capabilities which aren’t just compliance. Maybe one product provides HSM integration for cryptographic keys, another One Time Password (OTP) integration, another integrity-protected logging. Each of these allows you to address different types of risk:

HSM integration – protect against compromise of private keys
OTP integration – protect against compromise of user passwords, re-use of user passwords across sites
integrity-protected logging – protect against compromise of logs.

The importance of these features to you will depend on your view of these different risks, and the possible mitigations that you have in place, but they are ways that you can differentiate between the various options. Also, popular risk-centric security features are likely to morph into compliance-centric features as they are commoditised and more products support them: TLS is a good example of this, as is password shadowing in Operating Systems. In a similar way, regulatory regimes (in, for instance, the telecommunications, government, healthcare or banking sectors) help establish minimum risk profiles for applications where customers or consumers of services are rarely in a position to choose their provider based on security capabilities (typically because they’re invisible to them, or the consumers do not have the expertise, or both).

I think of risk-centric security features as “help me” features: if you have them, the response to a sales call is “how will they help me?”.

Why is this important to me?

If you are already a buyer of services, and care about security – you’re a CISO, or part of a procurement department, for instance – you probably consider these differences already. You buy security products to address security problems or meet specific risk profiles (well, assuming they work as advertised…), but you have other applications/products for which you have compliance-related security checks. Other security features are part of how you decide which product to buy.

If you are a developer, architect, product manager or service owner, though, think: what I am providing here? Am I providing a security application, or an application with security features? If the latter, how do I balance where I put my effort? In providing and advertisingcompliance-centric or risk-centric features? In order to get acceptance in multiple markets, I am going to need to address all of their compliance requirements, but that may not leave me enough resources to providing differentiating features against other products (which may be specific to that industry). On the other hand, if I focus too much on differentiation, you may miss important compliance features, and not get in the door at all. If you want to getting to the senior decision makers in a company or organisation and to be seen as a supplier of a key product – one which is not commoditised, but is differentiated from your competitors and really helps organisations manage risk – then you need to thinking about moving to risk-centric security features. But you really, really need to know what compliance-centric features are expected, as otherwise you’re just not going to get in the door.

Trust in Computing and the Cloud

I wrote a book.

I usually write and post articles first thing in the morning, before starting work, but today is different. For a start, I’m officially on holiday (so definitely not planning to write any code for Enarx, oh no), and second, I decided that today would be the day that I should finish my book, if I could.

Towards the end of 2019, I signed a contract with Wiley to write a book (which, to be honest, I’d already started) on trust. There’s lots of literature out there on human trust, organisational trust and how humans trust each other, but despite a growing interest in concepts such as zero trust, precious little on how computer systems establish and manage trust relationships to each other. I decided it was time to write a book on this, and also on how trust works (or maybe doesn’t) in the Cloud. I gave myself a target of 125,000 words, simply by looking at a couple of books at the same sort of level and then doing some simple arithmetic around words per page and number of pages. I found out later that I’d got it a bit wrong, and this will be quite a long book – but it turns out that the book that needed writing (or that I needed to write, which isn’t quite the same thing) was almost exactly this long, as when I finished around 1430 GMT today, I found that I was at 124,939 words. I have been tracking it, but not writing to the target, given that my editor told me that I had some latitude, but I’m quite amused by how close it was.

Anyway, I emailed my editor on completion, who replied (despite being on holiday), and given that I’m 5 months or so ahead of schedule, he seems happy (I think they prefer early to late).

I don’t have many more words in me today, so I’m going to wrap up here, but do encourage you to read articles on this blog labelled with “trust”, several of which are edited excerpts from the book. I promise I’ll keep you informed as I get information about publication dates, etc.

Keep safe and have a Merry Christmas and Happy New Year, or whatever you celebrate.

Timely risk or risky times?

Being aware of “the long game”.

On Friday, 29th November 2019, Jack Merritt and Saskia Jones were killed in a terrorist attack. A number of members of the public (some with with improvised weapons) and of the emergency services acted with great heroism. I wanted to mention the mention the names of the victims and to praise those involved in stopping him before mentioning the name of the attacker: Usman Khan. The victims, the attacker were taking part in an offender rehabilitation conference to help offenders released from prison to reintegrate into society: Khan had been convicted to 16 years in prison for terrorist offences.

There’s an important formula that everyone involved in risk – and given that IT security is all about mitigating risk, that’s anyone involved in security – should know. It’s usually expressed thus:

Risk = likelihood x impact

Sometimes likelihood is sometimes expressed as “probability”, impact as “consequence” or “loss”, and I’ve seen some other variants as well, but the version above is generally sufficient for most purposes.

Using the formula

How should you use the formula? Well, it’s most useful for comparing risks and deciding how to mitigate them. Humans are terrible at calculating risk, and any tools that help them[1] is good. In order to use this formula correctly, you want to compare risks over the same time period. You could say that almost any eventuality may come to pass over the lifetime of the universe, but comparing the risk of losing broadband access to the risk of your lead developer quitting for another company between the Big Bang and the eventual heat death of the universe is probably not going to give you much actionable information.

Let’s look at the two variables that we need to have in order to calculate risk. We’ll start with the impact, because I want to devote most of this article to the other part: likelihood.

Impact is what the damage will be if the risk happens. In a business context, you want to look at the risk of your order system being brought down for a week by malicious attackers. You might calculate that you would lose £15,000 in orders. On top of that, there might be a loss of reputation which you might calculate at £30,000. Fixing the problem might add £10,000. Add these together, and the impact is £55,000.

What’s the likelihood? Well, remember that we need to consider a particular time period. What you choose will depend on what you’re interested in, but a classic use is for budgeting, and so the length of time considered is often a year. “What is the likelihood of my order system being brought down for a week by malicious attackers over the next twelve months?” is the question you want to ask. If you decide that it’s 0.005 (or 0.5%), then your risk is calculated thus:

Risk = 0.005 x 55,000

Risk = 275

The units don’t really matter, because what you want to do is compare risks. If the risk of your order system being brought down through hardware failure is higher (say 500), then you should probably balance the amount of resources you assign to mitigate these risks accordingly.

Time, reputation, trust and risk

What I’m interested in is a set of rather more complicated risks, however: those associated with human behaviour. I’m very interested in trust, and one of the interesting things about trust is how we decide to trust people. One way is by their reputation: if someone keeps behaving well over a long period, then we tend to trust them more – or if badly, then to trust them less[2]. If we trust someone more, our calculation of risk is likely to be strongly based on that trust, as our view of the likelihood of a behaviour at odds with the reputation that person holds will be informed by that.

This makes sense: in the absence of perfect information about humans, their motivations and intentions, our view of risk must be based on something, and reputation is actually a fairly good measure for that. We might say that the likelihood of a customer defaulting on payment terms reduces year by year as we start to think of them as a “trusted customer”. As the likelihood reduces, we may decide to increase the amount we lend to them – and thereby the impact of defaulting – to keep the risk about the same, year on year.

The risk here is what is sometimes called “playing the long game”. Humans sometimes manipulate their reputation, or build up a reputation, in order to perform an action once they have gained trust. Online sellers my make lots of “good” sales in order to get a 5 star rating over time, only to wait and then make a set of “bad” sales, where they don’t ship goods at all, and then just pocket the money. Or, they may make many small sales in order to build up a good reputation, and then use that reputation to make one big sale which they have no intention of fulfilling. Online selling sites are wise to some of these tricks, and have algorithms to try to protect buyers (in fact, the same behaviour can be used by sellers in some cases), but these are not perfect.

I’d like to come back to the London Bridge attack. In this case, it seems likely that the attacker bided his time over many years, behaving well, and raising his “reputation” among those who knew him – the prison staff, parole board, rehabilitation conference organisers, etc. – so that he had the opportunity to perform one major action at odds with that reputation. The heroism of those around him stopped him being as successful as he may have hoped, but still at the cost of two innocent lives and several serious injuries.

There is no easy way to deal with such issues. We need reputation, and we need to allow people to show that they have changed and can be integrated into society, but when we make risk calculations based on reputation in any sphere, we should take care to consider whether actors are playing a long game, and what the possible ramifications would be if they were to act at odds with that reputation.

I noted above that humans are bad at calculating risk, and to follow our example of the non-defaulting customer, one mistake might be to increase the credit we give to that customer beyond the balance of the increase of reputation: actually accepting higher risk than we would have done previously, because we consider them trustworthy. If we do this, we’ve ceased to use the risk formula, and have started to act irrationally. Don’t do that.

1 – OK, then: “us”.

2 – I’m writing this in the lead up to a UK General Election, and it occurs to me that we actually don’t apply this to most of our politicians.

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].

Summary

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.

Are my messages safe? No, but…

“Are any of these messaging services secure?”

Today brought another story about insecurity of a messenger app, and by a brilliant coincidence, I’m listening to E.L.O.’s “Secret Messages” as I start to compose this post. This article isn’t, however, about my closet 70s musical tastes[1], but about the messages you send from your mobile phone, tablet or computer to friends, families and colleagues, and how secure they are.

There are loads of options out there for messaging services, with some of the better-known including WhatsApp, Facebook Messenger, Google Chat, Signal and Telegram. Then there’s good old SMS. First question first: do I use any of these myself? Absolutely. I also indulge in Facebook, LinkedIn and Twitter. Do I trust these services? Let’s get back to this question later.

A more pressing question might be: “are any of these messaging services secure?” It turns out that this is a really simple question to answer: of course they’re not. No service is “secure”: it’s a key principle of IT security that there is no “secure”. This may sound like a glib – and frankly unhelpful – answer, but it’s not supposed to be. Once you accept that there is no perfectly secure system, you’re forced to consider what you are trying to achieve, and what risks you’re willing to take. This is a recurring theme of this blog, so regular readers shouldn’t be surprised.

Most of the popular messaging services can be thought of as consisting of at least seven components. Let’s assume that Alice is sending a message from her phone to Bob’s phone. Here’s what the various components might look like:

Alice’s messenger app
Alice’s phone
Communications channel Alice -> server
Server
Communications channel server -> Bob
Bob’s phone
Bob’s messenger app

Each of these is a possible attack surface: combined, they make up the attack surface for what we can think of as the Alice <-> Bob and messaging system.

Let’s start in the middle, with the server. For Alice and Bob to be happy with the security of the system for their purposes, they must be happy that this server has sufficiently secure to cope with whatever risks they need to address. So, it may be that they trust that the server (which will be run, ultimately, by fallible and possibly subornable humans who also are subject to legal jurisdiction(s)) is not vulnerable. Not vulnerable to whom? Hacktivists? Criminal gangs? Commercial competitors? State actors? Legal warrants from the server’s jurisdiction? Legal warrants from Alice or Bob’s jurisdiction(s)? The likelihood of successful defence against each of these varies, and the risk posed to Alice and Bob by each is also different, and needs to be assessed, even if that assessment is “we can ignore this”.

Each of the other components is subject to similar questions. For the communication channels, we will assume that they’re encrypted, but we have to be sure that the cryptography and cryptographic protocols have been correctly implemented, and that all keys are appropriately protected by all parties. The messaging apps must be up to date, well designed and well implemented. Obviously, if they’re open source, you have a much, much better chance of being sure of the security of both software (never, ever use cryptography or protocols which have not been not open sourced and peer reviewed: just don’t). The phones in which the software is running must also be uncompromised – not to mention protected by Alice and Bob from physical tampering and delivered new to them from the manufacturer with no vulnerabilities[2].

How sure are Alice and Bob of all of the answers to all of these questions? The answer, I would submit, is pretty much always going to be “not completely”. Does this mean that Alice and Bob should not use messaging services? Not necessarily. But it does mean that they should consider what messages they should exchange via any particular messaging service. They might be happy to arrange a surprise birthday party for a colleague, but not to exchange financial details of a business deal. They might be happy to schedule a trip to visit a Non-Governmental Organisation to discuss human rights, but not to talk about specific cases over the messaging service.

This is the view that I take: I consider what information I’m happy to transfer over or store on messaging services and social media platforms. There are occasions where I may happy to pass sensitive data across messaging services, but break the data up between different services (using “different channels” in the relevant parlance): using one service for a username and another for the associated password, for instance. I still need to be careful about shared components: the two phones in the example above might qualify, but I’ve reduced the shared attack surface, and therefore the risk. I’m actually more likely to require that the password is exchanged over a phone call, and if I’m feeling particularly paranoid, I’ll use a different phone to receive that call.

My advice, therefore, is this:

Keep your devices and apps up to date;
Evaluate the security of your various messaging service options;
Consider the types of information that you’ll be transferring and/or storing;
Think about the risks you’re willing to accept;
Select the appropriate option on a case by case basis:
Consider using separate channels where particularly sensitive data can be split for added security.

1 – I’m also partial to 1920’s Jazz and a bit of Bluegrass, as it happens.

2 – yeah, right.

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:

that you need to pay attention, and maybe apply some more measures;
that the measure was at least partially effective;
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.

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.
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.
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.

Don’t talk security: talk risk

We rush to implement the latest, greatest AI-enhanced, post-quantum container-based blockchain security solution.

We don’t do security because it’s fun. No: let me qualify that. Most of us don’t do security because it’s fun, but none of us get paid to do security because it’s fun[1]. Security isn’t a thing in itself, it’s a means to an end, and that end is to reduce risk. This was a notable change in theme in and around the RSA Conference last week. I’d love to say that it was reflected in the Expo, but although it got some lip service, selling point solutions still seemed to be the approach for most vendors. We’re way overdue some industry consolidation, given the number of vendors advertising solutions which, to me, seemed almost indistinguishable.

In some of the sessions, however, and certainly in many of the conversations that I had in the “hallway track” or the more focused birds-of-a-feather type after show meetings, risk is beginning to feature large. I ended up spending quite a lot of time with CISO folks and similar – CSO (Chief Security Officer) and CPSO (Chief Product Security Officer) were two other of the favoured titles – and risk is top of mind as we see the security landscape develop. The reason this has happened, of course, is that we didn’t win.

What didn’t we win? Well, any of it, really. It’s become clear that the “it’s not if, it’s when” approach to security breaches is correct. Given some of the huge, and long-term, breaches across some huge organisations from British Airways to the Marriott group to Citrix, and the continued experience of the industry after Sony and Equifax, nobody is confident that they can plug all of the breaches, and everybody is aware that it just takes one breach, in a part of the attack surface that you weren’t even thinking about, for you to be exposed, and to be exposed big time.

There are a variety of ways to try to manage this problem, all of which I heard expressed at the conference. They include:

cultural approaches (making security everybody’s responsibility/problem, training more staff in different ways, more or less often);
process approaches (“shifting left” so that security is visible earlier in your projects);
technical approaches (too many to list, let alone understand or implement fully, and ranging from hardware to firmware to software, using Machine Learning, not using Machine Learning, relying on hardware, not relying on hardware, and pretty much everything in between);
design approaches (using serverless, selecting security-friendly languages, using smart contracts, not using smart contracts);
cryptographic approaches (trusting existing, tested, peer-reviewed primitives, combining established but underused techniques such as threshold signatures, embracing quantum-resistant algorithms, ensuring that you use “quantum-generated” entropy);
architectural approaches (placing all of your sensitive data in the cloud, placing none of your sensitive data in the cloud).

In the end, none of these is going to work. Not singly, not in concert. We must use as many of them as make sense in our environment, and ensure that we’re espousing a “defence in depth” philosophy such that no vulnerability will lay our entire estate or stack open if it is compromised. But it’s not going to be enough.

Businesses and organisations exist to run, not to be weighed down by the encumbrance of security measure after security measure. Hence the “as make sense in our environment” above, because there will always come a point where the balance of security measures outweighs the ability of the business to function effectively.

And that’s fine, actually. Security people have always managed risk. We may have forgotten this, as we rush to implement the latest, greatest AI-enhanced, post-quantum container-based blockchain security solution[2], but we’re always making a balance. Too often that balance is “if we lose data, I’ll get fired”, though, rather than a different conversation entirely.

The people who pay our salaries are not our customers, despite what your manager and SVP of Sales may tell you. They are the members of the Board. Whether the relevant person on the Board is the CFO, the CISO, the CSO, the CTO or the CRO[3], they need to be able to talk to their colleagues about risk, because that’s the language that the rest of them will understand. In fact, it’s what they talk about every day. Whether it’s fraud risk, currency exchange risk, economic risk, terrorist risk, hostile take-over risk, reputational risk, competitive risk or one of the dozens of other types, risk is what they want to hear about. And not security. Security should be a way to measure, monitor and mitigate risk. They know by now – and if they don’t, it’s the C[F|IS|S|T|R]O’s job to explain to them – that there’s always a likelihood that the security of your core product/network/sales system/whatever won’t be sufficient. What they need to know is what risks that exposes. Is it risk that:

the organisation’s intellectual property will be stolen;
customers’ private information will be exposed to the Internet;
merger and acquisition information will go to competitors;
payroll information will be leaked to the press – and employees;
sales won’t be able to take any orders for a week;
employees won’t be paid for a month;
or something completely different?

The answer (or, more likely, answers) will depend on the organisation and sector, but the risks will be there. And the Board will be happy to hear about them. Well, maybe that’s an overstatement, but they’ll be happier hearing about them in advance than after an attack has happened. Because if they hear about them in advance, they can plan mitigations, whether that’s insurance, changes in systems, increased security or something else.

So we, as a security profession, need to get better a presenting the risk, and also at presenting options to the Board, so that they can make informed decisions. We don’t always have all the information, and neither will anybody else, but the more understanding there is of what we do, and why we do it, the more we will be valued. And there’s little risk in that.

1 – if I’m wrong about this, and you do get paid to do security because it’s fun, please contact me privately. I interested, but don’t think we should share the secret too widely.

2 – if this buzzphrase-compliant clickbait doesn’t get me page views, I don’t know what will.

3 – Chief [Financial|Information Security|Security|Technology|Risk] Officer.

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.

Using words that normal people understand

Normal people generally just want things to work.

Most people[1] don’t realise quite how much fun security is, or exactly how sexy security expertise makes you to other people[2]. We know that it’s engrossing, engaging and cool, they don’t. For this reason, when security people go to the other people (let’s just call them “normal people” for the purposes of this article), and tell them that they’re doing something wrong, and that they can’t launch their product, or deploy their application, or that they must stop taking sales orders immediately, and probably for the next couple of days until this are fixed, then those normal people don’t always react with the levels of gratefulness that we feel is appropriate.

Sometimes, in fact, they will exhibit negative responses – even quite personal negative responses – to these suggestions.

The problem is this: security folks know how things should be, and that’s secure. They’ve taken the training, they’ve attended the sessions, they’ve read the articles, they’ve skimmed the heavy books[3], and all of these sources are quite clear: everything must be secure. And secure generally means “closed” – particularly if the security folks weren’t sufficiently involved in the design, implementation and operations processes. Normal people, on the other hand, generally just want things to work. There’s a fundamental disjoint between those two points of view that we’re not going to get fixed until security is the very top requirement for any project from its inception to its ending[4].

Now, normal people aren’t stupid[5]. They know that things can’t always work perfectly: but they would like them to work as well as they can. This is the gap[7] that we need to cross. I’ve talked about managed degradation as a concept before, in the post Service degradation: actually a good thing, and this is part of the story. One of the things that we security people should be ready to do is explain that there are risks to be mitigated. For security people, those risks should be mitigated by “failing closed”. It’s easy to stop risk: you just stop system operation, and there’s no risk that it can be misused. But for many people, there are other risks: an example being that the organisation may in fact go completely out of business because some *[8]* security person turned the ordering system off. If they’d offered me the choice to balance the risk of stopping taking orders against the risk of losing some internal company data, would I have taken it? Well yes, I might have. But if I’m not offered the option, and the risk isn’t explained, then I have no choice. These are the sorts of words that I’d like to hear if I’m running a business.

It’s not just this type of risk, though. Coming to a project meeting two weeks before launch and announcing that the project can’t be deployed because this calls against this API aren’t being authenticated is no good at all. To anybody. As a developer, though, I have a different vocabulary – and different concerns – to those of the business owner. How about, instead of saying “you need to use authentication on this API, or you can’t proceed”, the security person asks “what would happen if data that was provided on this API was incorrect, or provided by someone who wanted to disrupt system operation?”? In my experience, most developers are interested – are invested – in the correct operation of the system that they’re running, and of the data that it processes. Asking questions that show the possible impact of lack of security is much more likely to garner positive reactions than an initial “discussion” that basically amounts to a “no”.

Don’t get me wrong; there are times when we, as security people, need to be firm, and stick to our guns[9], but in the end, it’s the owners – of systems, or organisations, of business units, of resources – who get to make the final decision. It’s our job to talk to them in words they can understand and ensure that they are as well informed as we can possibly make them. Without just saying “no”.

1. by which I mean “those poor unfortunate souls who don’t read these posts, unlike you, dear and intelligent reader”.

2. my wife, sadly, seems to fall into this category.

3. which usually have a picture of a lock on the cover.

4. and good luck with that.

5. while we’ve all met our fair share of stupid normal people, I’m betting that you’ve met your fair share of stupid security people, too, so it balances out[6].

6. probably more than balances out. Let’s leave it there.

7. chasm.

8. insert your favourite adjectival expletive here.

9. figuratively: I don’t condone bringing any weapons, including firearms, to your place of work.