Anton Security Tip of the Week #11: But These Are OUR Logs!

by Anton Chuvakin

Following the new "tradition" of posting a security tip of the week (mentioned here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #11: But These Are OUR Logs!

A common and unfortunate situation that occurs when dealing with logs is not technical, but political: not being able to get the logs you need due to political, cultural, egotistic, or other "corporate" reasons. In this tip we will try to present a few situations and solutions for those trying to wrangle logs from whatever hostile (or ambivalent - sometimes worse!) entity at your organization and thus to break the siloed approach to log management.

So, here is the situation: a desktop system starts "behaving strangely" (as evidenced by network IDS logs, which are controlled by the security team) and security wants to take a peek at the system logs to determine how it was 0wned or infected (no centralized log collection takes place). However, the security team does not have administrator-level (or, sometimes, any) access to all desktops needed to grab security logs from a Windows PC: only the desktop division of IT department does. And they refuse! Why?

  • what if the security team finds that the intrusion happened due to our negligence?
  • what if "they" find something else wrong while looking for logs?
  • what if they crash the system and leave "us" holding the bag?
  • why should they mess with "our" systems? - we are perfectly capable of taking care of it ourselves? (not! -))
  • <fill whatever reasons you've heard!>

What can you - the security analyst or manager - do?

  • leverage your existing relationships and get the logs "informally" (obviously, doesn't scale ...)
  • remind them of the company security policy (hopefully, written by you to support such cases!)
  • [UPDATED] ask your internal auditors for help
  • use whatever desktop logs you can get a hold of (example: client anti-virus logs; other security agent)
  • report them to senior management (yours or theirs; of, if you report to the same boss, both yours and theirs)

As a side note, database administrators (DBAs) are even more famously resistant to providing log data.

Overall, the tips above might help; however, to resolve such control issues once and for all, the smart organization must deploy log management tools across the entire organization and then provide limited access to the logs to all the stakeholders on the "as needed" basis ...

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.