[Entity]
No:
Information Technology Standard
IT Standard: Updated:
Issued By:
Security Logging
Owner:
1.0 Purpose and Benefits
Logs record data so that systems and networks can be appropriately monitored to
maintain use for authorized purposes and an awareness of the operating environment,
including detecting indications of security problems.
This standard defines requirements for security log generation, management, storage,
disposal, access, and use. Security logs are generated by many sources, including
security software, such as antivirus software, firewalls, and intrusion detection and
prevention systems; operating systems on servers, workstations, and networking
equipment; databases and applications.
2.0 Authority
[Authority Needed]
3.0 Scope
[Scope Needed]
4.0 Information Statement
Logs must be generated in information technology (IT) systems and networks.
Because of the nature of the data contained in security logs (e.g., passwords, e-mail
content), they are considered personally identifying information (PII) and must be
protected with the controls for a confidentiality and integrity of high.
4.1 Initial Log Generation
a. All hosts and networking equipment must perform security log generation for
all components (e.g., OS, service, application).
b. All security events (Appendix A) must be logged and must be set to capture
significant levels of detail to indicate activity.
4.2 Log Administration
a. All hosts and networking equipment must issue alerts on security log
processing failures, such as software/hardware errors, failures in the log
capturing mechanisms, and log storage capacity being reached or exceeded.
All alerts must be as close to real time as possible.
b. When non-revolving log storage reaches 90% capacity, a warning must be
issued.
4.3 Log Consolidation
a. Security-related information from all systems, with the exception of individual
workstations, must be transferred to a consolidated log infrastructure. Systems
running workstation operating systems which are used for shared services,
such as shared file storage or web services must also satisfy these
requirements.
b. All workstations must have the ability to transfer logs to a consolidated log
infrastructure, if needed.
c. Log data must be transferred real-time from individual hosts to a consolidated
log infrastructure. Where real-time transfer is not possible, data must be
transferred from the individual hosts to a consolidated log infrastructure as
quickly as the technology allows.
d. Entities must establish processes for the establishment, operation and, as
appropriate, integration of log management systems.
4.4 Log Storage and Disposal
a. Within the consolidated log infrastructure, logs must be maintained and readily
available for a minimum of 92 days. Based on entity requirements, including
audit or legal needs, logs may need to be retained for a longer period of time.
b. Log data must be securely disposed of (at both the system and the
infrastructure level) in compliance with the Sanitization/Secure Disposal
Standard.
c. Systems that collect logs, whether local or consolidated, must maintain
sufficient storage space to meet the minimum requirements for both readily
available and retained logs. Storage planning must account for log bursts or
increases in storage requirements that could reasonably be expected to result
from system issues, including security.
d. A process must be put in place to provide for log preservation requests, such
as a legal requirement to prevent the alteration and destruction of particular
Security Logging Standard Page 2 of 3
log records (e.g., how the impacted logs must be marked, stored, and
protected).
e. Log integrity for consolidated log infrastructure needs to be preserved, such as
storing logs on write-once media or generating message digests for each log
file.
4.5 Log Access and Use
a. Log data must be initially analyzed as close to real time as possible.
b. Access to log management systems must be recorded and must be limited to
individuals with a specific need for access to the records. Access to log data
must be limited to the specific sets of data appropriate for the business need.
c. Procedures must exist for managing unusual events. Response must be
commensurate with system criticality, data sensitivity and regulatory
requirements.
5.0 Compliance
This standard shall take effect upon publication. Compliance is expected with all
enterprise policies and standards. Entities may amend its policies and standards at
any time; compliance with amended policies and standards is expected.
If compliance with this standard is not feasible or technically possible, or if deviation
from this policy is necessary to support a business function, entities shall request an
exception through the Chief Information Security Officer’s exception process.
6.0 Definitions of Key Terms
Term Definition
7.0 Contact Information
Submit all inquiries and requests for future enhancements to the policy owner at:
[Entity Address]
8.0 Revision History
This standard shall be subject to periodic review to ensure relevancy.
Date Description of Change Reviewer
Security Logging Standard Page 3 of 3
9.0 Related Documents
NIST Special Publication 800-92, Guide to Computer Security Log Management
Security Logging Standard Page 4 of 3
Appendix A: Security Events to Log
Security events that must be logged for all systems include but are not limited to:
Successful and unsuccessful authentication events to include but not limited to:
system logon/logoff;
account or user-ID;
change of password;
the type of event;
an indication of success or failure of event;
the date and time of event; and
Identification of the source of event such as location, IP addresses terminal
ID or other means of identification.
Unsuccessful resource access events will be logged to include at minimum:
account or user-ID;
the type of event;
an indication of the event;
the date and time of event;
the resource; and
identification of the source of event such as location, IP addresses terminal
ID or other means of identification.
Successful and unsuccessful privileged operations including but not limited to:
use of system privileged accounts;
system starts and stops;
hardware attachments and detachments;
system and network management alerts and errors messages; and
security events - account/group management and policy changes.
Successful and unsuccessful access to log files to include but not limited to:
account or user-ID;
the type of event;
an indication of success or failure of event;
the date and time of event; and
identification of the source of event such as location, IP address, terminal ID
or other means of identification.
Appendix A Page 1 of 2
Most web servers offer the option to store log files in either the common log format or an
extended log format. The extended log format records more information than the common
log file format. When technically feasible web servers must use extended log format. The
extended log format adds valuable logging information to your log file so you can
determine where messages are coming from, who is sending the message and adds
information to the log file that would be necessary to trace an attack.
For systems identified as critical based on a risk assessment or systems that have not yet
been classified, in addition to the above, successful resource access events will be logged
to include at a minimum:
account or user-ID;
the type of event;
an indication of the event;
the date and time of event;
the resource; and
identification of the source of event such as location, IP addresses terminal
ID or other means of identification.
Security Logging Standard Page 2 of 3
