Is ArcSight harder to use?

Interestingly enough (if I read Google Analytics correctly) the post I created back at the beginning of November related to the question of is ArcSight hard to use was the most visited page over the last month. In fact I think it has been on or towards the top of the list since I posted it. Since I have some time on my hands I figured I would write a sort of follow up to that post. Once again I will state that my only SIEM experience is with ArcSight so maybe someone will speak up for the other SIEM engines out there and/or tell me if I’m way off base.

I still maintain asking if something is “hard”, generally speaking, often only gets you only so far. Having some context implied in your question might get you an answer closer to what you really are looking for. Is calculus hard? Depends on who you are talking to. Is calculus harder than basic algebra? Yup. Is “ArcSight” hard to use? Depends on who you are talking to. Is ArcSight harder to use than some other SIEM? Ahh now we are getting somewhere. I did have sort of an interesting thought while reading the SIEM implementation book I wrote a review of back in January (at least it was interesting to me).

SIEM Maintenance Support Costs and Returns

Anton Chuvakin recently wrote up a great blog article discussing SIEM associated costs. While it is my attention to write a longer post here to go a little more in depth on a comment I made in his article I wanted to post something quickly about a line item that probably doesn’t get a whole lot of attention after the bean counters and upper management have done their thing and papers are signed…until something breaks or there is a technical issue of one flavor or another.

Wrapping your arms around ArcSight Trends - Part 2

I ended part 1 of this Trend mini series by giving a quick and dirty way to see when your Trends start. While the report does have value it doesn’t show things like how long the Trend ran, how many insertions there were, or whether or not it was ultimately successful. A report that had all that data would be ideal. The problem, as such, is ArcSight doesn’t show when the Trend actually started in the event generated when the run ends. DeviceCustomDate1 shows the start of that run’s interval though if that is of value to you.

There is a common event key found in all three events (start x1, end x2 based on success or failure) which is found in deviceCustomString5. This appears to be a combination of epoch time + perhaps the number of actions performed by the ESM that day. So now you just need a rule to add the endTime + dCS5 to an active list and reference that list in a rule that looks for a Trend run completion event. Only…..you can’t pull the creation date field from an Active List in an AL lookup variable….and you can’t aggregate on the endTime field in order to add that to a field in an Active List (through 4.5 – dunno about 5.0 yet).

Wrapping your arms around ArcSight Trends - Part 1

Anyone else’s drive into work getting a little darker? I feel like the summer has FLOWN by. Before too long it will almost be back to a military 0’dark 30 to 0’dark 30 - at least relative to the sun; I'm not working additional hours :)

There are a number of things rattling around in my head I’d like to write about and even some things I indicated I would write about in previous posts. Work, family, summer, and the cumulative lost sleep effects from fighting through some weird sinus issue for the last 6 months have conspired to work against this goal. 60 back pokes and 22 shots in the arm have at least indicated it not being allergies. Good times.

For S&Gs I think this will be the start of a short series of posts/articles/whatever on Trends. My next post may or may not be the continuation lol. If it isn’t I WILL come back to it.

ArcSight's indexOf variable - how I love thee

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$.

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!

"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?

Hidden value of Windows 673/4769 events in your SIEM

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.

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.

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.

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)).

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?

ArcSight Use Cases and....Golf?

A couple weeks ago my wife was watching the Masters and I happened to see Phil Mickelson hit his second eagle in a row. The amazing part to me are all the vectors in play that led the ball to eventually fall into a hole with a 4.25 inch diameter: gravity, ball spin, force upon landing, multiple slopes on the green, etc.

I wondered if there was an analogy between that and ArcSight/SIEM use cases. The problem is I am not sure which side of the analogy they fall on.

On one hand the SIEM content creator could be the golfer and the badness you are trying to capture is the ball. You massage your content so that you see this, followed by that, followed by this other thing and then WHAM the trap springs and you have IDed badness – red flags go up and the alarm gong sounds. In that sense I often think of ArcSight as building a cantilevered mouse trap.

On the other hand the “bad guy” could be both the golfer and the golf ball. The content creator is really just focused on people who hit the green and doesn’t really care about how they got there. If the ball lands in the hole then things are really really bad but the key here is proximity to the hole is enough to alert on/be reviewed.

At a bigger picture level the two ways of looking at the analogy probably represent a SIEM centric vs Log review approach.