Malos Ojos Security Blog

Archive for September, 2012

OK, maybe you should do more than tap your network before an incident…

by on Sep.19, 2012, under General

In looking back at the last post about tapping your network prior an incident I thought to myself, why did I stop there…or more appropriately, why was I focused on having the right infrastructure in place?  Perhaps it was out of frustration of showing up to a client and wondering why it was so difficult to start quickly monitoring the environment to get a handle on the issue we may, or may not, be dealing with.  But when I thought about it what I really needed was a Delorean with a flux capacitor and a crazy Doc Brown of my own so I can travel back in time (no, I don’t own a vest jacket or skateboard but may on occasion rock some Huey).  I don’t have a time machine and can’t go back in time, but what I can do is make some recommendations that we start capturing information that may be useful in an incident response PRIOR to one happening.  I don’t mean to dismiss the ability to rapidly scale up your monitoring efforts during a response, even if that means dropping new tools into the environment or calling on 3rd parties to assist, but would be doing an injustice if I didn’t discuss what you should be collecting today.

Normally I’d be frustrated with myself for recommending that you collect information, logs, data, etc. and then do nothing with them.  But, is that really a bad thing?  I thought back to when I started at the law firm and many years ago when I asked what we monitored I was told we had network perimeter logs and that they were being sent to an MSSP for storage.  Were we doing anything with these logs?  No.  Was the MSSP doing “some science” to them and telling us bad things may have been happening?  No.  So, at first I questioned the value, and sanity, of the decision to capture but do nothing with our information.  But the more I thought about it the more I understood that IF something had happened I would/may have the information I need to start my investigation.  Forensics guys may know this as the concept of the “order of volatility”, or how quickly something is no longer available for analysis.  I’d say besides system memory that network connections would be very high up on that list.  And if I weren’t at least capturing and storing these somewhere then they would be lost in the past because of their volatility.  So, it isn’t that bad to just collect data, just in case.

I’d also like to temper the aspirations of folks who want to run out and log everything for the sake of logging everything.  What I’d much rather see is that your logging and data collection be founded on sound principles.  What you choose to focus on should be based on your risk, or what you’re trying to protect/prevent, and I hope to highlight some of this in the rest of this post.  As an example, if you are logging successful authentications, or access to data it should be focused on your most valuable information.  This will, for obvious reasons, vary from organization to organization.  A manufacturing company is more likely trying to protect formulas, R&D data, plant specifications and not medical records like an organization in healthcare would.  OK, on to the major areas of logging to focus on, or at least something to consider:

Perimeter/Network  Systems

  • Firewalls
  • Web proxies
  • Routers/switches (netflow)


  • Access to sensitive data via applications
  • Database administrative actions/bulk changes
  • Administrative access to DBs, applications, and systems (focus on critical systems first)
  • SharePoint and other data repository access
  • Email systems

Security Controls

  • AV, Anti-malware, and end-point controls
  • File integrity monitoring systems
  • DLP and data loss prevention tools

Contextual Information

  • Identity management systems and access governance systems
  • Vulnerability information
  • Operational data such as configuration information and process monitoring

And as Appendix A.2.1 of NIST 800-86 says, have a process to collect the data that is repeatable and be proactive in collecting data – be aware of the range of sources and application sources of this information.

While I realize the recommendations of this post are rather remedial, I still find organizations who haven’t put the right level of thought into what they log and why.  Basically, the recommendation I may make is to first understand what you may log today, identify gaps in the current set of logs and remediate as necessary, and design your future state around a solid process for what you plan to collect and what you plan to do with it.  More to come…


3 Comments more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

Links for tools and such...