Thursday, February 15, 2007

The Plural of Anecdote is Boring


Dark Reading has an article on identifying the insider threat, although it seems to be more focused on how to spot a bad employee. The article, which seems to be anecdote-based information from Rob Enderle and RSnake, lists the top ten warning signs that you may have a bad employee, or, as they term it, an "insider."

Sure, the insider threat may be a subset of the bad employee, but these ten warning signs don't seem to indicate anything else. The IP thief is not the same as the disgruntled vandal is not the same as the black market carder. The article conflates all these threats, and winds up with recommendations so broad as to be meaningless. For example:

  • Excessive absences
Well, this is bad employee behavior. But an employee who is about to leave is no less damaging a threat than an employee who has an ongoing scheme that requires constant maintenance. The classic anti-fraud control of requiring an employee to take vacation seems to run counter to the cited behavior. Is the dude taking extra sick days as dangerous as the dude who routinely funnels dozens of credit card numbers or SSNs to his buddy on CarderPlanet but keeps a low profile?

  • Unusual behavior / Office romance gone bad
Bad stuff, but is there really a high enough incident rate to justify it as a "red flag" for a potential bad guy? If not, this advice seems to confuse as much as clarify.

  • Employee is terminated / Employee resigns
I believe the employee would be participating in the "outsider threat" at that point.

The real meaty threats and red flags associated with them are a bit more nuanced, and have been hashed out in the fraud investigation field for years. Computer crime is just crime. Vandals are vandals. The computer security industry seems to be genuinely befuddled when encountering a threat that doesn't have a 8P8C modular connector jack.

Image from oronzo.

2 comments:

Alex said...

D-

What do you think of internal honeypots?

Dutcher Stiles said...

I'm trying to think of a practical use for them. Assuming you have an insider problem, and using the SANS definition of honeypot (http://www.sans.org/resources/idfaq/honeypot3.php), are the folks breaking into the honeypot the same as the ones causing your info leakage problems? It seems that you'd have to model the honeypot so close to the production system, other countermeasures might better solve the problem.

Also, I feel it's different to try to deceive hostile outside attackers than to try to deceive people you've hired and trust enough to get legitimate access. Besides ethics, there could be complicated legal & HR issues.

I'd be interested in hearing about a real life examples.