When we first were wading through the initial honeymoon period of having ArcSight and creating content we were often stymied by trying to compare two strings. This was back in the “olden” days of 4.0 when you couldn’t just throw 2 fields into the conditions editor like you can in 4.5 (field1 = field2; field1 != field2). What about instances when you wanted to compare two fields where something like a computer name in field1 was domain\computer name and the other was COMPUTERNAME$.
Wednesday, June 23, 2010
Wednesday, June 16, 2010
Monitor vs Alert
Several weeks ago now I took some money out of the ATM and the bottom of the transaction receipt showed a balance that seemed a bit low to me. I brought it up to my wife at lunch and watched her mentally parse a multitude of variables to include the day of the month, what bills had been paid, and the times and amounts of money that move out of checking and into sub accounts. About 5 seconds later she said the amount sounded about right. This is the difference between monitoring and alerting.
Don't get me wrong. My wife isn't the type that pulls up the account information every day to check the ebb and flow of cash but by doing the bills and interacting with the accounts she had a familiarity for how and when the money does flow. The trick in my mind with a SIEM is to figure out the balance for both types of actions. Not only do you have to balance how and where analysts get data but also things like how much should be simply monitored vs alerted on, if you create reports is there too much or too little data in them to be actionable, if the report is on a particular data source can you give it some historical context or cross reference it against other data sources.
To many of those ends my new favorite report template in ArcSight is one that comes out of the box. 4 charts on one page and then a table. Most of the daily reports we have been creating were of the one table variety with a level of detail in the information - source, destinations, times, counts, etc. While we humans are good at visually picking out patterns and nuance things out of spreadsheets putting what amounts to a rolled up summary of top information with the multiple charts at the top of the report is great. Now within the report not only have you framed aspects of the data but since more detailed information is in the table section readers can pull out an IP/user name/whatever from the top page and then search for it within the report.
Don't get me wrong. My wife isn't the type that pulls up the account information every day to check the ebb and flow of cash but by doing the bills and interacting with the accounts she had a familiarity for how and when the money does flow. The trick in my mind with a SIEM is to figure out the balance for both types of actions. Not only do you have to balance how and where analysts get data but also things like how much should be simply monitored vs alerted on, if you create reports is there too much or too little data in them to be actionable, if the report is on a particular data source can you give it some historical context or cross reference it against other data sources.
To many of those ends my new favorite report template in ArcSight is one that comes out of the box. 4 charts on one page and then a table. Most of the daily reports we have been creating were of the one table variety with a level of detail in the information - source, destinations, times, counts, etc. While we humans are good at visually picking out patterns and nuance things out of spreadsheets putting what amounts to a rolled up summary of top information with the multiple charts at the top of the report is great. Now within the report not only have you framed aspects of the data but since more detailed information is in the table section readers can pull out an IP/user name/whatever from the top page and then search for it within the report.
Thursday, June 10, 2010
Converting Windows failure codes to something readable
I posted this in the content section on the ArcSight user forums (and if you are ArcSight client you are reading them right...?) but I haven't been able to take anything with antihisimine for the last week and won't be able to until after my alergy test on Monday so feeling mis-er-a-ble.
Hopefully your SIEM is capturing the reason/status/substatus codes when it comes to failed Windows login events. In ArcSight that data is generally found in deviceCustomString4. We recently had to create a series of reports that were being passed to some folks outside the more technical group who would normally just look at the codes.
To make the reports more readable I did a copy/paste job from the GREAT resource over at Ultimate Windows Security - the event encyclopedia. Then created an active list with 2 string fields making sure to index the one with the code. You do that so in your report query you can use the variable allowing you to grab a value from an active list basically doing a join. Since this calls for a string comparison with letters I chose to make the data in the AL lower case and then use another variable to take the data from customString4 and make it lower case as well. Then in your query field selection if you look under the variable section you should see BOTH fields from the Active List. Select the normal fields you want and include the unindexed field from the active list and just clean it up using the alias field in the report.
Worked like a champ though given my current state it might read like a train wreck.
Hopefully your SIEM is capturing the reason/status/substatus codes when it comes to failed Windows login events. In ArcSight that data is generally found in deviceCustomString4. We recently had to create a series of reports that were being passed to some folks outside the more technical group who would normally just look at the codes.
To make the reports more readable I did a copy/paste job from the GREAT resource over at Ultimate Windows Security - the event encyclopedia. Then created an active list with 2 string fields making sure to index the one with the code. You do that so in your report query you can use the variable allowing you to grab a value from an active list basically doing a join. Since this calls for a string comparison with letters I chose to make the data in the AL lower case and then use another variable to take the data from customString4 and make it lower case as well. Then in your query field selection if you look under the variable section you should see BOTH fields from the Active List. Select the normal fields you want and include the unindexed field from the active list and just clean it up using the alias field in the report.
Worked like a champ though given my current state it might read like a train wreck.
Thursday, June 3, 2010
Arcsight '10 User Conference - Presentation Idea
Sadly its not looking good for the presentation idea I submitted for the ArcSight '10 User Conference. Don't get me wrong - I know I am a little fish in a big pond but I really think there is some value. How much value there is relative to other items on the plate is another topic and one ultimately they will decide.
What I had hoped to talk about was the framework/system I designed to let anomalous activity "bubble up" to the surface without elaborate and extensive use cases. Anomalous activity and systems almost in a sense will triage themselves. While many large, 24x7 SOC operations probably have people watching events scroll by and react in near real time there are many SMB types out there that simply can't sustain that type of op / op tempo. Of the few companies and individuals I have interacted with who also use ArcSight or another SIEM/LM tend to fall into the category where if they don't have a 24x7 shop they spit out daily reports that are reviewed in the morning w/o really leveraging all that their SIEM can provide. There aren't a whole lot who have comfortably found the middle ground. Granted my data set for that observation is fairly small.
Don't get me wrong - this isn't a silver bullet or an especially magical use of the product. It does however provide an extensible framework that will alert users and then provides quick access to pertinent live and historically siloed data when they open the ESM console without having to rout around.
Of course one of my hidden agendas was for other experts to tell me how much better their systems are. That would give me additional insight and help me add to and refine my own. I also hoped it would spark discussion along the lines of best SIEM/ArcSight use for SMB types.
Update: I gave up hope too soon. ArcSight has accepted the presentation idea and asked me to run one of the breakout sessions. Am excited!
What I had hoped to talk about was the framework/system I designed to let anomalous activity "bubble up" to the surface without elaborate and extensive use cases. Anomalous activity and systems almost in a sense will triage themselves. While many large, 24x7 SOC operations probably have people watching events scroll by and react in near real time there are many SMB types out there that simply can't sustain that type of op / op tempo. Of the few companies and individuals I have interacted with who also use ArcSight or another SIEM/LM tend to fall into the category where if they don't have a 24x7 shop they spit out daily reports that are reviewed in the morning w/o really leveraging all that their SIEM can provide. There aren't a whole lot who have comfortably found the middle ground. Granted my data set for that observation is fairly small.
Don't get me wrong - this isn't a silver bullet or an especially magical use of the product. It does however provide an extensible framework that will alert users and then provides quick access to pertinent live and historically siloed data when they open the ESM console without having to rout around.
Of course one of my hidden agendas was for other experts to tell me how much better their systems are. That would give me additional insight and help me add to and refine my own. I also hoped it would spark discussion along the lines of best SIEM/ArcSight use for SMB types.
Update: I gave up hope too soon. ArcSight has accepted the presentation idea and asked me to run one of the breakout sessions. Am excited!
Wednesday, June 2, 2010
"Good enough" ArcSight/Use Cases
There have been a couple articles that have popped up here and there that seem to have had their base in Duncan Hoopes’ FUDsec article relative to things being “good enough” – well if not their base then a similar theme.
Last week I took some time to drill into several Win2k8 failed login events and how ArcSight was parsing them. For event 4625 (which replaced 10 Win2k3 events) I was surprised to find a rather key piece of data - sub status code – stuck in a field you can’t query on and isn’t consistent with where the same data was parsed and dumped in the corresponding Win2k3 events. What is key about these codes is it lets the reader know WHAT the condition was surrounding this particular login failure – user account doesn’t exist, account was locked out, account is currently disabled, etc. It would be easy to question why hasn’t ArcSight “fixed” this issue. The better thing to ask though to me is why hasn’t anyone over the last 2 years plus that the OS been out actually brought the issue up to ArcSight in the first place?
Maybe I look at our service contract different than others and honestly you can make an override relatively easy; bypass the issue and move on. Why not bring it up and try to get the thing fixed at a macro level….unless people don’t have content that involves that data and aren’t looking at it anyway? Is this a case of simply getting the ball on the green and wrapping your arms around just the event is good enough? Don’t get me wrong I don’t have a ton of content built around each of the sub messages but I do throw them into the Trend that is tracking failed logins where they eventually show up in multiple reports. I mean wouldn’t you want to differentiate between 600 failed login attempts but that they were because some idiot used his domain credentials on a service account and didn’t change the password vs 600 failed login attempts for an account that didn’t exist?
Last week I took some time to drill into several Win2k8 failed login events and how ArcSight was parsing them. For event 4625 (which replaced 10 Win2k3 events) I was surprised to find a rather key piece of data - sub status code – stuck in a field you can’t query on and isn’t consistent with where the same data was parsed and dumped in the corresponding Win2k3 events. What is key about these codes is it lets the reader know WHAT the condition was surrounding this particular login failure – user account doesn’t exist, account was locked out, account is currently disabled, etc. It would be easy to question why hasn’t ArcSight “fixed” this issue. The better thing to ask though to me is why hasn’t anyone over the last 2 years plus that the OS been out actually brought the issue up to ArcSight in the first place?
Maybe I look at our service contract different than others and honestly you can make an override relatively easy; bypass the issue and move on. Why not bring it up and try to get the thing fixed at a macro level….unless people don’t have content that involves that data and aren’t looking at it anyway? Is this a case of simply getting the ball on the green and wrapping your arms around just the event is good enough? Don’t get me wrong I don’t have a ton of content built around each of the sub messages but I do throw them into the Trend that is tracking failed logins where they eventually show up in multiple reports. I mean wouldn’t you want to differentiate between 600 failed login attempts but that they were because some idiot used his domain credentials on a service account and didn’t change the password vs 600 failed login attempts for an account that didn’t exist?
Subscribe to:
Posts (Atom)