OCIO/G4.23
Government guideline on cyber security
ISMF Guideline 23
Monitoring and event logs
BACKGROUND
Security event logging and monitoring involves the capturing and examining events that may have
an impact on the confidentiality, integrity or availability of information assets. Well-defined
procedures and practices are the prerequisite for identifying and handling these events to protect
agency information assets. In conjunction with appropriate tools, these can assist in detecting
attempted and actual security violations.
Event logs are records of current and past management, operational and technical information
systems events or user activities. They may have several functions, each devoted to a particular
activity type, such as user access or system status.
Log monitoring and analysis is an examination of activity to help accomplish several securityrelated objectives, including individual accountability, reconstruction of information security related
events, intrusion detection, and problem analysis. It can facilitate establishing the records needed
for security auditing and forensic analysis and/or investigations.
This guideline will assist agencies in establishing and integrating appropriate logging and
monitoring of information security events with organisational event monitoring and cyber security
management practices. This guideline supports implementation of ISMF Policy Statement 23.
GUIDANCE
Agencies are responsible for developing and implementing policies and procedures to ensure that
their system or resources have not been harmed by hackers, insiders, or technical , and that
exploitation of security vulnerabilities are prevented or managed in a timely fashion.
Such policies and procedures will need to account for the unique business environment and risk
profile that has been determined by each business. What is considered ‘acceptable practice’ in
one agency may not necessarily be considered acceptable in a different business due to the
sensitivity of information assets involved and/or the findings of a business impact assessment
against identified risks.
Agencies are responsible for developing and implementing procedures in accordance with the
requirements of the:


Protective Security Management Framework [PSMF]
Information Security Management Framework [ISMF]
ISMF Guideline 23
This guideline assists Business Owners and Responsible Parties (as defined in the ISMF) in
developing their practices and procedures for undertaking adequate logging and monitoring of
user, system and activity events.
PRE-REQUISITE DOCUMENTS
The ISMF should be read in conjunction with this guideline. Implementing the guidance in this
document may assist in meeting the requirements contained in the following ISMF Policy
Statements:

ISMF Policy Statement 23 (Monitoring and event logs)

ISMF Policy Statement 19 (Information back-up, archival and retrieval)

Policy Statement 33 (Cryptographic requirements)
The predominant ISMF standards relating to security event logging and monitoring are ISMF
Standards 71, 72, 73, 74 and 75 respectively.
EVENT LOGGING AND MONITORING
Event logging is the creation of a record set that documents a sequence of specific operations,
events or other activities that may have affected the confidentiality, integrity and/or availability of
information and associated assets.
It can help raise the security posture by increasing accountability for all user actions, thereby
improving the chances that malicious behaviour and other security-relevant activity can be
prevented and detected..
Event monitoring can be used to identify events while they are occurring, or reconstruct them
afterwards. Examples include the process of identifying attempts to penetrate a system and gain
unauthorized access. Although often thought of as "after the fact", monitoring logs in real time as
they are created allows activities such as intrusions to be detected. Real-time intrusion detection is
primarily aimed at outsiders attempting to gain unauthorized access to the system. It may also be
used to detect changes in the system's performance indicative of an attack resulting from
malicious code. There may be difficulties in implementing real-time monitoring, including
unacceptable system performance.
Through event log analysis, damage can be more easily contained and assessed by reviewing
system activity to pinpoint how, when, and why normal operations ceased. After-the-fact
identification may indicate that unauthorized access was attempted (or was successful). Attention
can then be given to damage assessment or reviewing controls that were attacked. Responsible
Parties need to recognise the human dimension of event logging, in that event logs are only useful
in planning, prevention and response activities if the information is fit for purpose and is being
analysed for patterns, trends and suspicious or significant events.
Government guideline on cyber security
Logging and Monitoring v1.0
Page 2 of 7
ISMF Guideline 23
Table 1 – Event logging and monitoring
Applicability
Guidance
Responsible Parties should implement procedures concerning the
monitoring of significant information asset events which are
commensurate to their confidentiality, integrity and availability
requirements, and established through a risk-based approach for
assessing the level of monitoring required that is consistent with the
Government of South Australia Risk Management Policy Statement.
References
ISMF Standard 71
Responsible Parties should consider the following events for logging:







user account and record actions, including access and
changes
successful and rejected authentication attempts, particularly for
system operator, support user, system administrator and other
trusted user roles
authentication and authorisation attempts that violate access
control standards
data input validation failures
changes to information asset configuration, privileges or
security-related services, including endpoint protection and
intrusion detection systems
privileged activities and any associated access control system
alerts, including system or service start/stop
fault events
ISMF Standard 71
ISMF Standard 73
ISFM Standard 74
All classifications
Responsible Parties should configure logging functionality to capture,
where relevant:


