May 23, 2006

Insider Threat – ISSA Article

Category: Security Article Reviews — Raffael Marty @ 10:19 am

I haven’t done any of these reviews in a while. I guess I haven’t been travelling much lately. Anyways. I came accross this article on Insider Threat by Ronald Mendell. I am not sure the author really understands the insider threat problem. Let me give you my perspective:

The author suggests that the primary line of defense against insider threat is using countermeasures based on specific responses to particular threats. That’s a mouth-full, isn’t it? He continues by saying that you should follow a recognized standard like ISO 17799 or a checklist to identify needed safeguards. Well, first of all, you can follow a lot of checklists and implement a security program based on ISO 17799 and still have tons of insider problems. Insiders do not use common attack vectors that can be revealed with following standard approached. That’s the core problem! [Note that I am not saying that you shouldn’t use a checklist, but it does not help much against your insider problem!]

Well, I would be a bad commentator if I was not offering another approach. If the author spent some time reading research in this area, he would have found a study by Mitre which suggests that most of the insiders can be detected while they do reconnaissance! Think about it. Someone who wants to abuse his privileges is not going to sound all the bells and whistles of your security controls, but he might go off and do some reconnaissance or start behaving abnormal! I am not going into details on how you could actually monitor these things, but you can imagine how (just look at the company I work for 😉

I also don’t see the point the author tries to make with his very lengthy bat-script example. He describes how someone builds a bat script on windows to collect certain information via different commands, such as the net command. He claims that the problem is that people can build bat scripts on their boxes. That’s completely wrong. The problem is that this user had privileges to execute the net command.

The article continues with giving a checklist of things to do to detect insiders. Actually it’s more a checklist that would prevent insiders from being successful. I couldn’t disagree more with the checklist. The things mentioned are good security practices, but do not help at all in preventing insider abuse. For example, the author urges people to block null sessions by filtering port 139/tcp and 445/udp traffic. First of all, it is exactly the other way around: 139/udp and 445/tcp. Second, where do you filter that? Between zones? That’s not going to help. If I am on the same LAN, I can still access other machines. If you turn it off on the end-systems, you won’t be able to share files among machines anymore. The only thing you really want to do is disabling anonymous connections and disable all default accounts, etc. And why would having a UNIX shell (which by the way is not how I would call a cygwin session) on a Windows machine is bad and needs to be turned off?! That’s hardly the problem. Does the author actually know what a UNIX shell is and what that means on a Windows box? Just because I might be able to write more powerful shell scripts (Is this even true? I bet bat scripts are pretty powerful too!), but that does not give me more control over what I am after…

Then again, the author mentions that users learn the vulnerabilities of the network or system and exploit them. Well, that might be a problem, but barely one that pertains to the insider threat problem! insiders don’t need vulnerabilities. Or do you think the CFO is going to exploit a vulnerability to get to confidential financial records? No dude, he already has legitimate access to them. The problem is if the CFO starts printing these things and takes them places! That’s what you are after! You gotta start to think differently!

Think profiling, think abnormal behavior, think watch-lists, think roles. That’s all I have to say!

May 19, 2006

Perl Performance Improvement

Category: Programming — Raffael Marty @ 4:18 pm

I was fiddling with optimizing AfterGlow the other day and to do so, I introduced caches for some of the functions. Later a coworker (thanks Senthil) sent me a note that I could have done without implementing the cache myself by using Memoize. This is how to use it:

use Memoize;
function(arguments); # this is now much faster

This will basically cache the outputs for each of inputs to the function. Especially for recursion this is an incredible speedup.