Insider Threat

Somebody showed me a magazine article a few days ago about the “threat within” and ask me if I was concerned and considered it a risk for my own organisation.

It would be a foolish security manager who didn’t consider the insider risk. I judge the risk here using two measures.

1. Using the common quoted risk = threat * vulnerability assessment where the threat is likely to be relative to factors such as the number of employees you have, the value of your data to an external organisation, and your staff turn-over. The vulnerability level should take into account factors such as the number of individuals with access rights to high value data or critical systems and the presence of controls such as fraud detection software and system audits. If controls are lacking then read this story on Information Week and consider the consequences if the malicious code planted by the employee had not been discovered.

A former systems administrator at Medco Health Solutions pleaded guilty in federal court Wednesday to writing and planting malicious code that could have crippled a network that maintains customer health care information.

Now read this one which shows what happens when the code is not found in time.

A former IT worker for UBS has been found guilty of attempting to profit by unleashing a ‘logic bomb’ computer virus on the bank’s network that caused more than $3 million in damage.

2. What is the “return on attack” that a disgruntled employee or – let’s be plain – thief could get from stealing your data or bringing down a system? In other words, is the crime likely to be quickly detected, and what value does data have once it leaves the office and would the individual be able to profit from it? A paper I quoted from during some related research I performed some time ago makes the point that we must take into account the “difference between mitigating the effects of attacks and discouraging attackers by making their efforts no longer profitable.” (from: Evaluating Information Security Investments from Attackers. Perspective: the Return-On-Attack (ROA), by Marco Cremonini and Patrizia Martini). In other words, if they think they will be caught then they are less likely to try to commit the crime in the first place.

There are a variety of things we can use to try to detect malicious or fraudulent activity on our networks:

1. Monitoring of database activity monitoring encompassing database transactions and privileged access.

2. Use of content monitoring and filtering to discover inappropriate use of content and data, although the ability to detect anything of interest will be limited to what can be discovered via simple data pattern rules.

3. Fraud detection software can discover and stop suspect user activity although only for the specific set of applications and business rules with which it interfaces.

4. Network behavior analysis tools can discover anomalous network traffic between applications and associate that traffic with a specific user.

Nothing is going to be 100% reliable and technical controls are only one element. Your organisational culture must also play a part as well as having in place authoritive policies and a documented process for what actions to take in the event that you do suspect an employee of malicious or fraudulent activity.