Back
Insider Threats
We all want to believe that our co-workers will do the right thing. That we need to focus our security efforts on the bad guys “out there.” However the insider threat is one of the worst incidents that an organization can withstand. Carnegie Mellon’s CERT® Coordination Center has launched the CERT Insider Threat Database. They have collected approximately 700 cases of insider activity that “resulted in the disruption of an organization’s critical information technology (IT) services.” I realize that 700 cases since they started collecting data in 2001 seems like a drop in the bucket but it’s important to remember that these are cases involving the critical IT services, and were reported to CERT. Many incidents are not reported as the organization doesn’t want the negative publicity, or in even worse cases, the perpetrator hasn’t been caught (yet). In many discussions about Insider Threats I’ve referred to the San Francisco IT Administrator charged with holding the city’s network hostage. In this particular case he didn’t give the administrative credentials back to his employer but kept the systems operational. It was a good example but is now a bit dated (2008) but it was only a matter of time before another one emerged. With a roar, it did. An IT Administrator has recently pleaded guilty to crippling his former employer’s network. Now some have dubbed this a “hacking spree” but I would like to differentiate this as not a hack, but an individual that had elevated privileges that became so disgruntled that he lashed out. When he did so, he didn’t use specialized hacking tools or techniques, instead he used a common administrative tool to delete critical IT systems causing in excess of $800,000 in damages according to court documents. What makes this example worse is that this individual resigned before the attack, but the organization kept him on as a consultant “due to this extensive knowledge of the company’s network.” He performed his attacks with valid user credentials and common support tools. Why am I trying to draw such a distinction whether this is hacking or not? When discussing risks as either part of your normal risk assessments, Risk Management Program, etc. I think it is important to draw the distinction as it relates to policies and implementable controls. There is usually a lot of effort put into place to protect against malicious and unauthorized attacks (i.e., hacking) compared to disgruntled individuals with elevated privileges. Malicious? Yes. Unauthorized? No. That’s the scary part and the one that needs to be addressed by each and every organization. The take away here is to ensure that segregation of duties is followed so not one person has keys to the kingdom and disgruntled employees are not retained where they can cause extensive damage to the organization.
