Skip to main content

System Monitoring and Logging

Updated

PURPOSE:

This System Monitoring and Logging Policy establish the standards and procedures for monitoring and logging activity on Idaho College of Osteopathic Medicine (ICOM) information systems, networks, and applications. The purpose of this policy is to provide visibility into system operations, detect security incidents, support incident response and forensic investigations, ensure system performance and availability, and comply with relevant regulatory requirements. Comprehensive monitoring and logging are essential security controls for proactively identifying and responding to threats, maintaining system health, and supporting accountability. This policy applies to all institutional systems, including on-premises infrastructure and cloud-based services (including SaaS applications, to the extent applicable and feasible).

SCOPE:

This policy applies to all information systems, network devices, applications, and services owned, leased, managed, or used by ICOM, including but not limited to:

  • Servers (physical and virtual)
  • Workstations and laptops
  • Mobile devices (institutionally owned and MDM-managed devices, regarding security-relevant logging)
  • Network infrastructure devices (routers, switches, firewalls, intrusion detection/prevention systems – IDS/IPS)
  • Operating systems
  • Applications (institutionally managed applications)
  • Databases
  • Security systems (e.g., firewalls, anti-malware, vulnerability scanners, Identity and Access Management systems)
  • SaaS Applications (addressing logging capabilities available from SaaS vendors)
  • Cloud infrastructure services (IaaS, PaaS)
  • Web applications and services

This policy applies to all individuals responsible for managing, maintaining, securing, and using these systems, including but not limited to:

  • IT Department
  • System Administrators
  • SaaS Application Administrators (regarding SaaS logging configurations and review)
  • Information Technology Office
  • Users (regarding awareness of monitoring and logging and responsible system use).

DEFINITIONS:

  • Audit Log: A chronological record of system activities, particularly focused on user actions and administrative tasks, used to track activity, ensure accountability, and support audits.
  • Availability: Ensuring that information and systems are accessible to authorized users when they need them. Systems and data should be reliable and readily available for legitimate purposes.
  • Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
  • Integrity: Guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity.
  • Log (System Log, Security Log, Application Log): A record of events that occur within a computer system, network, or application. Logs provide a history of system activity and can be used for monitoring, troubleshooting, security analysis, and compliance auditing.
  • Log Management System (Centralized Log Management): A system designed to centrally collect, aggregate, store, analyze, and manage logs from various systems and applications across an organization. Often includes features for log searching, reporting, alerting, and security analytics.
  • Personally Identifiable Information (PII): Information that can be used to identify a specific individual, such as name, address, Social Security Number, Protected Health Information, etc., as further defined by applicable privacy regulations.
  • SaaS Application (Software as a Service): A software delivery model in which software is hosted by a vendor and made available to customers over a network, typically the internet, usually on a subscription basis.
  • SIEM (Security Information and Event Management): A security management system that combines security information management (SIM) and security event management (SEM) functions. SIEM systems provide real-time analysis of security alerts generated by applications and network hardware.
  • System Anomaly: An event or pattern of activity that deviates from normal or expected system behavior. Anomalies may indicate security incidents, system failures, or performance issues.
  • Threat Actor: An individual, group, or organization that attempts to exploit vulnerabilities or cause harm to information systems or data.

POLICY:

Logging Requirements: Logging must be enabled and configured on all systems and applications within the scope of this policy, to the extent technically feasible and practical. Logging should capture sufficient information to:

  • Detect and investigate security incidents and policy violations.
  • Monitor system performance and availability.
  • Troubleshoot system and application errors.
  • Support audit trails and compliance requirements.

Types of Logs to be Collected: The following categories of logs should be collected, where applicable and technically feasible:

  • Security Logs: Logs related to security events, including:
    • Authentication attempts (successful and failed logins).
    • Authorization events (access control decisions, privilege escalations).
    • Account management activities (account creation, modification, deletion).
    • Firewall logs (allowed and denied traffic).
    • Intrusion detection/prevention system (IDS/IPS) alerts.
    • Anti-malware alerts and detections.
    • Changes to security configurations.
    • Security policy violations.
  • System Logs: Logs related to system operations and events, including:
    • Operating system events and errors.
    • Hardware events and errors.
    • System startup and shutdown events.
    • Resource utilization (CPU, memory, disk, network).
    • System performance metrics.
  • Application Logs: Logs generated by applications, including:
    • Application errors and exceptions.
    • User activity within applications (transactions, data access, modifications).
    • Application-specific events and functions.
    • Web server access logs and error logs.
    • Database query logs (where appropriate and with consideration for performance and data sensitivity).
  • Audit Logs: Logs that provide a chronological record of system activities, particularly focused on user actions and administrative tasks, to support audit trails and accountability.

Log Retention: Logs must be retained for a sufficient period to meet security, operational, and compliance requirements. Log retention periods will be defined based on the type of log and relevant regulatory or institutional requirements, but as a general guideline:

  • Security Logs: Retain for a minimum of 30 days. Longer retention may be required for compliance or incident investigation needs.
  • System Logs: Retain for a minimum of 6 months.
  • Application Logs: Retain for a minimum of 3 months, or as required for specific applications or compliance needs.
  • Audit Logs: Retain for a minimum of 30 days, or as required for compliance.

Specific log retention periods for different log types and systems will be documented in the Data Retention Schedule. Log retention policies will comply with legal and regulatory requirements, including data privacy regulations and the Data Privacy Policy.

