Security, et al

I’ve perused the National Institute of Standards and Technology draft Guide to Computer Security Log Management (Special Publication 800-92) and have some thoughts to share. (You can find the guide at http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf.

Valuable points in the guide:

The guide asserts that security log management is required by regulatory compliance including SOX, HIPAA, GLBA and especially FISMA. In fact the guide maps security log management to specific requriements in FISMA. Therefore this document may be a real help to those trying to get funds approved for security log management. If you are already monitoring, reporting and archiving with your security logs the guide will help you demonstrate compliance to auditors and examiners.

The document also repeatedly makes the case that organizations need to provide tools and training to IT staff tasked with security log management.

Section 2.2 The Need for Log Management does a good job of highlighting the manifold benefits of log management above and beyond compliance.

Where the guide falls short:

The guide is a bit too theoretical and general for me. I realize it is intended to be technology agnostic but I think it could avoid getting product specific but still provide more precise guidance on what types of activity should be monitored and what to do about it. Some of the log interpretation techniques are a bit simplistic.

The guide completely omits any treatment of one of the most important benefits and issues associated with computer security log management: administrator accountability. In this age of increased requirements for building a "controlled" organization, little is being done to provide any controls over those of us with unlimited administrator authority. After due diligence in the hiring process the only real control available for administrators is a high-integrity audit trail of their actions. The only way to provide that is with a secure log management infrastructure that is logically and physically separate from operational administrators. The monitoring and report analysis must be performed by non-operational IS security staff. This has significant ramifications on the architecture of your log management infrastructure and requires seperation of duty among staff. The guide discusses security of the log management infrastructure and store and identifies roles associated with log management but makes no mention of separation of duty nor any acknowledgement of using security logs to enforce accountability with administrators.

All things considered I think this draft is a good piece of work and will be highly valuable despite the somewhat ivory tower tone. However the guide does a major disservice if it fails to give proper treatment to the irreplaceable function of security logs as a control over administrative abuse and the impact that makes on the design and function of the security log management.