http://www.ncaasports.com/icehockey/mens/recaps/d1_0407_01/2007/2007
At least there's 1 NCAA champion in Michigan. Yeah, I said it. Go Green!
Saturday, April 7, 2007
Thursday, April 5, 2007
Avivah Litan drops the dime on TJX
Avivah Litan, a VP and security analyst at Gartner, dishes on TJX to NetworkWorld. The interesting tidbit that she shares in this story is that they suspect that unsecured wireless APs were the hackers' way in. If that's true, there need to be some very public firings of security and network staff at TJX.
Wednesday, April 4, 2007
Guilty Pleasures, Social Networks, and Event ID's
So, one of my guilty pleasures is I like to read and answer the Information Security questions people ask on LinkedIn. It's like infosec Jeopardy without having to go to Vegas. Sometimes I even know the answer and have time to post it. The other day was one, and I'll share it here in a little more detail.
Venkatesh asks: "What are you monitoring on Active Directory/SQL Server as part of IT compliance?"
The cool thing about Microsoft EventLog format is the Event ID field, which for the most part tells you what is happening, and the details are things like who or what is doing that thing to who- or what-else. An example is Event ID Security:628. Any time you see that code, you know that A changed the password of B, and it is possible that A == B or A != B.
So get your left pinky finger ready for Ctrl-C & Ctrl-V action. Here's my big list of Security EventLog ID's that you should monitor as part of your log review processes.
In our environment (200+ Windows servers, another 80-100 UNIX servers that authenticate against AD, and 1200+ Windows workstations), this represents about 70-100 events per day out of roughly a half million EventLog entries that we collect per day. That's so totally manageable. The rest of it you can subject to trending, thresholds, and so on to find weirdness worth investigating.
It's also a good idea to go through your EventLog data every couple of months and look for new Event ID's that you haven't seen before. I use a filter that matches all of the Event ID's that I've already identified and excludes them. Then it's just a matter of researching the new Event ID's and determining their cause and relevance.
If you've got other ideas of good EventLog content that you focus on, post it up here. I'd love to hear about it!
Venkatesh asks: "What are you monitoring on Active Directory/SQL Server as part of IT compliance?"
The cool thing about Microsoft EventLog format is the Event ID field, which for the most part tells you what is happening, and the details are things like who or what is doing that thing to who- or what-else. An example is Event ID Security:628. Any time you see that code, you know that A changed the password of B, and it is possible that A == B or A != B.
So get your left pinky finger ready for Ctrl-C & Ctrl-V action. Here's my big list of Security EventLog ID's that you should monitor as part of your log review processes.
- EventID == Security:535
- EventID == Security:624
- EventID == Security:628
- EventID == Security:629
- EventID == Security:630
- EventID == Security:631
- EventID == Security:632
- EventID == Security:634
- EventID == Security:636
- EventID == Security:637
- EventID == Security:639
- EventID == Security:641
- EventID == Security:642
- EventID == Security:644
- EventID == Security:647
- EventID == Security:659
- EventID == Security:660
- EventID == Security:671
- EventID == Security:685
- Target Account Name == Administrator
- Target Account Name == [real admin user name] (you renamed Administrator, right?)
In our environment (200+ Windows servers, another 80-100 UNIX servers that authenticate against AD, and 1200+ Windows workstations), this represents about 70-100 events per day out of roughly a half million EventLog entries that we collect per day. That's so totally manageable. The rest of it you can subject to trending, thresholds, and so on to find weirdness worth investigating.
It's also a good idea to go through your EventLog data every couple of months and look for new Event ID's that you haven't seen before. I use a filter that matches all of the Event ID's that I've already identified and excludes them. Then it's just a matter of researching the new Event ID's and determining their cause and relevance.
If you've got other ideas of good EventLog content that you focus on, post it up here. I'd love to hear about it!
In Case You Missed It...
http://www.matasano.com/log/755/questions-for-stillsecure-about-cobia/
Tom at Matasano called out StillSecure for calling their new Cobia platform "open source."
It's a small nit to pick in my book - we all know that open source projects have been exploited by for-profit vendors pretty much from go. But read the comments.
There's a lesson for all of the vendors out there that are ripping off open source projects to save time and money - shut your mouth and don't try and spin it as 'giving back' or whatever.
Tom at Matasano called out StillSecure for calling their new Cobia platform "open source."
It's a small nit to pick in my book - we all know that open source projects have been exploited by for-profit vendors pretty much from go. But read the comments.
There's a lesson for all of the vendors out there that are ripping off open source projects to save time and money - shut your mouth and don't try and spin it as 'giving back' or whatever.
I Ain't Got No Crystal Ball...
...but I feel comfortable in predicting the next thing every NIDS vendor will roll into their products: full packet logging.
In a nutshell, analysis will be removed one step further from capture. You'll have a tool that logs all packets to disk. Then packet and stream data will be analyzed on disk. It will work like your current IDS except that you can go back and get all of the packets, not just the ones that the IDS alerted on at the time. There are both performance and forensic advantages to doing this. The main drawback is the amount of disk it will take and how you will manage data retention over time. But disk is cheap and security products are expensive and this is something that will make the old seem new again.
In a nutshell, analysis will be removed one step further from capture. You'll have a tool that logs all packets to disk. Then packet and stream data will be analyzed on disk. It will work like your current IDS except that you can go back and get all of the packets, not just the ones that the IDS alerted on at the time. There are both performance and forensic advantages to doing this. The main drawback is the amount of disk it will take and how you will manage data retention over time. But disk is cheap and security products are expensive and this is something that will make the old seem new again.
HoneyC Follow-Up
At the end of February, I posted about honeypots and honeyclients and promised a follow-up on Christian Seifert's HoneyC honeyclient.
If you want an intro to HoneyC and how it works, then visit here.
I installed HoneyC on OpenBSD 4.0 (my home firewall), but you can run it on just about anything since it's 100% Ruby. HoneyC relies on Snort-like signatures to detect web client attacks or malware. So the first step is to load it up with some signatures. I hacked up the web-client.rules file that comes free with Snort for starters. An example rule would be:
Original Snort rule:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT Javascript document.domain attempt"; flow:to_client,established; content:"document.domain|28|"; nocase; reference:bugtraq,5346; reference:cve,2002-0815; classtype:attempted-user; sid:1840; rev:7;)
Modified HoneyC rule:
alert tcp any any <> any any (msg:"WEB-CLIENT Javascript document.domain attempt"; flow:to_client,established; content:"document.domain|28|"; nocase; reference:bugtraq,5346; reference:cve,2002-0815; classtype:attempted-user; sid:1840; rev:7;)
The next step is to give HoneyC someplace to go looking for signature matches. There are two options for this. You can feed HoneyC a list of URLs to visit, or you can feed it a search term and it will search Yahoo and then crawl and analyze the results. The second option is a lot more interesting, and if you use your imagination, you can think of some easy search terms that will yield results (think keygen, lyrics, etc.) However, feeding HoneyC a list of URLs from, say, a proxy server log is a whole lot more relevant. For kicks I took a day's work of logs where the URL ended in .EXE and ran those through HoneyC. Sure enough, there were a couple of hits. But as you might have guessed, these were also found via traditional IDS. But unlike the IDS, I now have a sample of the malware to analyze.
In my opinion, HoneyC has some shortcomings. First, by being signature based, it misses a lot. And the whole point of using a honeypot or a honeyclient is to find bad stuff you don't already know about. So you may be able to luck up and find some new malware using old browser exploits, but since HoneyC doesn't parse JavaScript, or even automatically download URLs that look like malware (.EXE, .VBS, .CMD), you still have to do most of the heavy lifting. Getting it to run is really easy. But getting from there to having exploits and binaries to analyze is still a lot of work.
In recent honeyclient news, Niels Provos, one of the monkey.org supergeniuses has released SpyBye. SpyBye is a proxy that analyzes pages for browser exploits. You can run and install it locally or you may use the proxy that Niels has set up at spybye.org. Very cool.
If you want an intro to HoneyC and how it works, then visit here.
I installed HoneyC on OpenBSD 4.0 (my home firewall), but you can run it on just about anything since it's 100% Ruby. HoneyC relies on Snort-like signatures to detect web client attacks or malware. So the first step is to load it up with some signatures. I hacked up the web-client.rules file that comes free with Snort for starters. An example rule would be:
Original Snort rule:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT Javascript document.domain attempt"; flow:to_client,established; content:"document.domain|28|"; nocase; reference:bugtraq,5346; reference:cve,2002-0815; classtype:attempted-user; sid:1840; rev:7;)
Modified HoneyC rule:
alert tcp any any <> any any (msg:"WEB-CLIENT Javascript document.domain attempt"; flow:to_client,established; content:"document.domain|28|"; nocase; reference:bugtraq,5346; reference:cve,2002-0815; classtype:attempted-user; sid:1840; rev:7;)
The next step is to give HoneyC someplace to go looking for signature matches. There are two options for this. You can feed HoneyC a list of URLs to visit, or you can feed it a search term and it will search Yahoo and then crawl and analyze the results. The second option is a lot more interesting, and if you use your imagination, you can think of some easy search terms that will yield results (think keygen, lyrics, etc.) However, feeding HoneyC a list of URLs from, say, a proxy server log is a whole lot more relevant. For kicks I took a day's work of logs where the URL ended in .EXE and ran those through HoneyC. Sure enough, there were a couple of hits. But as you might have guessed, these were also found via traditional IDS. But unlike the IDS, I now have a sample of the malware to analyze.
In my opinion, HoneyC has some shortcomings. First, by being signature based, it misses a lot. And the whole point of using a honeypot or a honeyclient is to find bad stuff you don't already know about. So you may be able to luck up and find some new malware using old browser exploits, but since HoneyC doesn't parse JavaScript, or even automatically download URLs that look like malware (.EXE, .VBS, .CMD), you still have to do most of the heavy lifting. Getting it to run is really easy. But getting from there to having exploits and binaries to analyze is still a lot of work.
In recent honeyclient news, Niels Provos, one of the monkey.org supergeniuses has released SpyBye. SpyBye is a proxy that analyzes pages for browser exploits. You can run and install it locally or you may use the proxy that Niels has set up at spybye.org. Very cool.
Monday, April 2, 2007
Subscribe to:
Posts (Atom)