Of SIEMs and Gymnastics

In thinking about SIEMs overall relative to a thought that has been building over the last month or so I had a flashback to my cheerleading days.

Don’t laugh. For a slightly introverted guy, cheerleading at a college with a girl to guy ratio of 7:1 = win.

One of the differences between a back hand spring and a back tuck is the general ability to transfer momentum from one movement into the next. This is a lot easier with a back hand spring since the motion is front to back vs the tuck’s up and down. It is one of the main reasons why you are much more apt to see a series end in a back tuck vs start with one and transition to other things.

My problem is I learned how to do a back tuck – the finishing move – first. This translated into me not really being able to do multiple back hand springs in a series.

So, how does this relate?

If you look at the maturity models from the last post, SIEMs are toward the right side. IMO then and based on the language used by the vendors I have talked with you have use cases all about alerting on X in your environment. SIEMs are (should be?) the finishing move back tucks of the InfoSec world. Based on your environment though how are you using it? Starting at alerting and backing into monitoring? Moving from monitoring into alterting? Can your SIEM do both or maybe you need just one or the other? I really think the difference between monitoring and alerting is more than just semantics.

I’m the newb here - am I off my rocker?

The maturity of your ops

I stumbled across Anton Chuvakin’s blog some time ago and have been reading it since. Back in early February he posted a maturity scale that at the time I sort of dismissed. One of the commenters posted a link to a similar, though more verbose, article they had written back in 2008.

Anton Chuvaki’s: here
Raffael Marty’s: here

(seriously…read them!)

What I had missed in the simplicity of Anton’s graph was all the soft processes, tuning, and trial and error behind each of the steps. I liken it to a 10 speed bike. You shift up too many gears and if you aren’t already going fast enough you bog down. Of course the opposite could also happen where you shift down too many gears and while you are peddling your heart out you really aren’t moving forward (the whole activity vs accomplishment issue). A lot of that is perspective and proximity to the tool at hand I suppose.

I started to write a couple other things but maybe they will show up in future posts. At any rate, the purpose of this post was really just to point people to those other two articles lol.

Query Viewers as a replacement for Active Channels?

Could you use a Query Viewer to (generically speaking) replace some of the initial visibility you get from an Active Channel. The TLDR summary is below.

As the primary content creator for our ArcSight install and since my ArcSight users don’t always have their consoles open, I often think about how best to get them to actionable data and to the point where they can dynamically interact with it in the shortest amount of time. You generally have data in Active Channels and data in Dashboards – with a sort of gulf between them. 4.5 brought an interesting feature with Query Viewers. Among other uses is the ability to tie multiple queries into a QV. Most often we use this for linking multiple buckets (Trends) of data. I see Bob’s computer/IP doing something in this bucket and with a simple right click and investigate I can see if that same IP shows up in another bucket.

The more I use ACs now though, the more I want them to act or at least have the functionality of QV. To that end I went about creating a QV that pulled 3 hours worth of events and didn’t update as a first pass at a replacement mechanism for an AC. My thought was while I would lose some of the extensibility I could at least link a number of the “buckets” I wanted to have visibility into.

TLDR Summary

I found the following issues impeded the overall goal. Others could be added to the list but then you get to the point where you might as well use an AC anyway given all that you CAN do with them.
• When you close a QV investigation panel you aren’t returned to your initial DB/QV – you are taken to the last tab in the Navigator pane on the right. This is kinda a pain if you are trying to do a quick drilldown and then get back to what you are looking at.
• QVs don’t have a horizontal scroll bar. This becomes an issue if you are trying to resize fields with long strings or if you have more than about 5 fields you want to pull up (note last bullet)
• You can’t adjust the relative position of QV drilldowns. The first one you put in is the first on the list etc. Is a pain if after you throw in a couple and want to organize it.
• The real kicker is if you have more fields in your QV then you are initially showing if you go to add them to the display while you are viewing the QV the console will lock up. At least that is what mine does. For example, I will always want to see fields like source/dest IP. I sometimes want to see zone name. My thought was to add the zone names to the QV but not initially display them.

It will be interesting to see what happens to QV in the next installment of the ESM. Hopefully some of these issues will be addressed.

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.

First Post

I entered both the InfoSec and SIEM realm about 18 months ago when I made a lateral move to be the primary administrator, innovator, and content creator for the ArcSight software we had just purchased. While I came to the table with a decent mix of IT skills they were mostly based around close desktop and network support though in a variety of environments. I have spent a lot of time searching the Interwebs for SIEM-esque material to help get over the learning curve of all that goes into enterprise level InfoSec and then turn around and create actionable ArcSight content. While I found a number of blogs and the odd resource here and there, at the end of the day there isn’t a whole lot of boiled down information out there for folks – at least with my background.

So what’s this blog about? While I’m not a SIEM expert I’d like to think I have something to bring to the bigger conversation. The other part of this is going through the mental gymnastics of converting thoughts to text. What remains to be seen is how long this little experiment will last. I have some high hopes...though I have to also learn how to navigate this blogging thingamajig