Log Storage and Security: Logs must be stored securely to protect their confidentiality, integrity, and availability. Log storage and security measures will include:

  • Centralized Log Management System (SIEM/Log Management): Utilize a centralized log management system (Security Information and Event Management - SIEM or equivalent log aggregation and analysis platform) where feasible, to collect, aggregate, and securely store logs from various systems.
  • Log Integrity Protection: Implement measures to ensure log integrity and prevent unauthorized modification or deletion of logs. This may include using write-once storage, digital signatures, or log integrity monitoring tools.
  • Access Control for Logs: Restrict access to log data to authorized personnel only (e.g., security administrators, system administrators, auditors, incident responders) based on the principle of least privilege and need-to-know.
  • Secure Log Transmission: Use secure protocols (e.g., TLS encryption) to transmit logs from source systems to the central log management system.
  • Secure Storage Infrastructure: Store log data on secure infrastructure with appropriate physical and logical security controls to protect against unauthorized access and data loss.

System Monitoring and Alerting: Logs must be actively monitored for security events, system anomalies, and policy violations. Implement automated monitoring and alerting mechanisms, including:

  • Real-time Monitoring (Where Feasible): Utilize SIEM or monitoring tools for real-time monitoring of security logs and system events.
  • Automated Alerting: Configure automated alerts to notify designated personnel (e.g., system administrators) when critical security events or anomalies are detected based on predefined rules and thresholds. Alerts should be prioritized based on severity and potential impact.
  • Regular Log Review: Conduct regular reviews of security logs and system events, even beyond automated alerting, to proactively identify potential security issues or trends that may not trigger automated alerts. Log review frequency should be based on the risk level of the systems being monitored.

Log Analysis and Incident Response: Logs are a critical resource for security incident response and forensic investigations. Establish procedures for:

  • Log Analysis During Incident Response: Utilize logs to analyze security incidents, identify root causes, track attacker activity, and assess the scope and impact of incidents.
  • Forensic Investigations: Preserve and utilize logs as evidence in forensic investigations, following established chain-of-custody procedures when necessary.
  • Correlation of Logs from Multiple Systems: Correlate logs from different systems and applications to gain a comprehensive view of security events and user activity across the institution's environment.

Monitoring and Logging in SaaS Environments: Recognizing the distributed nature of SaaS applications,
the institution will:

  • Utilize SaaS Vendor Logging Capabilities: Leverage logging features and capabilities provided by SaaS vendors. Configure SaaS applications to enable logging of security-relevant events and user activity within the SaaS environment, to the extent supported by the vendor.
  • Access SaaS Logs via APIs or Vendor Portals: When possible, utilize SaaS vendor APIs or administrative portals to access and retrieve SaaS logs for monitoring, analysis, and integration with central log management systems.
  • Work with SaaS Vendors for Log Access (If Needed): In cases where direct log access is limited, work with SaaS vendors to understand their logging practices and explore options for obtaining log data or security reports necessary for incident investigation or compliance audits.
  • Focus on SaaS Application-Level Logging: Prioritize logging of user actions, data access, configuration changes, and security-relevant events within SaaS applications, as infrastructure-level logs are typically managed by the SaaS vendor.

Privacy Considerations for Logging: Implement logging practices in a manner that respects user privacy and complies with applicable data privacy regulations.

  • Minimize Collection of Personally Identifiable Information (PII) in Logs (Where Possible): Log only necessary information for security and operational purposes. Minimize logging of PII where possible, or implement data masking or anonymization techniques for sensitive data in logs.
  • Access Control Based on Privacy Considerations: Restrict access to logs containing PII to only authorized personnel with a legitimate need to access such data, and in compliance with privacy policies and regulations.
  • Transparency and User Awareness (General): While detailed log data is typically not shared with general users, maintain general transparency about system monitoring and logging practices in the institution's Data Privacy Policy and Acceptable Use Policy.

POLICY EXCEPTIONS: 

Exceptions to the mandatory logging requirements or log retention periods may be granted in limited circumstances by the Chief Information Officer or designated authorization authority, with appropriate justification, risk assessment, and compensating security controls documented and implemented. Exceptions should be rare and subject to periodic review.

ENFORCEMENT:

Enforcement of this System Monitoring and Logging Policy is the responsibility of all managers, supervisors, IT administrators, system administrators, application administrators, SaaS application administrators, and users, under the overall direction of the Chief Information Officer and the Information Technology Office. Failure to implement required logging, improperly managing logs, unauthorized access to logs, or other policy violations may result in disciplinary actions, up to and including warnings, suspension of system access, and termination of employment or access privileges, and potential legal or financial consequences, particularly in cases of negligence leading to undetected security breaches or compliance violations. The Information Technology Office will monitor compliance with this policy, audit logging configurations, and investigate reported violations or logging deficiencies.

POLICY REVIEW AND UPDATES:

This System Monitoring and Logging Policy and associated procedures will be reviewed and updated at least annually, or as needed to reflect changes in technology, security threats, logging best practices, regulations, institutional risk assessments, business needs, or advancements in monitoring and log management technologies. The Chief Information Officer is responsible for coordinating policy reviews and updates, in consultation with IT Department, relevant system and application administrators, and compliance stakeholders.

 

PRIMARY POLICY OWNER: 

Chief Information Officer

 

APPROVAL:

Effective: 7/8/25

Last Reviewed: 7/8/25

Review Requirement: Annual

Related articles