This is another one of those posts that started out on a listserv. The original thread was about using contracting staff for security work. Along the way, someone mentioned insider threat and I went off. Enjoy.
> While he or she does not necessarily have access to
> many/all functional areas (hopefully), he/she would
> have an easier time compromising the organization's
> security. Being that internal threats are much more
> prevalent than external ones, I'd argue that this
> poses a greater risk when compared to equally-
> screened contract employees under the same NDAs, etc.
I'm not sure that I agree with your statement that internal threats are much more prevalent, or even more prevalent. Looking at the CSI/FBI Survey results over time, the Internet surpassed internal networks as the origin of attack in 2001 and has been widening ever since. I don't think the data bears this conclusion out.
If I put my tinfoil hat on here for a minute, I do think that the way that insider abuse is hyped and promoted in infosec trade press is intentionally vendor-driven. Vendors whose products address border security at layers 3-4 found their sales slumping a few years ago when everybody finally got a firewall, everybody that was going to get NIDS got NIDS, and everybody that had to comply with GLBA got DLP.
So they started telling ghost-story-anecdotes about insiders and how we need to watch our staff like they're an elite team of Chinese hackers. Of course, they never suggested how they would solve the real insider issue. Insiders getting unauthorized access to data isn't the problem. It's what they do with the data that they *are* authorized to access that's the problem. When somebody comes up with IDS signatures for bad intentions, please let me know. I'll be the first one with my checkbook out.
I guess my bottom line on insider threat is not that it's wholly imaginary, but that it's not the same as external threats. Cool appliance-based technologies don't serve you as well inside. Doing things like monitoring use of administrative accounts, auditing financial application access for proper separation of duties, and proper pre-hire screening of staff go a whole lot further than watching what files people copy to their thumb drives and guessing what they might do with them.
2 comments:
This is a great post! I am at ArcSight (thanks for your 4.0 upgrade posts, btw), and we have an insider threat package. We are moving away from it toward an “identity monitoring” package. I think it’s more than just marketing spin, these aren’t the same concept. As you mention, insider threat does seem to imply very malicious hacker employees, which do exist. But, just as often, people want to monitor their users to see who’s accessing which apps, to get a better view of roles and rights for compliance audit, etc. We just spoke to one customer who is using these kinds of rules to see how many people access each app, so that he can increase or decrease his user licenses to his ERP vendor. That’s not insider threat, It’s identity monitoring.
I previously worked at Symantec (email security) and Oblix (identity/access management). At Oblix, I saw many companies put in IAM systems to get some consistent control across their (mostly Web) apps. They wanted to make sure that information didn’t leak out because of weak access control. IAM was a big deal and wasn’t just vendor hype. If anything, the problem is that it didn’t go far enough – it’s hard to control anything other than web apps with those products. Later, at Symantec, we did a deal to put the Vontu DLP stuff on our email AS/AV box. The demand for this was pretty good, because as you mention, the problem is not the data access, but what people do with the data – e.g. are they pasting it into a spreadsheet and mailing it.
I don’t think there is a magic bullet to fix the “watching what people are doing so that I protect my data" problem. But I do see a need for a combination of IAM, plus some basic data monitoring/fingerprinting, plus connecting to a much broader set of things that IAM does (like checking USB keys, print jobs, etc), plus profiling to baseline what normal access looks like, then correlating the whole thing to find problems or just give comprehensive reporting.
I think that if this is done right, it will be useful and not hype. People spend a lot of money on IAM products and can’t apply them to half the stuff in the environment. They don’t have access profiling to even understand if an action is good or bad. They have limited view into what happens to the data after authorized people access it. Even with SIEM products, there is much we can do to help our customers get more value from their investment. I think we can do better and packages like identity monitoring can make the existing products work better and give more value. “Insider threat” is occasionally real and when it is, it costs a lot of money. But there is much more to be done beyond just that.
Hi Rick! Thanks for the comment.
I'm familiar with the Insider Threat content pack from ArcSight. We use ArcSight for some of the things I mentioned above, like monitoring the use of privileged accounts or corellating application and server logs.
SIM's aren't really Identity Management tools, but the ability to do things like search across log types by username is a huge help in monitoring user activity and a big part of why SIM's are awesome in the first place.
But even according-to-Hoyle Identity Management tools don't solve the big part of the insider threat problem. You can make sure that everybody is who they say they are and, to the extent that homebrew and legacy apps play nice, do access control via roles. But the problem isn't Herbert from Accounts Recievable*
brute-forcing Myron from Accounts Payable's password. It's Myron telling Herbert his password, meaning Herbert can now cut checks to his DBA LLC. Or it's Herbert abusing the information he's supposed to have access to in order to do his job. And while I can do some cool asset-fu to find a login from Herbert's workstation to Myron's account, the other stuff is nearly impossible to distinguish.
* RIP H-Dog (1972-2007)
Post a Comment