Virtual Information Security Center (VISC)
Log Management Guidelines
Last Revised:
February 13, 2012
Draft:
January 16, 2012
Title
DRAFT
REVISION CONTROL
Document Title:
Log Management Guidelines
Author:
VISC Log Management
File Reference
?
Revision History
Revision Date
Revised By
Summary of Revisions
Section(s) Revised
01-16-20120116-2012
Rafael Villegas
Draft Document
All
02-13-2012
Rafael Villegas
Added recommendations from team review
All
3-15-2012
VISC Doc Team
Formatting, addition of section 4.2.5, definition changes
All
Review / Approval History
Review Date
Reviewed By
Action (Reviewed, Recommended or Approved)
01-30-20120130-2012
Log Management
TeamLog
Management Team
ReviewedReviewed
Last Revised: 02/13/12
Page ii
Title
DRAFT
Table of Contents
Page
1.0
INTRODUCTION .............................................................................................................................................. 4
2.0
PURPOSE ........................................................................................................................................................ 4
3.0
SCOPE ............................................................................................................................................................. 4
4.0
GUIDELINES FOR LOG MANAGEMENT ........................................................................................................ 4
4.1
Log Management Processes .................................................................................................................. 5
4.2
Log Generation ....................................................................................................................................... 5
4.2.1
Log Events ................................................................................................................................. 6
4.2.2
Log Event Frequency ................................................................................................................. 6
4.2.3
Log Event Details ....................................................................................................................... 6
4.2.4
Log Contents .............................................................................................................................. 7
4.2.5
Log Synchronization................................................................................................................... 7
4.3
Log Retention and Storage ..................................................................................................................... 7
4.4
Log Analysis ............................................................................................................................................ 9
4.4.1
4.5
Monitoring and Reporting ........................................................................................................... 9
Log Protection and Security .................................................................................................................. 10
5.0
DEFINITIONS ................................................................................................................................................. 11
6.0
REFERENCES ............................................................................................................................................... 12
Last Revised: 02/13/12
Page iii
Title
1.0
DRAFT
INTRODUCTION
The collection, regular review and retention of logs and events enable organizations to meet compliance with
regulations and properly protect their information resources. Log and event management is essential to ensure
that information security records are stored in sufficient detail for an appropriate period of time.
Log management activities include log and event generation, transmission, storage, analysis and disposal; while
protecting the confidentiality, integrity and availability of logs. Logs contain information related to many
different types of events occurring within computer systems, networks and applications. These logs provide
information on security events, including user access and activities.
2.0
PURPOSE
Each member university of the VISC will need to define log management procedures that address log and event
generation, retention, storage, analysis, protection and security. Appropriate log management guidelines,
procedures and a log management infrastructure add value in the following areas:

Compliance
o
Sufficient log collection and retention to meet government regulations, standards, policies
and other compliance requirements.
o
Suitable reports readily available during an audit.

Risk Management
o The review and monitoring of logs can help detect or prevent security incidents.

Forensics

o
The right logs can reduce costs associated with evidence collection efforts in the event of a
o
security breach.
Complete logs can assists in system recovery and cleanup after a security incident.
Operations
o
Effective log collection and analysis is complimentary to monitoring, can improve system
availability and assist in problems resolution.
3.0
SCOPE
This log management guideline applies to all member universities of the Virtual Information Security Center
(VISC).
4.0
GUIDELINES FOR LOG MANAGEMENT
This guideline based on the recommendations of the National Institute of Standards and Technology (NIST)
publications 800-92 (Computer Security Log Management) and 800-53 (Recommended Security Controls for
Federal Information Systems), and other log management practices provide recommendations in the following:


Log Management Processes
Log Generation
Last Revised: 02/13/12
Page 4 of 12
Title
DRAFT



Log Retention and Storage
Log Analysis
Log Protection and Security
Log management benefits include enhanced security, resource management and regulatory compliance. A
dedicated log management infrastructure can capture information and aid analysis about:
4.1

Access
o Identify who is using services.

Change Monitoring
o Ascertain how and when services are modified.

Malfunction
o Recognize when services fail.

