Log Management Standard 1.0 INTRODUCTION 2.0 SYSTEM AND APPLICATION MONITORING STANDARD. 2.1 Required Logging



Similar documents
FIREWALL CHECKLIST. Pre Audit Checklist. 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review.

University of Pittsburgh Security Assessment Questionnaire (v1.5)

Standard: Event Monitoring

USM IT Security Council Guide for Security Event Logging. Version 1.1

<COMPANY> PR11 - Log Review Procedure. Document Reference Date 30th September 2014 Document Status. Final Version 3.

Teleran PCI Customer Case Study

Client Security Risk Assessment Questionnaire

FairWarning Mapping to PCI DSS 3.0, Requirement 10

WHITEPAPER XMEDIUSFAX CLOUD FOR HEALTHCARE AND HIPAA COMPLIANCE

6. AUDIT CHECKLIST FOR NETWORK ADMINISTRATION AND SECURITY AUDITING

Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite.

PCI DSS Policies Outline. PCI DSS Policies. All Rights Reserved. ecfirst Page 1 of 7

APPENDIX G ASP/SaaS SECURITY ASSESSMENT CHECKLIST

Rule 4-004M Payment Card Industry (PCI) Monitoring, Logging and Audit (proposed)

ensure prompt restart of critical applications and business activities in a timely manner following an emergency or disaster

TASK TDSP Web Portal Project Cyber Security Standards Best Practices

Guideline on Auditing and Log Management

Log Management for the University of California: Issues and Recommendations

Specific observations and recommendations that were discussed with campus management are presented in detail below.

MySQL Security: Best Practices

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS

HIPAA Security Alert

The Comprehensive Guide to PCI Security Standards Compliance

Information Security Office. Logging Standard

University of California, Riverside Computing and Communications. IS3 Local Campus Overview Departmental Planning Template

IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including:

PCI DSS Requirements - Security Controls and Processes

FINAL May Guideline on Security Systems for Safeguarding Customer Information

IT General Controls Domain COBIT Domain Control Objective Control Activity Test Plan Test of Controls Results

Executive Summary Program Highlights for FY2009/2010 Mission Statement Authority State Law: University Policy:

GE Measurement & Control. Cyber Security for NEI 08-09

SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA)

Adopt and implement privacy procedures, train employees on requirements, and designate a responsible party for adopting and following procedures

Information Security Policy

Fortinet Solutions for Compliance Requirements

Automation Suite for. 201 CMR Compliance

Credit Card Acceptance Policy. Vice Chancellor of Business Affairs. History: Effective July 1, 2011 Updated February 2013

IT Security Procedure

Security Policy for External Customers

CorreLog Alignment to PCI Security Standards Compliance

FISMA / NIST REVISION 3 COMPLIANCE

Health Insurance Portability and Accountability Act Enterprise Compliance Auditing & Reporting ECAR for HIPAA Technical Product Overview Whitepaper

MIT s Information Security Program for Protecting Personal Information Requiring Notification. (Revision date: 2/26/10)

IT Security Standard: Computing Devices

TOP 10 WAYS TO ADDRESS PCI DSS COMPLIANCE. ebook Series

Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4

Security Information Lifecycle

SolarWinds Security Information Management in the Payment Card Industry: Using SolarWinds Log & Event Manager (LEM) to Meet PCI Requirements

The Business Case for Security Information Management

Server Protection Policy 1 1. Rationale 1.1. Compliance with this policy will help protect the privacy and integrity of data created by and relating

Altius IT Policy Collection Compliance and Standards Matrix

Information Security Risk Assessment Checklist. A High-Level Tool to Assist USG Institutions with Risk Analysis

Summary of Technical Information Security for Information Systems and Services Managed by NUIT (Newcastle University IT Service)

Vendor Questionnaire

The Protection Mission a constant endeavor

LogRhythm and PCI Compliance

Log Management How to Develop the Right Strategy for Business and Compliance. Log Management

Wellesley College Written Information Security Program

HIPAA Compliance Guide

Procedure Title: TennDent HIPAA Security Awareness and Training

whitepaper Ten Essential Steps for Achieving Continuous Compliance: A Complete Strategy for Compliance

2. From a control perspective, the PRIMARY objective of classifying information assets is to:

REGULATIONS FOR THE SECURITY OF INTERNET BANKING

AIRDEFENSE SOLUTIONS PROTECT YOUR WIRELESS NETWORK AND YOUR CRITICAL DATA SECURITY AND COMPLIANCE

Information Security Policy Manual

PierianDx - Clinical Genomicist Workstation Software as a Service FAQ s

TEMPLE UNIVERSITY POLICIES AND PROCEDURES MANUAL

Information Security Policy and Handbook Overview. ITSS Information Security June 2015

Information Security: A Perspective for Higher Education

Compliance and Industry Regulations

Infor CloudSuite. Defense-in-depth. Table of Contents. Technical Paper Plain talk about Infor CloudSuite security

INCIDENT RESPONSE CHECKLIST

Information Security Plan May 24, 2011

WHITEPAPER Complying with HIPAA LogRhythm and HIPAA Compliance

Enterprise Cybersecurity Best Practices Part Number MAN Revision 006

Payment Card Industry Self-Assessment Questionnaire

HIPAA Information Security Overview

05.0 Application Development

Supplier Security Assessment Questionnaire

AIRDEFENSE SOLUTIONS PROTECT YOUR WIRELESS NETWORK AND YOUR CRITICAL DATA SECURITY AND COMPLIANCE

Feature. Log Management: A Pragmatic Approach to PCI DSS

Central Agency for Information Technology

INFORMATION SECURITY GOVERNANCE ASSESSMENT TOOL FOR HIGHER EDUCATION

