Last year, I was invited to present on stage at one of the biggest cyber security conferences in the world, InfoSecurity Europe here in London. This is a huge event, with hundreds of vendors and tens of thousands of visitors every year.
Most people who get on stage at these events will rattle off demos and pitches about why their product is brilliant and necessary. Normally, a couple dozen people show up, and within five minutes they’re staring at their phone playing Candy Crush.
Instead of simply doing the same, I decided to speak about a topic I know a bit about. No demos, just knowledge. Far more people showed up than we had room for, and not one Candy Crusher among them!
The topic was ‘Understanding the Insider Security Threat’. There seems to be a lot of people confused about this. So, I’m looking forward to publishing a series of posts, which I hope will shed some light. And since all good blog series need to kick off with a ‘Top n Something for This or That’ post, lets get started.
1) Its about people, not just technology
Are you in your office right now? Look at the person sitting next to you. The person in the kitchen making coffee. The person in the next room who always talks too loud. They’re all just regular people, doing their jobs, going about their day.
The Insider Threat is the risk that regular, trusted staff allow sensitive information to fall into the wrong hands. These are the regular, trusted staff that we’re talking about.
Now, when one of them has a people-type problem, we find a people-type solution. Mary needs to take Thursday off work to attend her sister’s wedding. OK, but please make sure you work late during the week, so you get everything done by our Friday deadline. A people-type solution to a people-type problem.
Stopping sensitive information from falling into the wrong hands, this is a people-type problem too. How do we know whether any information is ‘sensitive’? How do we know which are the ‘wrong hands’? And whose decision should it be?
The answer depends so heavily on context, on personal experience, on instinct and gut-feel, that it most often comes down to a series of personal judgement calls.
Technology can certainly be of tremendous help in making these judgement calls. It can encapsulate and communicate the necessary context. It can support our instincts with better information. It can cut through complexity to help people make better decisions, and enact them more effectively.
But to approach the problem solely with technology-centric solutions, is to miss half the point. Unfortunately, when technical vendors sell technical solutions to technical people (DLP, RM, IDS and UBA, anybody?), they fail to appreciate that the problem is as much a human one, which can’t be solved with just the latest expensive acronym.
2) Many incidents are accidents
Prior to starting Torsion, I spent a career as a consultant, with several different consulting firms.
There was once an incident where the in-house HR team maintained a confidential spreadsheet with the name, salary, bonus payments and performance review results of every staff member at the firm. The spreadsheet was stored on what they thought was a locked-down, private folder on the company intranet.
When a new person named Eve joined the HR team, it was somebody’s job to share the private folder with her.
Normally, when typing people’s names into the Share screen of the intranet, you type the first few letters, and the system suggests matching names to pick from. But when typing Eve’s name into the Share screen, they must have accidentally selected ‘Everyone’ instead.
Most intranets have a built-in search. When you search for something, your search results are trimmed to just the files you have access to – so it didn’t take long for the HR spreadsheet to show up in everyone’s search results. The confidential information spread like wildfire.
The fallout was severe. Staff members everywhere lodged formal complaints. “Why is he getting paid more than me?”. “How could her performance review be better than mine?”. “Pay me as much as my teammates or I’m resigning”.
The firm lost some really talented staff members through that incident. Many had to be given big pay rises they hadn’t necessarily earned. The trust and reputational damage took years to fade.
An incident like this – it doesn’t fit most people’s idea of an information security breach, because it has nothing to do with “hackers”. But when a trusted staff member allows sensitive information to fall into the wrong hands and causes damage, that is an Insider Information Security breach. This was most definitely what happened here.
There was nothing malicious about the way that security breach happened. It was an accident.
3) One man’s trash is another man’s treasure
The sensitivity information is a very subjective idea. To say that one document is highly sensitive, while another is not, will often depend on the person making the decision. They cannot help but be influenced by their own perspectives and experiences, which can lead to poor decisions.
e.g. an IT Analyst, identifying the most sensitive information to move to a secure location. Due to the vast amount of legacy information – they might decide that files over 5 years old are not current, and therefore not as important.
The idea that anything out of date is worthless, is a classic technical person’s perspective. But files containing commercial details of past deals, or personal details of past customers and employees – don’t get any less sensitive over time.
A recent survey found that 35% of employees would be willing to sell company data for personal gain. Customer information, supply chain, technical designs – to an alarming number of employees, they are all for sale at the right price.
Their price was a function of their perception of the sensitivity of the data they were selling. Information they thought was less sensitive, they would be willing to sell for not much at all. 22% were willing to trade certain data for a nice dinner for two.
But their price isn’t low because they feel the information isn’t valuable. Their price is low because the less sensitive they think the information is, the easier it is to rationalise the act of selling it. The three key elements of employee fraud are pressure (personal motivation), opportunity (they have access), and ability to rationalise their actions.
But that same information, combined with other information obtained in other ways, could be exploited to embarrass the company, undercut its commercial opportunities, advantage its competitors or blackmail its executives.
4) Minimising access = Minimising risk
The severity of a risk is defined as its probability, multiplied by its consequence.
Therefore, the way to minimise a risk is to minimise the probability and/or impact of it occurring.
So, when it comes to Insider information security risks, we can minimise the risk in two ways. We can minimise the probability that employees and other insiders will cause a breach, and we can minimise the impact of a potential breach.
Generally, the more sensitive the information, the greater the impact if it is breached. And in most cases, the sensitivity of a piece of information – it is what it is. Even though sensitivity is subjective and hard to quantify, there usually isn’t much anyone can do to change it.
Which leaves us with one strategy – minimising the probability of a breach.
The simplest way to stop a person from causing a piece of information to fall into the wrong hands, is if they didn’t have access to it in the first place.
Obviously, this approach can’t be taken to its extreme. If nobody has access to anything, the company couldn’t function! But it forms the basis of the most effective, fundamental strategy for minimising the probability of these breaches occurring.
By minimising the set of people who have access to information, we minimise the risk of the information being breached. Drawing from the ‘Principal of Least Privilege’, we can implement a ‘Need to Know’ policy for access to information.
Simply put, every person should have access to only the information they need to do their job at any given moment, and nothing else.
5) Governance policy is not enough
In my consulting career, I designed information management systems for hundreds of clients, big and small. As part of every project we always wrote a governance policy, describing how the client should own and operate their new system.
In some areas, governance can be quite effective. Scheduling database backups, or approval processes to control sprawl, for example. It works because only a small number of people need to actually do anything for the policy area to be implemented.
But as a mechanism for implementing a Need to Know access policy – centrally implemented, human-based governance processes are utterly inadequate.
It is easy to write a policy saying that access should only be granted when people need it (and removed when they no longer need it). But accurately implementing it in practice is very difficult.
There are two reasons for this – complexity and change.
Imagine a huge piece of paper. On one side is a list of every file stored across the whole company (all tens of millions of them), and on the other side, every person in the company. Draw a line from every file, to every person who needs access to it.
Even when access is managed at a higher level of abstraction (collections, folders, etc.), the lines form a web of such complexity that no human could ever plausibly keep track of.
The second reason is change. Businesses never stand still. People are assigned to one role today, and another tomorrow. Customers come and go. New departments, old teams, new offices, old partners. Change is the only real constant!
When a person’s task or context changes, the set of information they need to do their job changes. They need new access to some things, and don’t need their old access to other things.
So, that impossibly complex web we imagined a moment ago is also constantly changing.
To expect a centrally implemented, human-based governance process to accurately control and validate every person’s access to information, is just not reasonable. The process always gets completely swamped.
In a coming post, I will explain the difference between governance processes which are centrally implemented, and de-centralised.
Thanks for reading!