Designing for crime

Designing for crime I’m sure that those who read this column are honest, law-abiding folks who wouldn’t dream of mugging granny for her weekly pension. In fact, many of you will not have ever been exposed to any sort of crime, even as a victim (and for those who have been a victim, accept my sympathy.)

I’m sure that those who read this column are honest, law-abiding folks who wouldn’t dream of mugging granny for her weekly pension. In fact, many of you will not have ever been exposed to any sort of crime, even as a victim (and for those who have been a victim, accept my sympathy.)

This is actually a major problem: we really don’t think about life from a criminal perspective, but tend to treat our life, and the processes and systems within it, as if people reacted as we do, viewed things from our perspective, and basically followed the mainstream, logical, linear process which we have laid out for ourselves, our colleagues, users and customers.

This applies to our ICT systems too; all too often, it comes as a big surprise when users do peculiar things to our systems, things that we never anticipated. It comes as an even bigger surprise when as a system is exploited. ‘Who would ever have thought they’d do that,’ you cry. We do of course learn the hard way, but anticipating it is a much less painful process.
Crime is always with us. There will always be people who have a different definition of morality than you. Often they will win, because they will work harder to take your wallet than you will to protect it, and in the process be more prepared to use violence and risk being hurt than you would be. In an IT scenario, nothing changes; if there is prospect of reward, they may spend a long time diligently seeking the loopholes in your system, until they find the way in.

Someone once said, of hackers, that the security officers are paid 9 till 5, 5 days a week, to build the barriers whereas the hacker will willingly work 24x7 until he defeats them. The contest is therefore uneven. To quote Paul Ekblom, we can simplify the great variety of crime and how it relates to technology into a few broad headings, (taken from the Misdeeds and Security framework):
Misappropriation – property stolen;
Mistreatment – property damaged, people assaulted, self-harm;
Misuse – as tools, weapons, information for crime
Mishandling – property subject to deception, counterfeiting and smuggling; information illegally divulged to third party;
Misbehaviour –an environment conducive to disorder
When you think about it, this covers everything in an electronic environment too.
I suggest also that whilst computer crime or e-crime creates its own mystique, the vast majority is ‘old’ crime, which is transferred into an electronic environment. There is a small minority of ‘new’ crime, which was not possible or practical or cost-effective in a manual world, but of course IT assists everyone to do things better. In either case they all fall into one of the 5 Ms above.

Do we even think about them in our system design? I suggest that in the interests of streamlining, simplifying and automating we often don’t. A fun example, perhaps, but the humble wheelie bin is effective and efficient,it holds your rubbish competently, is easily moved, and is emptied mechanically with minimal intervention.

A great innovation, but when designing it, did they think ‘crime’? What they provide at the back of your house is an easily portable platform for the burglar to use as a step to get up to window-level, a neat work-bench for him to use, and a useful receptacle to hide away your property until they can safely pick it up. A different design could have drastically reduced its crime potential, without affecting its functionality as a rubbish container.
In IT systems, often we streamline processes and in the process remove the old-fashioned checks and balances. A simple example, but in one organisation, all expense claims were once filled in on paper and countersigned. Of course there was never any real fraud, because everyone knew the claims were likely to be examined.

So one day came the argument that instead of wasteful filling in of paper and countersigning (which arguably just wasted time as no fraud had ever been discovered) people should fill in their expenses online and submit the claim directly for automatic payment. No more collecting bus tickets and hotel bills, taxi receipts, etc. No more paper mountain. Simpler, more efficient, cuts out the middle man, but think about it.

One manager argued that even if a small amount of fraud were ever to occur, the savings would outweigh the loss. But how do you quantify that, and is it a valid argument anyway? We didn’t actually let this one through, but it was not an isolated case. How many systems like this, more complicated and less obviously flawed, do you have in your organisation?
In both these cases, people didn’t really consider the design from a crime perspective.
 These cases are very simple and obvious– most of your systems and processes are much less obvious. Even so, the designers didn’t ask about the potential for each of the 5 M’s, and how they might reduce the potential. Their eye was on another ball, regrettably. Computer crime is a growth industry, possibly one of the faster growing sectors of our economy.

Government, police and industry are all looking to see how we can design crime out of our systems. You may expect to see a lot more interest in this area in the next few months. Whatever they can do to raise awareness of the issue will be a good thing, and will help you, as a security officer, by demonstrating you are not alone in what you say. But ultimately it is going to be up to people like you. Only you can help to slow down the e-crime epidemic.

 Next time you look at the system’s security measures, look beyond the firewall settings and the user authentication processes, and ask ‘Have the company and the designers considered these 5 M’s? Have we designed our system to assist in e-crime, or to discourage it?’ Give us Your View

 Do you agree with Les Fraser’s view on e-crime?
 How many ‘M’s’ are in your system design?
 Send us your feedback to
 [email protected]

Read more on IT risk management