INFORMATION SECURITY Humboldt State University

How To Achieve Pca Compliance With Redhat Enterprise Linux

Information Technology Branch Access Control Technical Standard

TRIPWIRE NERC SOLUTION SUITE

University System of Maryland University of Maryland, College Park Division of Information Technology

Clavister InSight TM. Protecting Values

MANAGED FILE TRANSFER: 10 STEPS TO SOX COMPLIANCE

LOG MANAGEMENT: BEST PRACTICES

Transcription:

Log Management Standard Effective Date: 7/28/2015 1.0 INTRODUCTION The California State University, Chico system/application log management standard identifies event logging requirements, log review frequency, retention period of logs, and general configuration. System monitoring plays a critical role in securing information resources and aids in detecting unauthorized system activities, monitoring performance, and investigating incidents. An effective implementation of system monitoring requires clear standards, support by management, and well-trained system administrators in the areas of operating system and applications. Configuring logging requires individual system evaluation of risk, cost and performance to the system. System monitoring requires dedicated staff to regularly review, analyze, and take appropriate action to resolve or mitigate unauthorized events. Implements: CSU Policy ICSUAM 8045 Information Technology Security Policy Reference: http://www.calstate.edu/icsuam/sections/8000/8045.0.shtml Implements: CSU Standard ICSUAM 8045.S600 Logging Elements Policy Reference: http://www.calstate.edu/icsuam/sections/8000/8045.s600_logging_elements.pdf 2.0 SYSTEM AND APPLICATION MONITORING STANDARD 2.1 Required Logging Servers, applications and Workstations: All campus servers and high-risk workstations must send security logs at a minimum to the campus log Applications that process, or access Level 1 data must send authentication related log events to the log 2.2 Directory and Authentication Servers All directory and authentication servers must send authentication information at a minimum to the campus log Directory and authentication management servers include: AD, OpenLDAP, CAS, Shibboleth, Radius, ADFS, OID, Password Management applications, and Identity Management systems. Password recovery and modification systems must send all successful and unsuccessful attempts and IP address information to the log Information Security Office 1 July 28, 2015

Network Equipment: All network systems that perform authentication transactions must send such events the campus log Network device authentication and configuration change events must be sent to the campus log DNS, IDS, and Firewall logs must be retained in a log 2.3 Audit Logging Audit logging records system and user activities used for system performance tuning, detecting unauthorized access and to investigate incidents. Audit logs must contain at minimum, the event/application/process, user ID, date and time for key events. If possible or appropriate audit logs should identify terminal, location, network addresses and protocols. Key events are: Records of successful and failed system access attempts; Records of failed data and other resources access attempts; Changes to system configuration; Use of elevated privileges; Use of system utilities and applications; Alarms raised by the access control system; Changes to protection systems (e.g. firewall, anti-virus, and intrusion detection systems); Additional events identified by the vendor or system administrator. The types of events logged must be determined for each system taking into account an evaluation of risk, cost and performance to the system. 2.4 Log Event Format 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 Information Security Office 2 July 28, 2015

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. 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. 2.5 Monitoring of Logs and Events Monitoring requires regular review and analysis of log files and appropriate event follow-up. Daily log monitoring is required for critical systems or systems containing Level 1 protected information, or systems exposed through the border firewall. The campus Log and Event management system must be utilized for the collection of security events as well as daily review. It is recommended that a record of log analysis audit history be maintained. Access to log data should be restricted to the appropriate members as determined by management. Log review procedures should address the following topics: Who is responsible for the overall process and results How often reviews will take place How often review results be analyzed Types of log data and monitoring procedures that will be needed How reports or logs will be reviewed Where monitoring reports will be filed and maintained 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: Anomalous events Attempts to gain access Failed file or resource access attempts Unauthorized changes to users, groups and services 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. Information Security Office 3 July 28, 2015

The inadvertent disclosure of confidential information recorded in logs should be reported to the respective university management. 2.6 Reporting Security-Related Events Security-related events must be reported to the Information Security Office (x6212) or security@csuchico.edu. The Information Security Office will review these events and prescribe corrective measures as needed. Security-related events include, but are not limited to: Brute force attempts Accounts that have been automatically locked due to failed attempts Multiple simultaneous login events from geo-locations greater than 6,000 miles apart Port-scan attacks Evidence of unauthorized access Anomalous occurrences that are not related to specific applications on the host Theft of computing equipment. 2.7 Retention and Protection of Log Information Log information must be retained locally for a minimum of 90 days. Server and application security logs that include authentication and source IP must be sent to the campus log The campus log management system should retain logs for 6 months at a minimum. Schedules Minimum specified duration Retention to meet audit cycle Long term retention of logs that may include audit records Federal Information Security Managemen t Act (FISMA) Gramm- Leach-Bliley Act (GLBA) Health Insurance Portability and Accountability Act (HIPAA) Payment Card Industry (PCI) Minimum of one year Sarbanes-Oxley Act (SOX) One year One year One year One year One year (Six years for documentation of policies, actions, procedures, or assessments) (Seven years of documents and communications related to an audit) Information Security Office 4 July 28, 2015

Log information must be protected from tampering or modification on systems through need to know file access or appropriate security control. Systems with level 1 protected information must store logs on a secure secondary system. 2.8 Clock Synchronization All event generating applications must synchronize to the campus time servers. 3.0 Documentation Review & Approval Review / Approval History Review Date Reviewed By Action (Reviewed, Recommended or Approved) Version 5/11/15 Policies and Standards Group Reviewed / Recommended V1.0 7/21/15 Information Technology Executive Committee (ITEC) Approved V1.0 Information Security Office 5 July 28, 2015