South Plains College

Information Services (SPC-IS)

 

Security Logging Standard: I-D(d)

Purpose and Benefits

Logs record data so that systems and networks can be appropriately monitored to maintain authorized use and awareness of the operating environment, including detecting indications of security problems.

This standard defines security log generation, management, storage, disposal, access, and use requirements. 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.

Scope

This standard applies to all network devices, servers, wireless access points, and other devices that handle security on the SPC network.

Information Statement

Logs must be generated in information technology (IT) systems and networks. Because of the data contained in security logs (e.g., passwords, and e-mail content), they are considered personally identifying information (PII). They must be protected with controls for confidentiality and integrity.

1.    Initial Log Generation

1. All hosts and networking equipment must generate security logs for all components (e.g., OS, service, application).
2. All security events (Appendix A) must be logged and set to capture significant levels of detail to indicate activity.

2.    Log Administration

1. 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.
2. A warning must be issued When non-revolving log storage reaches 90% capacity.

 

 

3.    Log Consolidation

1. Security-related information from all systems, except individual workstations, must be transferred to a consolidated log infrastructure. Workstation operating systems running for shared services, such as shared file storage or web services, must also satisfy these requirements.
2. All workstations must be able to transfer logs to a consolidated log infrastructure if needed.
3. Log data must be transferred from individual hosts to a consolidated log infrastructure in real time. Where real-time transfer is impossible, data must be transferred from the individual hosts to a consolidated log infrastructure as quickly as the technology allows.
4. Entities must establish processes for establishing, operating, and, as appropriate, integrating log management systems.

4.    Log Storage and Disposal

1. Within the consolidated log infrastructure, logs must be maintained and readily available for at least 92 days. Based on entity requirements, including audit or legal needs, logs may need to be retained for a longer period.
2. Log data must be securely disposed of (at both the system and the infrastructure level) in compliance with the Sanitization/Secure Disposal Standard.
3. Systems that collect logs, whether local or consolidated, must maintain sufficient storage space to meet the minimum requirements for 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.
4. A process must be implemented for log preservation requests, such as a legal requirement to prevent the alteration and destruction of particular log records (e.g., how the impacted logs must be marked, stored, and protected).
5. 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.

5.    Log Access and Use

1. Log data must be initially analyzed as closely as possible in real time.
2. Access to log management systems must be recorded and limited to individuals with a specific need for access to the records. Access to log data must be limited to the specific data sets appropriate for the business need.
3. Procedures must exist to manage unusual events. The response must be commensurate with system criticality, data sensitivity, and regulatory requirements.

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.

Related Documents

NIST Special Publication 800-92, Guide to Computer Security Log Management

 An index of approved SPC-IS policies can be found on the SPC Policies website at http://www.southplainscollege.edu/human_resources/policy_procedure/?%20.  The SPC Information Security Program and SPC Information Security User Guide are also available on the Information Technology Services Policies website.

Texas Security Controls Standards Catalog Control Group: AU-1, AU-2, AU-3, AU-4

NIST Function Groups:   PR.MA-2, PR.PT-1, DE.AE-3, DE.CM-4, DE.CM-7

 

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.

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.