Friday, June 23, 2006

Security Metrics (part 1)

I attended two of Dan Geer's presentations in the last year. The first was at shmoocon 2006 while the other was at usenix. Both were about finding and applying metrics to security.

I'm currently doing some neat scripts to measure changes in firewall configurations. That's a whole other ball of wax that just happens to fit into this metrics post (and will eventually be part 2).

Something simpler: passwords. I thought it'd be a simple case of pulling out JtR and then make some silly charts. That ended up having lots of variables. To keep things sane, I'm using stock (documented) hardware along with a typical install of Fedora. I then compiled john w/ system x86-linux-mmx flags. These are all things I'm tracking to verify that, over time, the test constants stay the same.
Then I dug into JtR as I never used it. Props to Solar Designer, as it's really pretty sweet. I didn't find anything that let me see how long a certain password took to crack though. That made me sad, which made me resourceful.

Here is a small perl script I wrote (simply requires the Proc::Background module). It's slightly hackish but golly it's cool.
./ -h ntlmhashes.pwdump -t incremental -o output.csv -i 30:120:300:3600:28800

This revs up JtR to just brute forcing the passwords in ntlmhashes.pwdump. It then outputs the number of passwords cracked per each increments as seperated by the colon
$ cat output.csv

Which is pretty lame until you import it into excel:

cracked passwords over time

Now, you do this on a routine basis (say, quarterly) and you can then track as users have stronger or weaker passwords. This can provide data on if your current policy is adequate, or if password awareness is adequate.

And it'll get looked at because everyone likes graphs. This is a rough script, and I've only ran it against test hashes. I should have a more streamlined (converts seconds to minutes, etc) version in the next few weeks.

No comments:

Post a Comment