How Much Logging, Monitoring and Alerting?

Organisations tend to do far too little or far too much web site logging, monitoring and alerting. And thus, meaningful reporting becomes infeasible.

I took the following photograph at the Brunswick residential and shopping centre in Bloomsbury, London. I pity the person who has to work out which fire alarm bell is ringing and which part of the building it relates to.

Web sites and web applications I review usually fall into one of three monitoring classes:

• None
• Marketing related only
• All the bells and whistles.

The marketing-related aspects usually include server log analysis including visitor analytics, search engine monitoring, click-through rates, conversion rates and sometimes availability monitoring. Security aspects are normally never considered, even though these affect customer trust and the ability for organisations to protect and monitor their own and their customer's data.

A few web sites have detailed systems monitoring and alerting, watching for reputational aspects, sales process monitoring, unauthorised file and configuration change monitoring, successful and failed log ins, error conditions, usage patterns, fraud identification, network intrusion detection, computer systems log analysis, and so on.

The latter type often have too much monitoring, and alerts begin to be disabled. The level of security monitoring, alerting and reporting needs to be set during the requirements and design stage of projects, and should be proportional to the information security risks. There is no one size fits all solution, and a blind checklist approach can lead to un-necessary "alarm fog" that means real problems go undetected.

I will list some of the type of things worth monitoring for typical types of web applications in a subsequent post on security logging.

Update 20th February 2009: See subsequent post Security Logging Requirements.