Tuesday, 13 April 2010

Auditing to Determine What Went Wrong

Unfortunately things go wrong no matter how effective the security controls are. Security is a risk based function. This means it is constrained in all cases by economic constraints. All resources are limited and the cost and benefits need to be weighted. Though we seldom admit it, even human life has a value. When a government looks at the inclusion of a control designed to reduce the loss of life in an industry, this is weighted against the other possible uses of the revenue. For instance, would $10 million annually be better spent on mine controls that save 1-10 lives a year against a one off aid grant of $50 million that would save 5000 starving refugees?

As things go wrong, we need to be able to determine why the failure occurred and to be able to decide if the occurrence was due to a control failure or a one off issue that is unexpected and cannot be reasonably forecasted. This is where logs are critical. Knowing what happened is both a means of being able to assess existing controls (with a motive to improving them) and also providing evidence of due care.

Both incident handling and forensic analysis require some form of audit trail.

Audit trails

Audit trails help to provide individual accountability for all users in the organization (including privileged users). Following an incident audit trails are useful in aiding incident response personnel in the process of reconstructing events. Correctly monitored they also provide a basic level of intrusion detection and problem identification.

An audit trail is the sum of the records created through the process of recording information concerning events and occurrences into a database or log file. Ideally, logs should not be kept on the source system. By sending logs to an alternate system, privilege users can be excluded from the ability to change or alter logs. Audit trials enable the tracking of the history of modifications, deletions, additions to data on a system allowing for accountability.

Audit logs should at a minimum record:

  • Transaction time and date
  • Who processed transaction
  • Which terminal or system was used
  • Various security events relating to transaction

Is necessary to have a policy that dictates which events are to be audited and how frequently.  This policy should also address data extraction as well as retention periods associated with the logs.

Some considerations that need to be addressed to ensure the secure operations of a logging system include:

  • Media  handling,
  •   Controls to ensure protection against alteration  or integrity loss,
  •   Controls to ensure protection against unavailability  of the logging system (both unavailability during audit and more importantly ensuring the capacity and availability to guarantee the logs are not lost),
  • Audit log backup (importance of system back-ups, frequency, availability, media, off-site storage location and protection mechanisms, quality, readability)
  • Sampling or data extraction is the practice of extracting selected data from overall data source in order to assemble a statistically significant representation of the whole.
  • Record Retention relates to regulatory requirements concerning the storage of records and data.  Records must be maintained in accordance with management policies, legal, audit and tax requirements.  For privacy reasons, employees and customers need to be made conscious of any data being held by the organization concerning them. 

Evidence of Past Incidents

Where an incident has been discovered after the fact, there may not be a great deal of evidence on hand to identify who the party was or how access to the system was obtained. The use of separate logging systems and forensic procedures will help, but the best thing is to have an effective monitoring and response strategy and the capability to discover incidents early.

No comments: