1. Technology
You can opt-out at any time. Please refer to our privacy policy for contact information.

Combating The Insider Threat With Misuse Cases

That bad guy could be sitting right next to you.


Combating The Insider Threat With Misuse Cases
Photo: Noel Hendrickson / Getty

The Wikileaks debacle has highlighted the fact that one of the biggest threats facing many organizations is the insider threat. Most security efforts are focused on keeping bad guys out, but all too often, the bad guy is sitting in the cubicle next to you, and is already behind your firewall.

What can you do to mitigate the risks associated with having your system abused by insiders?

It all starts with business process development and software design. Use cases are used in both software development and business process engineering. A use case in it's most basic form involves actors (people or other systems), a goal, and the steps and interactions required to achieve the goal. Software developers and engineers create use cases to lay the groundwork for the business rules and system processes that will make up a system.

The 'goal' of a use case is the intended end result of a process that the system was designed to support. An example of a use case goal for an online store would be "accept customer order", or "charge customer's credit card account". The problem is that developers and business process engineers often mistakenly assume that everyone is motivated to do the right thing.

Use cases are built to support intended process outcomes and aren't designed to deal with the bad guy factor. They don't take into account that there are bad people in the world that do bad things like steal credit card numbers. These people don't just hang out in alleys leering at passersby, these people work right along side you, and may want to abuse your system process for fun or profit (most likely profit).

Enter the misuse case. A misuse case describes something that the process stakeholders don't want to happen or have the process used for. If a use case was an angel on your shoulder, the misuse case would be the devil on your other shoulder. Misuse cases make system engineers and process designers put on their bad guy hats and think things like "if I wanted to steal from the company, how would I abuse the system to make this happen" and "what checks and balances does this process have in place to ensure that a theft doesn't go unnoticed.

How would this help with a Wikileak's type scenario? For starters, if "safeguard company/government secrets" were the use case, then "steal company/government secrets" would be the misuse-case. Process designers and software engineers would ask questions such as "how would I get data out of this system if I were trying to steal it" and then would develop a misuse case that would identify the weak points so they could modify access control, data handling procedures, network and media safeguards, and other processes so that the threats were mitigated to a level that was acceptable to the system and process stakeholders.

So how do you incorporate misuse cases to help protect your systems?

1. Educate your stakeholders on the misuse case concept.

Management buy-in is critical for success. It may take a minute or two for them to wrap their heads around the concept, but they should be able to understand that if misuse occurs and is not adequately planned for, then they could face consequences (i.e. go to jail.

2. Have your system architects and developers place themselves in the shoes of someone trying to abuse the system and its processes.

Misuse case development can actually be kind of fun because you get to try to break things. Your developers will likely have more fun developing misuse cases than they do with use cases.

3. Download templates for misuse case development

There is no reason to recreate the wheel if you don't have to. There are some excellent misuse case templates available on the Internet developed by people who have been doing this type of thing for awhile. Use the templates as guides and tailor them to your needs.

4. For every use case where security might be a concern, create at least one misuse case.

Not every use case will need a misuse case. Focus on developing misuse cases for the most critical areas where fraud and abuse might occur. Finance-related processes are an obvious target and are a great place to start.

©2014 About.com. All rights reserved.