Pages

Friday, August 27

Why I haven't written

I haven't been writing recently.  Been kinda busy.

For those of you that haven't heard, my wife gave birth to our baby boy last Wednesday.

His name is Paul Esler.

Thursday, August 12

Start with a cage containing five monkeys.

Start with a cage containing five monkeys.


Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water. After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water.


Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.
Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked. Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.
After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana.

Why not?


Because as far as they know that's the way it's always been done around here.
And that, my friends, is how policy begins.
-- Don't know the original author or where this came from, but it was posted on a Listserv I belong to, and I thought it was great. If anyone knows where this originally came from, please post in the comments so I can attribute it.
However, I think this really exemplifies some points that I've said for years. Just because "That's the way it's always been" doesn't mean that's the way it always needs to be done. Examine the status quo, and if you can try and make it better, do so.

Thursday, August 5

Security for the SMB makes sense, by Jason Brvenik

Security for the SMB makes sense.



I was off reading some older articles written on a couple of blogs that I follow looking for something in particular. Well, I never did find what i was looking for (in regards to the article itself), but I did reread this post by Jason Brvenik over at Snort.org.

This is a great article in response to another article about why small business shouldn't invest in IPS (which is a crazy view). Jason really does a nice job of laying out the reasons why its important. Definitely worth the read, or reread if you've seen it before.

Google Wave, it's dead. So sad.

In case you haven't heard.


So, on Google's "Official" Blog (which one guys?  You have so many!) they announced yesterday that they are pulling the plug on Google Wave.

So sad.


I think Wave had some really good potential, but I'll say it here, as I have said it since the beginning, Wave would have never caught on unless it replaced something else.  Wave was pretty neat, it was like a Wiki, Google Docs, Gmail, Gtalk, and god-knows-what-else all rolled into one.  It worked, it worked pretty well.  But it didn't replace anything for anyone.  It was a "and also" technology.

Let's Hope


Google rolls some of the technology they developed for Wave into the rest of their products.  For instance, simultaneous typing. That could be useful in Gmail and Gtalk.

I think the collaboration-on-documents idea was great.  That would be most useful in a corporate setting.  I would have loved to use it at Sourcefire.

Design


Some of their design ideas were great. Look at the navigation window over here on the right.  Look at the shading around the box, Look at the title bar (how it can be collapsed).  Look at the "+" button.  It all looks very nice.  It has icons, it has lots of html5 being used to shade and render it.  The drop shadow, the links.  Every box on Google Wave seemed to be more carefully thought out and precise.  The GUI was a wonderful idea and one couldn't very well argue with that.  The scroll bar (not pictured here) was nice to use.  Every pane was separated into it's own individual boxes.  You could tell there was a difference in between all of them.  Take a look at this post over at lifehacker.org: http://lifehacker.com/5400644/google-wave-look-and-feel-coming-to-gmail-other-google-apps.  I don't where they got that screenshot, but that's the way that Gmail should look!  Look at the boxes, the drop shadows, the shading.  The whole look and feel reeks less of a "Web App" and more of a Desktop app.  It has polish.  It has great design.  If you take a look at a screenshot of Gmail, from my own inbox, you will see what I am talking about.  Look at the panes here.  Look at the navigation windows.  This is not good GUI design in a web app, functional?  Yes.  Good looking and easier to navigate? No.

If Gmail wants to act like they are a desktop email replacement tool, they need to stop looking like "Mutt" and start looking like Wave.

In a way, I'm kind of sad to see Wave go.  There was a lot of really great ideas there.  I enjoyed using it.

However, I can totally see how it didn't work for some people.  It was confusing.  People didn't understand how it was different from anything else they used.  As I said, it didn't replace anything they already had, it didn't have a "need".  When the iPhone was invented people immediately saw the "need" for it.  A phone that is brilliantly easy to use.  It also replaced things.  It replaced their phone, it replaced their blackberry.  It was simple.

Wave wasn't simple.  It didn't replace anything, and that is why it failed.  People don't need another email system.  In fact, they need less.

Tuesday, August 3

Now that I have these IDS events, now what?

In my full-time job I work for Sourcefire, as a Sourcefire and Snort Professional Services Consultant.  I deal with a different customer every week (sometimes every day), and with each customer comes a separate set of IDS events.  Customers will often tell me "this network is unlike any you've ever seen before", and for the most part, they are right.  While all networks consist of servers, desktops, switches, routers, firewalls, antivirus, and even IDSes, all networks are essentially the same in that respect.  However, each of them pose their own unique set up and vulnerability attack-landscape.  Each network is unique in this way, it doesn't matter if you have 300,000 users on your network or 10.  All that does is make your life as a security person more difficult, this is essentially a number.  That number may increase lots of things, people hired to handle them, number of sensors needed, the amount of bandwidth needed, etc.

So, in dealing with the hundreds, perhaps hundreds of thousands, perhaps millions of IDS events that I see during the day on different networks, how do I deal with them?  How can I get into a customer engagement and turn 400,000 events a day into 100?   How do I help my customers deal with this?

My answer is: One at a time.

How do I do it?  Well, I take the same fundamentals as I have applied to Getting Things Done and Inbox Zero (mostly the latter) to IDS events.  In other words, for each IDS or IPS event, there is at least one (maybe multiple) outcome(s) to that event.  While yes, that may seem redundant, (and it is) my point in saying that is that there should always be an outcome to any IDS event.  It shouldn't just sit.  You shouldn't just be "moving events to archive".

You can kind of think this as a flow chart.

First -> Look at the event, let's use this event as an example:

POLICY Adobe FLV file transfer

Analyze it in context, what does this event mean?  It means someone is watching a flash video on the internet.  Okay, big deal right?  Is that allowed by policy?  Look at the packet data, is it from youtube?  Is watching YouTube from the corporate network allowed?  Perhaps if you are on a Government network, this isn't allowed, okay, so what next?  Do I need to look at the flows around it recorded by Netflow or RNA?  Do I need to look at my SIEM tool?

Second, Now comes where you ask "what relevancy does this have to my network?"  If it's a Sourcefire protected network (read: not Snort) then you might have RNA to help you perform this function.  How is the impact rating on the alert?  Is it high?  Is the end host vulnerable to this "exploit"?  The impact rating for the above event is probably pretty high, since every browser on every OS (for the most part) can watch a flash video.  How old is the rule or alert?  Does it cover a CVE that was patched in 2002?

Now that we know what the event is, and what relevancy it has to our network, what are we going to do about it?  Well, I view this has having about four possible outcomes.  Of course, this is related to Snort, so your IPS may vary.  But all IPSes get better with tuning, so...

  1. If you are in IPS mode, do you want to block it or not?

  2. Threshold or Surpress?

  3. Edit the rule manually?

  4. Shut the rule off?

  5. Does it provide relevance to other rules?

  6. DO something about the alert.


1.  Set the rule to drop.


This only works if you are in IPS mode, should you change the rule to drop?  Do you want the traffic to go into the big bit bucket in the sky?  Prevent that FLV file from being downloaded?  Prevent that PDF from being downloaded, prevent that newest browser exploit?  If you are in IPS mode, this is your second question after you analyze the event.

2. Threshold or Suppress?


Thresholding in Snort essentially means you still want the rule to alert, but not as much.  Or not until a certain threshold is reached (or both).  Suppressing means you want to turn off alerting to a certain IP or CIDR block.  Say for instance an SNMP alert going to your HP OpenView server.  Legit traffic, so tune it out.

3. Edit the rule.


Probably something you want to stay away from as much as possible, unless you editing your own rules.  But it's always an option to edit the rule manually to reduce false positives.

4. Turn the rule off.


Is the rule out of date?  Do none of the above apply?  Has it no relevance to your network?  For instance, using our above example, if watching flash videos is allowed on the network, and you don't want to track to see if people are doing that kind of thing, then shut the rule off.  If you aren't going to use the final step in this process (DO SOMETHING) then do you need the rule?

5.  Is the rule providing you contextually aware information?


Some rules will make no sense on their own, but they may provide a contextual awareness to other rules.  For instance, if there was a rule to watch for vulnerabilities within a certain flash video file format to exploit older versions of the flash player, that rule coupled with the above example, may provide better contextually aware alerts.  You know the video was bad, but now you can refer back to the above example and perhaps see where the alert came from.  Kind of a bad example, because you could do it either way, but hopefully you grasp my point.

6. DO SOMETHING.


This requires you to go mitigate the problem.  Whether that be to "file a ticket" for your helpdesk to clean off spyware, clean up a botnet, perhaps you'll need to pull forensics on the host machine, perhaps you'll need to pull web proxy logs to get better awareness.  But this is the step where you actually have to use the alerts generated by your IDS to do your job.  Find the bad guy, eradicate the badness from the network, and move onto the next alert.  After all, that's the point of having an IDS or IPS right?

Following these simple steps should allow you to have a greater awareness of the alerts on the network, and perhaps actually do something about them.  Getting an IDS alert and then "moving it to archive" or "marking it as reviewed" is doing nothing.  Following the above ACTION steps should give you a more streamlined IDS or IPS, and then only cause your system to alerts when you need to conduct step 6, above.  DO SOMETHING.

Monday, August 2

New Digg Interface Invites

I have a couple posts brewing in my head that I need to get down on paper, but in the meantime, I have 5 invites for the new Digg.com interface if anyone wants them.

First five people to send me their email address get them.