« Logging Glossary: Log Timestamp | Main | Top 11 Reasons to Look at Your Logs »
Anton Logging Tip of the Day #11: But These Are OUR Logs!
Following the new "tradition" of posting tips of the day (mentioned here, 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 Logging 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 or IPS logs, which are controlled by the security team) and security wants to take a peek at the system logs to determine how it was compromised or infected. At the same time, no centralized log collection takes place. The security team does not have administrator-level (or, sometimes, any) access to all desktops needed to grab security logs from Windows PCs: 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!)
- ask your internal auditors for help; IT might "fear" them more than they fear the security team (as suggested by one of the readers here)
- 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, while the tips above might help, the only way to truly to resolve such control issues is to 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 ...
BTW, I am tagging all the tips on my del.icio.us feed. Here is the link: All Tips of the Day.
Posted July 02, 2007 in | Permalink
TrackBack
TrackBack URL for this entry:
http://www.loglogic.com/mt/mt-tb.cgi/217
June 2008
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
Categories
Archives
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005