If you are like me you are always (or in stages) on the lookout for “noise” events to filter out of the SIEM. Windows event 673 is fairly tempting in that regard. However, depending on what sources you are pulling in you can leverage these events, which are recorded on your DCs, to see PCs hitting other PCs. There are two main limitations to these events. The first is you can’t see what network resource on the destination the source is trying touch. The second is you can’t see if the attempt was successful or not. If you REALLY needed that information though you probably have the appropriate level of logging turned on at the destination anyway.
Wednesday, May 19, 2010
The complete guide to SIEM use cases
I started looking for information on the web relative to SIEM use cases over a year ago. Almost a self search for just-in-time learning as it were. Unfortunately the list doesn’t exist. I think I have come to terms with that fact /wipes tear. The reality is everyone’s environment is different. Different tools, different event sources, different size shops, different foci, etc etc.
Don’t get me wrong. There are nuggets “out there” just…spread around. Hopefully I can throw a few things out there as well as this progresses. Always looking for ideas whether complete or still in concept phase. Would also be interested in getting a feel for good classes out there. (hit me at m j runals at gmail dot com if you don’t want to discuss in the comments).
At any rate I spent some time yesterday marrying a couple different items we created within our ArcSight ESM. I was left with two thoughts:
1. I used a good bit of Query Viewers and variables to pull this off (looking forward to global variables with 5.0) and was left with a feeling like I was building an application within an application. The feeling was very strange though I can’t really put my finger on why….could use more sleep I guess.
2. I want a way to combine multiple queries into one trend or chart.
Don’t get me wrong. There are nuggets “out there” just…spread around. Hopefully I can throw a few things out there as well as this progresses. Always looking for ideas whether complete or still in concept phase. Would also be interested in getting a feel for good classes out there. (hit me at m j runals at gmail dot com if you don’t want to discuss in the comments).
At any rate I spent some time yesterday marrying a couple different items we created within our ArcSight ESM. I was left with two thoughts:
1. I used a good bit of Query Viewers and variables to pull this off (looking forward to global variables with 5.0) and was left with a feeling like I was building an application within an application. The feeling was very strange though I can’t really put my finger on why….could use more sleep I guess.
2. I want a way to combine multiple queries into one trend or chart.
Wednesday, May 12, 2010
A brief FUD and SIEM thought
A buddy at work ran across a Wall Street Journal article that mentioned "Arcsight’s profits were up over 300% last year despite the recession and sales were up over 30%." This was basically attributed to FUD.
Of the many things you could say about those stats the one that is most on my mind is that I hope the companies that bought the software didn't just buy it to "do SIEM" or check a box and deploy it in a manner that will simply lead to failure or under utilization. At the very least I hope they have or are willing to set aside most of an FTE for care and feeding of the system.
I had a conversation with an ArcSight VP who mentioned one of their observations/frustrations is going back to a company two years after their professional services helped with an install and basically seeing no new content. To that end I think there is a very real effort within the company to make things easier and introduce some scaling (downward) for medium and smaller customers. The reality is though, imho, SIEMs aren't an InfoSec product like other point specific InfoSec solutions. In other words you buy AV, IPS, FW, etc to address a specific issue in your environment. A SIEM is really more of a platform you can use to survey normalized event data from across your network. To that end it requires effort to build and maintain content as well as effort to (crazy thought here) respond to the issues found.
Of the many things you could say about those stats the one that is most on my mind is that I hope the companies that bought the software didn't just buy it to "do SIEM" or check a box and deploy it in a manner that will simply lead to failure or under utilization. At the very least I hope they have or are willing to set aside most of an FTE for care and feeding of the system.
I had a conversation with an ArcSight VP who mentioned one of their observations/frustrations is going back to a company two years after their professional services helped with an install and basically seeing no new content. To that end I think there is a very real effort within the company to make things easier and introduce some scaling (downward) for medium and smaller customers. The reality is though, imho, SIEMs aren't an InfoSec product like other point specific InfoSec solutions. In other words you buy AV, IPS, FW, etc to address a specific issue in your environment. A SIEM is really more of a platform you can use to survey normalized event data from across your network. To that end it requires effort to build and maintain content as well as effort to (crazy thought here) respond to the issues found.
Tuesday, May 11, 2010
Monitoring logs and SIEMs
So there are several SIEM articles that tackle SIEMs vs Log Management, reasons you might want to use one in your environment, and what you might hope to see with one. I’m kinda a simple guy though and while I have recently tried to wrap my head around the nuances between monitoring log management style vs “just” alerting and how you might use a SIEM to both ends I was hit with a rather simplistic realization - the SIEM is already monitoring the logs.
See, I said it was simplistic. Here is what I mean though. I currently have multiple tickets open with ArcSight support and having reviewed multiple sets of manager logs one of the techs was kind enough to open an additional ticket based on some things she saw. I had three takeaways:
1. I should monitor the ArcSight logs. (I’m insightful aren’t I)
2. If I had been monitoring them I would have picked up on the warnings/errors/whatever that was seen
3. My manager logs rolled every 2 hours – used to anyway.
This, to me, makes the manager logs a perfect candidate for insertion into the SIEM. Granted part of the “perfect” is that the logs are being generated by something designed to suck in logs so it doesn’t seem to make a whole lot of sense to have something other than itself actually monitor…itself. The other side of this is while there is value in actually looking at the logs periodically I think this is also a perfect case of being able to just set up alerts.
The real takeaway then is maybe an adjustment to the argument that SIEMs are an “analyst in a box.” While they aren’t really an analyst they are at least some/part/multiple/an FTE who is, or at least capable of, monitoring logs. The next takeaway is according to the 2009 Verizon Data Breach Investigations Report we should be looking at application logs anyway. I mean the OS logs I am pulling in from the server hosting the ESM certainly aren’t telling me anything about these “guardoverflow” events that I should apparently search for in my logs in order to fix some data monitors.
See, I said it was simplistic. Here is what I mean though. I currently have multiple tickets open with ArcSight support and having reviewed multiple sets of manager logs one of the techs was kind enough to open an additional ticket based on some things she saw. I had three takeaways:
1. I should monitor the ArcSight logs. (I’m insightful aren’t I)
2. If I had been monitoring them I would have picked up on the warnings/errors/whatever that was seen
3. My manager logs rolled every 2 hours – used to anyway.
This, to me, makes the manager logs a perfect candidate for insertion into the SIEM. Granted part of the “perfect” is that the logs are being generated by something designed to suck in logs so it doesn’t seem to make a whole lot of sense to have something other than itself actually monitor…itself. The other side of this is while there is value in actually looking at the logs periodically I think this is also a perfect case of being able to just set up alerts.
The real takeaway then is maybe an adjustment to the argument that SIEMs are an “analyst in a box.” While they aren’t really an analyst they are at least some/part/multiple/an FTE who is, or at least capable of, monitoring logs. The next takeaway is according to the 2009 Verizon Data Breach Investigations Report we should be looking at application logs anyway. I mean the OS logs I am pulling in from the server hosting the ESM certainly aren’t telling me anything about these “guardoverflow” events that I should apparently search for in my logs in order to fix some data monitors.
Monday, May 10, 2010
Tickets and more tickets
I think I overheard my ordinal placement by ticket count relative to other ArcSight customers. I don't know if I should be proud or ashamed lol.
No I'm not in the number one position.
The irony, if there is one, is that we are on the lower side of a mid range company (by events per day). Not all of mine are overly deep/hard/indepth issues but I'd like to think I don't have a whole lot in the "how is the weather in Cupertino" category either.
No I'm not in the number one position.
The irony, if there is one, is that we are on the lower side of a mid range company (by events per day). Not all of mine are overly deep/hard/indepth issues but I'd like to think I don't have a whole lot in the "how is the weather in Cupertino" category either.
Saturday, May 8, 2010
Random ArcSight stuff from the week
Random stuffs from the week
Apparently there aren’t a whole lot of ArcSight customers with Win2k8 DCs. I say this because when I started looking at the event stream from when we spun ours up I was shocked at how many domain (vs local) events didn’t have the client side IP in the sourceAddress field. Lovely. Granted I am sure there are probably some high speed ArcSight admins out there who have done modifications to the Unified Connector to overcome this but this last week and a half has been crazy. I also figure by sending the events into ArcSight for them to adjust the connector I have helped the overall client base (aka I’m lazy).
I HAVE to carve out time to go through the Win2k8 events anyway as I think there are some slight differences in the fields data goes into. Noticed this on some content tracking AD group membership. In many cases I tried being preemptive and added the 2008 event ID to the appropriate filters. Yeah….not so much. If you aren’t familiar with those events I highly recommend looking up Randy Franklin Smith’s Ultimate Windows Security site. The quick and dirty way to know what the new event ID will be is to add 4096 to the 2003 event.
Trends. A Trend timeout will occur at the lesser of 50% of the scheduled run time or 2 hours. I could have sworn it was 4 hours in 4.0. Actually I should be looking at a pair of reports I created to do some analysis on my Trends start, run length, and insert counts due to some issues we are seeing but the magic of the flat panel TVs displaying the menus the Tim Hortons I am in has captured my attention. Is anyone else using this technology for this ends? Is cool. Been 2 years since I have stepped inside one. Probably more on Trends in my next post assuming I haven’t wrapped my arms around some post ideas on monitoring vs alerting and SIEM use.
The oil change on the family assault vehicle is probably done and I should get out of here before I get some ice cream (Tim Hortons + Cold Stone = win (or fail depending on your point of view)).
Apparently there aren’t a whole lot of ArcSight customers with Win2k8 DCs. I say this because when I started looking at the event stream from when we spun ours up I was shocked at how many domain (vs local) events didn’t have the client side IP in the sourceAddress field. Lovely. Granted I am sure there are probably some high speed ArcSight admins out there who have done modifications to the Unified Connector to overcome this but this last week and a half has been crazy. I also figure by sending the events into ArcSight for them to adjust the connector I have helped the overall client base (aka I’m lazy).
I HAVE to carve out time to go through the Win2k8 events anyway as I think there are some slight differences in the fields data goes into. Noticed this on some content tracking AD group membership. In many cases I tried being preemptive and added the 2008 event ID to the appropriate filters. Yeah….not so much. If you aren’t familiar with those events I highly recommend looking up Randy Franklin Smith’s Ultimate Windows Security site. The quick and dirty way to know what the new event ID will be is to add 4096 to the 2003 event.
Trends. A Trend timeout will occur at the lesser of 50% of the scheduled run time or 2 hours. I could have sworn it was 4 hours in 4.0. Actually I should be looking at a pair of reports I created to do some analysis on my Trends start, run length, and insert counts due to some issues we are seeing but the magic of the flat panel TVs displaying the menus the Tim Hortons I am in has captured my attention. Is anyone else using this technology for this ends? Is cool. Been 2 years since I have stepped inside one. Probably more on Trends in my next post assuming I haven’t wrapped my arms around some post ideas on monitoring vs alerting and SIEM use.
The oil change on the family assault vehicle is probably done and I should get out of here before I get some ice cream (Tim Hortons + Cold Stone = win (or fail depending on your point of view)).
Sunday, May 2, 2010
Tip of the Day
By a pair/box of latex gloves before you change the brakes on your car. What a difference!
ArcSight's PartitionInfo.log
Move over James Patterson – Kerry “the database queen” has posted the third installment of her series on reviewing the partitioninfo.log file. Its a real page turner…well if you printed it out on multiple pages. This is a file you should be generating at least twice a month as part of a backup process even if you don’t review it (KB article 572 if you need instructions). Kerry has been the proud recipient of several “coolest chick in the world” minutes given out by me based on her decisive, insightful, and quick treatment of database related trouble tickets. She would probably score 6+ thumbs up on the Homer Simpson thumbs up scale. Actually my impression of the database support team is that they are a pretty knowledgeable lot. If you are like me and don’t know what to look for in this file Kerry’s series is good stuff.
To get to her blog go to the ArcSight community site and either go to the Browse button at the top and select blog or there is a series of buttons on the middle right side. You do regularly check the ArcSight Protect 724 community site don’t you?
To get to her blog go to the ArcSight community site and either go to the Browse button at the top and select blog or there is a series of buttons on the middle right side. You do regularly check the ArcSight Protect 724 community site don’t you?
Subscribe to:
Posts (Atom)