Event date and time according to an agreed standard time
source, such as an approved Coordinated Universal Time
(UTC) based Network Time Protocol (NTP) service or time
certification service where legal requirements may apply
User identity information (e.g. user or endpoint identifier)
ISMF Standard 71
ISMF Standard 75
Responsible Parties may consider undertaking and reporting on
periodic event, trend and pattern analysis using suitable security
information and event management platforms1.
Responsible Parties should implement review mechanisms for
ensuring that rectification of identified events have been effective and
have not compromised related security controls.
ISMF Standard 74
Business Owners should consider specifying contractual provisions
that include monitoring, analysis and reporting of relevant system and
security events when engaging third parties such as contractors and
Suppliers (please also refer to the example provisions detailed in
section BASELINE LOGGING REQUIREMENTS).
ISMF Standard 58
1
Example platforms include but are not limited to the Tier 3 Huntsman Intelligent Enterprise Security Suite, the RSA
Netwitness security monitoring platform or the HP ArcSight Security Intelligence and Risk Management platform.
Government guideline on cyber security
Logging and Monitoring v1.0
Page 3 of 7
ISMF Guideline 23
Applicability
Guidance
References
Responsible Parties should record and retain logging information in a
format that can be readily accessed and examined.
ISMF Standard 71
Business Owners should retain event related information for an
appropriate period with respect to applicable data retention
requirements and obligations.
ISMF Standard 71
[SLC] Sensitive:
Legal
Business Owners should clearly and explicitly establish the rights and
responsibilities of management with regard to monitoring of user
activity to mitigate legal challenge risks in response to actions that may
be supported by event monitoring.
ISMF Standard 66
[SP] Sensitive:
Personal
Responsible Parties should configure event recording functionality to
facilitate conformance with the compliance obligations and
requirements pertaining to the recording of private information pursuant
to legislative requirements such as the Cth. Privacy Act 1988 or State
based equivalent.
ISMF Standard 72
Responsible Parties should consider real-time capable event analysis
using suitable security information and event management platforms1.
ISMF Standard 71
[P] Protected
[I4] Integrity 4
[A4] Availability 4
EVENT LOG ACCESS AND PROTECTION
When compromising a system, adversaries commonly tamper with or remove logs to cover their
tracks. Especially when an adversary can access higher level privileges, the integrity of log files
are in jeopardy.
Sound auditing and event monitoring and analysis practices require assurances that any recorded
event data is accurate, uncompromised and only available to those who are legitimately authorised
to access this data.
This section provides guidance for important considerations for taking appropriate measures to
protect event data and thus provide assurances of data confidentiality, integrity and availability.
Table 2 – Event log access and protection
All classifications
Responsible Parties should establish processes and
procedures to safeguard the accuracy and integrity of data
captured or held in event logs, such as data validity checks.
ISMF Standard 72
Responsible Parties should ensure that procedures include
confidentiality, integrity and availability considerations for
event logging and monitoring capabilities, such as rolebased security privileges for log configuration or event
record access.
ISMF Standard 72
Government guideline on cyber security
Logging and Monitoring v1.0
Page 4 of 7
ISMF Guideline 23
[SLC] Sensitive:
Legal
[SP] Sensitive:
Personal
Responsible Parties should include conflict of interest
considerations in the assignment of event logging,
monitoring and review responsibilities.
ISMF Standard 72
Event logs must be retained and stored in a manner that
allows their integrity and authenticity to be verified for any
period required to meet all legal and regulatory
requirements (e.g. signed, encrypted etc.).
ISFM Standard 71
Responsible Parties should configure event recording
functionality to facilitate conformance with the compliance
obligations and requirements pertaining to the recording of
private information pursuant to legislative requirements such
as the Cth. Privacy Act 1988 or State based equivalent.
ISMF Standard 72
ISMF Standard 109
BASELINE LOGGING REQUIREMENTS
Baseline logging requirements can specify minimum requirements for services to capture and
monitor cyber security system events. The following table provides a reference example of a set of
provisions that may be integrated into contractual agreements, e.g. with third-party suppliers.
Table 3 - Example Provisions for Baseline Logging Requirements
Provision
Standards
Identification of Event
Logs source device or
facility
All Event Logs collected on behalf of the State and Customers shall clearly
identify the source device type (e.g. Router Model 123, Server Brand XYZ etc.)
including the devices ‘common or network’ name.
Log Retention period
During the Term of the Agreement and during the term of each Customer
Agreement.
Destruction and
Erasure of Event Logs
Event Logs must be provided to each Customer (as Customer Data) upon
termination or expiration of each Customer Agreement or at such other times
during the Term as agreed between the Parties. Under no circumstances shall
the Supplier destroy, erase or otherwise dispose of any copy of an Event Log
until that Event Log has been provided to the relevant Customer in accordance
with conditions contained in the relevant Customer Agreement(s).
Timestamps
Event Logs must derive and synchronise their local reference clocks to the
State’s time provider (e.g. ntp1.sa.gov.au) unless otherwise agreed between a
Customer and the Supplier in a Customer Agreement.
Fields and other
information to be
captured by Event
Logs
Unless otherwise agreed between a Customer and the Supplier, the Supplier
agrees to capture (so far as it is technically possible for the device or ICT
system to do so) the following fields and other information in Event Logs:

