Security Ripcord

Reviewing my daily blog hits I came across another interesting search that directed somebody here.  “what a firewall and ids can tell you about an incident” Although I sarcastically commented on my Interesting Search Keywords page “That you need to turn on more logging” I have to admit that I meant it.  Firewalls and Intrusion Detection Systems will only provide the analyst (be it a professional incident responder or a system/network administrator) with a limited amount of information.  The real meat of an intrusion is going to come from the coalition of data from disparate logging resources.

• Firewall logs, depending on how logging is configured, is going to tell you about the connection attempts in and out of the network.  Most likely you are going to see the traffic that failed.  If the firewall has proxy capabilities you will be provided with specifics about the proxied traffic, also most likely the stuff that failed.  Depending on where the firewall is located within your infrastructure will determine how much noise will be present within the logs.  Internet facing firewalls will have a lot of noise and will therefore probably have failed logging toned down.  Internal firewalls, however, should not see much failed traffic.  So anything that shows up could protentially be interesting.  Comparing these logs could also be affective in determining the origin of specific attacks, were they intitiated internally or externally.
• IDS logs could be helpful or noisy as well.  These really depend on how well the security or network administrator has maintained the IDS sensors and where they have been placed.  Having every signature and capability turned on will lead to quite a bit of false positives to sort through.  But too much tweaking could leave administrators oblivious to reconnaissance efforts.  IDSes are great for determining if attackers are using known attack vectors to gain a beachhead within an environment.  But, like anti-virus engines, they are only as good as their signatures no matter how well the community and commercial companies stay on top of it.  I’m willing to bet it is going to be a long time before we see signatures for Clickjacking (BTW, Jeremiah Grossman recommends this article).
• These points aside, having the logs from both of these devices provides you with the best information of all.  What is the normal operational state of communications within the environment? There are no if, ands, or buts about it.  If you do not know what can be considered normal there is no way to asertain what is abnormal.  Having good logs from these devices will enable you to pin-point a specific time period that reconnaissance or even an attack occurred.  This could help you narrow your window of other investigation items be it system logs, file assess or write times, or registry modifications.

I said it on Twitter the other day, ” Logs are interesting, logs are fun, logs should be done by EVERYONE…..get to logging!!!” and I meant it.  It is very hard to investigate an intrusion or incident if there are no logs to review.  Bringing together the firewall logs, IDS logs, application logs, operating system logs, and anything else there is provides the foundation from which to build the response.  Without them you will just be staring at each other wondering what to do next.  And I’ll tell you what to do if you don’t have any logs.  Contain the incident, investigate as much as you can, return to a good operational state, disclose if you have to disclose, and TURN ON LOGGING.

Go forth and do good things,

Don C. Weber

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.