Security Events
o Determine what activity occurred during an incident.
Log Management Processes
Log management guidelines and procedures should be based on the requirements of applicable regulations and
standards, guidance from legal counsel, university business objectives and a risk analysis.
The proper planning of a log management infrastructure requires consideration of current and future requirements
that include volume of logs, storage capacity, security requirements, and time and resource to analyze the logs
and manage the infrastructure. Analyses of a university’s risk are factors in making these log management
decisions.
Fully documented processes and procedures should define requirements for log generation, analysis, retention,
storage and security. Management commitment includes prioritization, and the allocation of resources required for
the log management efforts.
Roles and responsibilities, including separation of duties, will need to be factored into the procedures to provide
proper support of log management activities.
4.2
Log Generation
There are many sources of log information:
o
Application logs and services that can potentially identify what transactions have been performed, at
what time, by whom, and on what, such as web, database and authentication can provide detailed
o
information about those activities.
System logs for operating systems.
o
o
Network devices, such as firewalls, routers and switches are generally capable of logging information.
Change management logs that document changes in the business environment.
o
Other logs that originate from physical access or surveillance logs.
Given the number of devices, systems and applications it is not always necessary or practical to log everything.
Therefore, it is important to conduct a risk assessment to determine the collection of sufficient data to meet the
requirements of regulations, potential incident investigations and legal issues.
Last Revised: 02/13/12
Page 5 of 12
Title
4.2.1
DRAFT
Log Events
Based on a risk assessment determine which events require logging on a continuous basis and which events
require logging in response to specific situations.
As referenced in a CSU standard
#8045.600
(http://www.calstate.edu/icsuam/sections/8000/8045.0.shtml) **at a minimum and as appropriate, taking into
account the capabilities of the device or application creating the log entries, such controls will need to be tracked
and logged for the following events:

Actions taken by any individual with root or administrative privileges

Changes to system configuration

Access to audit trails

Invalid logical access attempts

Use of identification and authentication mechanisms

Alarms raised by an access control system

Activation and de-activation of controls, such as anti-virus software or intrusion detection system.

Changes to, or attempts to change system security settings or controls
There are many log sources and some logs are more likely than others to record information that would be helpful
for different situations, such as detecting attacks, fraud and inappropriate usage. Therefore, when prioritizing log
collection, each university should define their requirements and goals.
4.2.2
Log Event Frequency
Log data from servers, network components (switches, routers, etc.) and other critical devices/services should be
collected real time. Log data from non-critical devices/services should be collected every 5 minutes or as
appropriate.
4.2.3
Log Event Details
Ensure that the details captured for events and activities contain sufficient information to establish what events
occurred, the sources of the events, and the outcomes of the events. For each of the events, the following will
need to be recorded, as appropriate:

User identification

Type of event

Date and time

Success or failure indication

Data accessed

Program or utility used

Origination of event (e.g., network address)

Protocol/Port used

Identity or name of affected data, information system or network resource
Log data should be collected in its original form whenever practical but may also be collected in a normalized form
(e.g., comma-separated variable format) if the normalization takes place at the time of collection and the integrity
of the normalized log data is assured.
Last Revised: 02/13/12
Page 6 of 12
Title
DRAFT
When appropriate, a California State University (CSU) approved data encryption, checksums or a similar process,
should be used to protect the integrity of collected, production and archived log data.
4.2.4
Log Contents
Logging can capture, intentionally or inadvertently, confidential information with privacy or security implications.
Security logs are considered confidential data and should only be used for their intended purpose, which is to
maintain the operation and security of university information resources.

Level 1 data should not be logged, and logging of Level 2 data should be minimized.

Programming and debugging methods may result in unintended logging of sensitive data.
4.2.5
Privacy
They should not be used to monitor personal information about individual users, such as their location at a given
time, web sites that they may have visited or files that they may have downloaded. Any exceptions to this
guideline require a documented request and specific authorization from appropriate management.
4.2.5
Log Synchronization
All log sources’ internal clocks will need to be synchronized to a trusted, accurate timeserver.
4.3
Log Retention and Storage
Log data should be collected using a centralized, hardened system with restricted physical and remote access
that provides both rapid access to production log data as well as a long-term archive of data held in a compressed
and secure format.
A difficult issue involved in the retention of data is knowing how long the data must be retained. In general,
security log information should not be retained beyond its usefulness or as required by applicable laws,
regulations, CSU policies and standards.
The following key regulations, standards and guidelines can help each university to define its requirements for log
retention and storage:

Federal Information Security Management Act (FISMA).
FISMA emphasizes the need for each
Federal agency to develop, document and implement an organization-wide program to provide
information security and describes several controls related to log management, including the generation,
review, protection and retention of audit records, as well as the actions to be taken because of audit
failure.

Gramm-Leach-Bliley Act (GLBA).
GLBA requires financial institutions to protect their customers’
information against security threats. The Federal Trade Commission (FTC) has officially stated that any
college or university that complies with the Federal Educational Rights and Privacy Act (FERPA) and that
is also a financial institution subject to the requirements of GLBA should be deemed to be in compliance
with GLBA’s privacy rules if it is in compliance with FERPA.
Last Revised: 02/13/12
Page 7 of 12
Title
DRAFT

Health Insurance Portability and Accountability Act (HIPAA). HIPAA includes security standards for
certain health information. The requirements include the need to perform regular reviews of audit logs,
access reports and specifies that documentation of actions and activities need to be retained.

Payment Card Industry Data Security Standard (PCI DSS). PCI DSS applies to organizations that
store, process or transmit cardholder data for credit cards. One of the requirements of PCI DSS is to
track access to network resources and cardholder data.

Sarbanes-Oxley Act (SOX).
SOX applies primarily to financial and accounting practices, but also
encompasses the information technology (IT) functions that support these practices. Reviewing logs
regularly to look for signs of security violations, as well as retaining logs can support SOX and records of
log reviews for future review by auditors.

Senate Bill 1386 (SB 1386).
On July 1, 2003, Senate Bill 1386 became effective in the State of
California, requiring government agencies and businesses operating in California to publicly disclose
computer security breaches, whenever it is reasonable to believe that a security breach may have
compromised personal data belonging to a resident of California. Log management can be helpful in
identifying possible security violations and resolving them effectively
Many regulations do not specifically indicate retention duration of log for audit cycles.
However, for many
regulations audit cycles are one year. Therefore, production log data that is being actively used for real time
analysis, on-going review and periodic audits and assessments should be maintained on-line for one year.
Retaining logs for this period also facilitates real time monitoring, on-going review and analysis.
The requirements of log management for some regulations and standards are shown in tables 2.
Schedules
Federal
Information
Security
Management
Act (FISMA)
GrammLeach-Bliley
Act (GLBA)
Health
Insurance
Portability and
Accountability
Act (HIPAA)
Minimum
specified duration
Not specified
Not specified
Not specified
Minimum of
one year
Not specified
Retention to meet
audit cycle
One year
One year
One year
One year
One year
Payment
Card Industry
(PCI)
Not specified
Long term
retention of logs
that may include
audit records
Not specified
Not specified
(Six years for
documentation of
policies, actions,
procedures, or
assessments)
SarbanesOxley Act
(SOX)
Not specified
Not specified
(Seven years of
documents and
communications
related to an
audit)
Table 2: Example of log sources and content (not exhaustive)
Archive log data should be stored longer term based on regulatory, CSU retention schedules, legal discovery,
possible forensic requirements and incident handling procedures. Archive data may need to be retained for
approximately two to seven years depending on the long term regulatory data retention requirements.
Last Revised: 02/13/12
Page 8 of 12
Title
DRAFT
The CSU retention and disposition schedules are located at http://www.calstate.edu/recordsretention/. Where no
regulatory or policy requirements exist, a general guideline is to maintain security logs for at least three months
but no longer than six months.
Production and archived data should be protected against loss by the same backup process that protects other
university data.
Provisions should be made to securely delete security log information beyond the retention period. The logs
should be destroyed according to the university’s data destruction policies.
4.4
Log Analysis
For compliance purposes, it is recommended to keep a record of log analysis audit history. Access to log data
should be restricted to the appropriate members as determined by management.
Each university should develop and deploy log review procedures to address:
o
Who is responsible for the overall process and results
o
How often reviews will take place
o
o
How often review results be analyzed
Types of log data and monitoring procedures that will be needed
o
o
How reports or logs will be reviewed
Where monitoring reports will be filed and maintained
o
o
Mechanisms implemented to assess the effectiveness of the review process (metrics)
The plan to revise the review process when needed
The regular review and analysis of logs can detect:
o
o
Anomalous events
Attempts to gain access
o
o
Failed file or resource access attempts
Unauthorized changes to users, groups and services
o
o
Suspicious or unauthorized network traffic patterns
Problem trends
Automation can improve the review and analysis of logs. However, log reduction, review and reporting tools
should support log analysis without altering original log records.
The inadvertent disclosure of confidential information recorded in logs should be reported to the respective
university management.
4.4.1
Monitoring and Reporting
Automate as much of the review process as possible to regularly review/analyze logs for indications of
inappropriate or unusual activity, investigate suspicious activity or suspected violations, report findings to
appropriate management, and take necessary actions.
A daily review or critical services and devices is required to identify events serious to service performance or
function and events that may reflect unauthorized or illegal activity and take immediate actions.
Last Revised: 02/13/12
Page 9 of 12
Title
DRAFT
A weekly review is required to identify events and patterns indicating unauthorized, suspicious, or illegal behavior.
4.5
Log Protection and Security
Log data should be collected to a centralized, hardened system with restricted physical and remote access that
provides both rapid access to current information for network administration and management support as well as
a long-term archive of data held in a compressed and secure format.
Strict access controls should be utilized. The log management infrastructure should protect log information and
log tools from unauthorized access, modification and deletion.
Log data should always be considered confidential.
Each university should ensure that the privacy of the log data is protected in accordance with applicable CSU
standards for confidential data.
The unauthorized access, or attempted unauthorized access, to logs may be an indication of an attack and should
be treated as an information security incident.
Each university should secure the processes that generate the log entries via approved policies and procedures.
When log data is transmitted over a public network, a secure mechanism for transferring log data using an
approved CSU encryption standard should be implemented.
The confidentiality and integrity of the log files should be maintained using an approved CSU protection
methodology.
Last Revised: 02/13/12
Page 10 of 12
Title
5.0
DRAFT
DEFINITIONS
Asset – anything that has value to the organization.
Availability - Ensuring that information assets are available and ready for use when they are needed.
Confidentiality – Preserving authorized restrictions on information access and disclosure, including means for
protecting personal privacy and proprietary information. [44 U.S.C, SEC. 3542]
Critical – Critical resources are resources that are essential to the success of a university. Critical resources
include those classified as Level 1 (see definition) or Level 2 (see definition).
Guidelines -- a description that clarifies what should be done and how, to achieve the objectives set out in
policies.
Incident – see Information Security Incident
Information security incident – any unexpected or unwanted event that causes a compromise of business
activities or information security. Examples of information security incidents are:
human errors and non-
compliances with policies or guidelines.
Information security – all aspects related to defining, achieving and maintaining confidentiality, integrity,
availability, non-repudiation, accountability, authenticity and reliability.
Information security policy – rules, directives and practices that govern how assets, including sensitive
information, are managed, protected and distributed within an organization.
Integrity – Guarding against improper information modification or destruction, and includes ensuring information
non-repudiation and authenticity. [44 U.S.C., SEC. 3542]
Level 1 – data or information governed by existing law or statute such as Social Security number, credit card
number, or health information. Data, information or resources are classified as confidential.
Level 2 – data or information that should be protected due to ethical or privacy concerns such as grades,
disciplinary actions or employment history. Data, information or resources are classified as restricted or private.
Resource – anything that has value to the organization.
Risk management – A structured process which identifies risks, prioritizes them, and then manages them to
appropriate and reasonable levels.
Service – an application or operating system running on a computer system that provides a resource to other
network resources.
Last Revised: 02/13/12
Page 11 of 12
Title
DRAFT
Threat – A person or agent that can cause harm to an organization or its resources. The agent may include other
individuals or software (e.g. worms, viruses) acting on behalf of the original attacker.
Vulnerability – A flaw within an environment which can be exploited to cause harm.
6.0
REFERENCES
CSU, California State University, “Integrated CSU Administrative Manual - Information Security Policy”,
Retrieved on January 3, 2012, Online from http://www.calstate.edu/icsuam/sections/8000/
CSU, California State University, “Records Retention and Disposition Schedules”,
Retrieved on January 7, 2012, Online from http://www.calstate.edu/recordsretention/
ISO/IEC 17799:2005, (2005). Information technology - Security Techniques - Code of practice for information
security management: International Standards Organization.
ISO 15408 ISO/IEC 15408-1: (1999 (E)), International Standard ISO/IEC 15408-1 The Common Criteria for
Information Technology Security Evaluation v2.1. International Standards Organization.
NIST, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS)
Publication 199, “Standards for Security Categorization of Federal Information and Information Systems”,
(February 2004).
NIST, National Institute of Standards and Technology, Special Publication 800-53, Revision 3, “Recommended
Security Controls for Federal Information Systems and Organizations”, (August 2009).
NIST, National Institute of Standards and Technology, Special Publication 800-92, “Guide to Computer Security
Log Management”, (September 2006).
Last Revised: 02/13/12
Page 12 of 12