User identification, login credentials, account identification or other such
information

Device configuration changes and modifications

Uniform Resource Locators (URL) or hyperlinks

Source/destination addresses including but not limited to: Media Access
Control (MAC), Internet Protocol (IP), IP logical port assignment, Virtual
Government guideline on cyber security
Logging and Monitoring v1.0
Page 5 of 7
ISMF Guideline 23
Provision
Standards
Local Area Network (VLAN) tag, Multi-Protocol Label Switching (MPLS)
tag and other relevant traffic mapping identifying source(s) and
destination(s) of payload and transport information
Access to Event Logs

User agents (i.e. browser types) incorporating version or variant numbers

Default server/device Event Logs fields and information (forwarded to
central log server).
Customers must be provided with a copy of all Events Logs relative to the
Services provided under their respective Customer Agreement(s) within
fourteen (14) calendar days of making a request to the Supplier.
If requested by the State’s PCA, the Supplier must provide a copy of all Event
Logs to the State within fourteen (14) calendar days (or such longer period as
agreed) of making a request to the Supplier.
In certain instances, the Supplier may be required to provide raw Event Logs in
their native device-generated format for purposes of forensic analysis and/or
investigations.
Format of Event Logs
Where the Supplier obtains and manages Event Logs in a proprietary format,
the Supplier must provide such Event Logs to Customers and the State in an
open or commonly readable format (i.e. using an ‘exportable’ format).
Security classification
and/or protective
marking of Event Logs
Unless otherwise agreed between the Customer and the Supplier, the Supplier
agrees to treat, handle, transmit, maintain and manage Event Logs in
accordance with the corresponding security classification obligations and
requirements of the system, platform, service or device associated with the
Deliverable.
ADDITIONAL INFORMATION

Detailed provisions for web server and web application logging configurations are provided by
the Government of South Australia web applications and web server security standards.

Further information and good practice guidance on this topic are available from the National
Institute of Standards and Technology (NIST), the Australian Signals Directorate (ASD) and the
SANS institute.
This guideline does not aim to provide the reader with all of the responsibilities and
obligations associated with the logging and monitoring of cyber security events. It is
merely an overview of the information provided in applicable government cyber security
policy, applicable governance frameworks and the resources and utilities available at the
time of publication. It is highly recommended that agencies review these documents in
their entirety. The individual requirements of agencies will have direct bearing on what
measures are implemented to mitigate identified risk(s).
Government guideline on cyber security
Logging and Monitoring v1.0
Page 6 of 7
ISMF Guideline 23
REFERENCES, LINKS & ADDITIONAL INFORMATION
1. OCIO/F4.1 Government of South Australia Information Security Management Framework
[ISMF]
2. PC030 Government of South Australia Protective Security Management Framework [PSMF]
3. Australian Government Protective Security Policy Framework [PSPF]
4. Australian Government Information Security Manual, Australian Signals Directorate
5. Strategies to Mitigate Targeted Cyber Intrusions – Mitigation Details, Australian Signals
Directorate
6. Guide to Computer Security Log Management, National Institute of Standards and Technology
(NIST), United States
7. Logging Technology and Techniques, SANS Institute, United States
ID
OCIO_G4.23
Classification/DLM
PUBLIC-I2-A1
Issued
April 2014
Authority
State Chief Information Security Officer
Master document location
Q:\SecurityRiskAssurance\Policy Development Sub-program\Policy and
Standards\ISMF\v3.2\ISMFguidelines\
Records management
File Folder: 2011/15123/01 - Document number: 8354295
Managed & maintained by
Office of the Chief Information Officer
Author(s)
Christian Bertram, Enterprise Architect
Reviewer(s)
Tony Stevens, Senior Analyst
Jason Caley CISM, MACS (CP), IP3P, CRISC, CEA, Principal Policy Adviser
Compliance
Discretionary
Next review date
March 2016
To attribute this material, cite the
Office of the Chief Information
Officer, Government of South
Australia, ISMF Guideline 23.
This work is licensed under a Creative Commons Attribution 3.0 Australia Licence
Copyright © South Australian Government, 2014.
Disclaimer