SECURE AUDITING


What is Secure Auditing?

Examples of auditing include event logging (e.g. when were records accessed and by whom), and log analysis. A secure audit service records significant privacy and security related events in an event log. Component services include event logging and log analysis. Security logging facilities are expensive to offer in terms of disk storage, processing time, and the cost associated with analysing the audit trail, either manually or by special software.


Under what circumstances is Secure Auditing required?

Regular log collection is critical to understanding the nature of security incidents during an active investigation and post-mortem analysis.  Logs are also useful for establishing baselines, identifying operational trends and supporting the organisation’s internal investigations, including audit and forensic analysis.  In some cases, an effective audit logging program can be the difference between a low impact security incident which is detected before covered data is stolen or a severe data breach where attackers download large volume of covered data over a prolonged period of time.


What are the Australian Standards for Secure Auditing?

The Australian Signals Directorate (ASD) provides extensive guidance to Commonwealth entities surrounding standards to safeguard data ranging in different levels of sensitivity, from “unclassified but sensitive or official information not intended for public release” (UD), through “protected” (P), to “Top Secret” (TS). Associated security controls are outlined in the ASD’s Information Security Manual (ISM).

Whilst it is only Australian Government agencies that are required to adopt the ASD controls outlined in the ISM, the controls also provide a useful framework for non-government organisations to consider when protecting data that ranges across various levels of sensitivity. Data of this type includes Personal Health Information that contains identifying aspects which is considered to be both “sensitive”[1] and “protected”[2].

The following ASD controls are issued for agencies in protecting data that are considered “unclassified but sensitive or official information not intended for public release” (UD) or “protected” (P).

Event logging strategy

ASD Control: 0580; Revision: 4; Agencies must develop an event logging strategy covering:

  • logging facilities, including availability requirements and the reliable delivery of event logs to logging facilities
  • the list of events associated with a system or software component to be logged
  • event log protection and retention requirements.

Secure centralised logging facility

ASD Control: 1405; Revision: 0; Agencies must implement a secure centralised logging facility.

ASD Control: 1344; Revision: 1; Agencies must ensure systems are configured to save event logs to the secure centralised logging facility.

ASD Control: 0587; Revision: 2; Agencies should save event logs to the secure centralised logging facility as soon as possible after each event occurs.

ASD Control: 0988; Revision: 4; Agencies must establish an accurate time source, and use it consistently across systems to assist with the correlation of events.

ASD Control: 0582; Revision: 4; Agencies should log, at minimum, the following events for all software components:

  • all privileged operations
  • successful and failed elevation of privileges
  • security related system alerts and failures
  • user and group additions, deletions and modification to permissions
  • unauthorised access attempts to critical systems and files.

ASD Control: 1176; Revision: 1; Agencies should log the following events for any system requiring authentication:

  • logons
  • failed logon attempts

ASD Control: 0987; Revision: 5; The events listed below should be logged:

events_to_log


ASD Control: 0585; Revision: 3;
For each event logged, agencies must ensure that the logging facility records the following details, where applicable:

  • date and time of the event
  • relevant users or process
  • event description
  • success or failure of the event
  • event source e.g. application name
  • ICT equipment location/identification.

Event log protection

ASD Control: 0586; Revision: 3; Event logs must be protected from modification and unauthorised access, and whole or partial loss within the defined retention period.

ASD Control: 0989; Revision: 4; Agencies should ensure that event log data is archived in a manner that maintains its integrity.

Event log retention

ASD Control: 0859; Revision: 1; Agencies must retain event logs for a minimum of 7 years after action is completed in accordance with the NAA’s Administrative Functions Disposal Authority.

ASD Control: 0991; Revision: 3; Agencies should retain DNS and proxy logs for at least 18 months.

Event log auditing

ASD Control: 0109; Revision: 4; Agencies must develop, document and implement event log auditing requirements covering:

  • the scope of audits
  • the audit schedule
  • what constitutes a violation of information security policy
  • action to be taken when violations are detected
  • reporting requirements
  • specific responsibilities.

ASD Control: 1228; Revision: 1; Agencies should correlate events across event logs to prioritise audits and focus investigations.


[1] The Commonwealth Privacy Act (1988) http://www.oaic.gov.au/privacy/privacy-act/the-privacy-act) defines what is considered personal and sensitive information in Australia. Personal Information means information about an identified individual, or an individual who is reasonably identifiable, and of relevance to med.data, Sensitive Information includes: Information about an individual’s Racial or ethnic origin or Sexual orientation or practices; Health information; Genetic information and Biometric information.
[2] The US HIPPA Privacy Rule (http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html ) defines “protected health information” as individually identifiable health information, including identifiable demographic and other information relating to the past, present, or future physical or mental health or condition of an individual, or the provision or payment of health care to an individual that is created or received by a health care provider, health plan, employer, or health care clearinghouse. Genetic information is considered to be health information.