Applying "Getting Things Done" to IPSs

Getting Things Done, or "GTD" for short, as I've blogged about before, several times, is a method of personal organization with a focus on accomplishing tasks.  It's great for applying to email (Inbox Zero) and it's great for organization of your personal life (read some of the articles I've written before, particularly this one).

Some IDS and IPS courses and teachers will tell you to turn on everything, and log everything because that's the only way you'll find anything.  I don't disagree with that, but there are several problems with this philosophy, design, bandwidth, dropping packets, time, money, and performance.  Just to name a few.  Plus, who wants to sit there and look for everything.  Most IDS analysts I know are just trying to keep their head above water.  They want to just figure out a better way to deal with the information that is coming in, not increase the amount of information coming in.  Some people have this same problem with email, which is why I am such and advocate to Inbox Zero and GTD to learn to deal with the increased amount of information that we are being subjected to.

What if we took this same philosophy to IDS/IPS?  While this can primarily work with a Snort based device, such as Sourcefire, it can work with about anything.

Step One:  Turn everything off.
Yup.  Just as a test, create a new IPS policy and turn everything off, if you can.  (If you can't then just move on to Step 2.)  Now the focus of this exercise is only to turn on what is relavant to you, so that's what we are going to do, reset expectations.

Step Two:  Use RNA
(If you don't have RNA, obviously you can skip this step, but go ahead and read it so that you know what you are missing.)  Go to your new policy, use your RNA Recommended Rules Configuration to essentially tie the IPS policy to a certain sensors or series of sensors.  RNA Recommended Rules will take the vulnerabilities that RNA has detected in Realtime (or that it received via the Host API or Qualys or Nessus or Nmap...) and uses the information to give you suggestions about what to turn on in your network.  Use the R3 (RNA Recommended Rules) to provide you those recommendations and then go over them with the common sense test.  As you know RNA tells you what you could be vulnerable to.  Your system is "Guilty until Proven Innocent", hopefully you can take the time and tell your system what your network is not vulnerable to, but lets leave that for another day right now.  Turn on the rules that are relevant to you and your network.  Don't turn on ICMP Port Unreachable.  You'll see why in Step Five.

Step Three:  Turn on any rules that are relavant.
Want to look for Spyware?  Turn on the spyware rules.  Want to look for Chat clients?  Turn on the chat rules, etc.

Step Four:  Push the policy, and wait.
Give the new policy 24 hours if you are on a slow network, or maybe just let it run over your lunch period.  Let the policy run on your network for an acceptable amount of time, you be the judge with your common sense hat.

Step Five:  Look at your alerts.
Now, go back and look at your alerts.  Time to start cleaning out.  For each event I want you to follow a flow, I want you to decide if it is an actionable alert.  Are you going to physically do something with this event?  Are you going to report it to the Desktop security people?  Are you going to block the port at the firewall?  Update the Antivirus?  What are you going to do with the event?

If you think about the next "actionable" event you are going to do with the alert, and you decide, well, I am going to do nothing with the event, then shut the rule off.  No point in running a rule if you aren't going to react to it's logging.  Do you allow AOL Instant Messenger on your network, and your AIM rules are alerting?  What are you going to do about it?  You allow it right?  So you are going to do nothing?  Okay, then shut the rule off.

What if you don't want to shut off the rule, but only want to shut it off going to a particular machine?  Well, the suppress it based on IP.  What if you don't want to shut off a rule, but it's alerting too much?  Then threshold it.  My point is, do something.

Do that for all the events in the period that you set in Step Four.  Do this once a day, and after you do it, at the end of each time, repush your policy, then do it again the next "period".  Do this for several days.  This step, in case you haven't noticed will need to be done every day.  Every update there will be new things for you to explore and catch.  Begin at the beginning.

Step Six:  What are you going to DO now?
Now, you have a bunch of alerts you intend to do something with.  Now, do you create trouble tickets?  Do you start working with various teams?  You get the point.

Step Seven: Now that your head is above water, you can experiment
After you have done the first six steps satisfactorily to a point where you can handle your IDS and IPS, you can deal with anything that comes in.  You have a process, now you have best practices.  Now, you can turn on rules that you are interested in.  Things that you don't (or might) have to deal with.  Things that you may have had on before but never got a chance to look at.  Rules that alert on obfuscated javascript for instance.  You can go play.

Warning:  Just a word before you start this process. Warn your coworkers and boss that you are about to become much more efficient and start filing more tickets.  Because you will.

Oh, and make backups of your policies before you make changes.  In fact, create new policies based off of your old ones and work off the new ones.



Please leave comments below.