Skip Navigation
Skip to Menu Toggle Button
UMGC Policy X-1.07

Information Security Audit and Accountability

Policy CategoryPolicy OwnerVersion Effective DateReview CyclePolicy Contact
X. Information Governance, Security & TechnologyChief Transformation OfficerMarch 28, 2023Every 3
  1. Purpose

    The purpose of this policy is to establish information security standards for the Security Log collection, analysis, reporting, and retention activities that support the audit and accountability processes relevant to University of Maryland Global Campus ("UMGC" or "University") Information Technology Resources.

  2. Scope and Applicability

    This policy applies to all University Information Systems and Information Technology Resources. All Users are responsible for adhering to this policy.

  3. Definitions

    Capitalized terms shall have the meaning ascribed to them herein and shall have the same meaning when used in the singular or plural form or any appropriate tense.

    1. Audit Record Reduction: An automated process that interprets raw audit log data and extracts meaningful and relevant information without altering the original logs. An example of log reduction for files to be analyzed would be the removal of details associated with nightly backups. Report generation on reduced log information allows you to create succinct customized reports without the need to burden the reader with unimportant information.
    2. Audit Trail: A set of records that collectively provide documentary evidence of processing used to aid in tracing from original transactions forward to related records and reports, and/or backwards from records and reports to their component source transactions.
    3. Authorized User: A user who has been granted authorization to access electronic Information Resources and is current in their privileges.
    4. Contractor: A person or a company that undertakes a contract to provide materials or labor to perform a service.
    5. Employee: University staff and faculty, including nonexempt, exempt, and overseas staff and collegiate faculty.
    6. Information System: Inter-related components of Information Technology Resources working together for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
    7. Information System Steward: A UMGC staff member or other individual providing services to the University who is responsible for the development, procurement, compliance, and/or final disposition of an Information System.
    8. Information Technology Resource: Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by UMGC directly or by a third party under a contract with UMGC which requires the use of such equipment. The term includes computers, mobile devices, software, firmware, services (including support services), and UMGC's network via a physical or wireless connection, regardless of the ownership of the Information Technology Resource connected to the network.
    9. Privileged User: A user that is authorized to perform security-relevant functions that ordinary users are not authorized to perform.
    10. Reporting: The final phase of the computer and network forensic process, which involves reporting the results of the analysis; this may include describing the actions used, explaining how tools and procedures were selected, determining what other actions need to be performed (e.g., forensic examination of additional data sources, securing identified vulnerabilities, improving existing security controls), and providing recommendations for improvement to policies, guidelines, procedures, tools, and other aspects of the forensic process. The formality of the reporting step varies greatly depending on the situation.
    11. Security Log: Security logs are records of events occurring within the university's systems and networks. A security log is a specialized Audit Trail that captures information associated with information security-related events. Specifically, security logs: 1) can identify anomalies for further analysis and potential remediation; 2) allow for 24/7 monitoring of security-related issues; and 3) are critical for successful forensic examination of events related to security incidents.
    12. User: A member of the University community, including but not limited to Staff and Faculty, and other individuals performing services on behalf of University, including Contractors, volunteers and other individuals who may have a need to access, use or control University Data.
  4. Audit and Accountability
    Information System Stewards should adhere to the University's Audit and Accountability Policy when managing University Information Technology Resources to ensure the creation, protection, and retention of system logs to monitor, analyze, investigate, and report unauthorized activity occurring on University systems.
    1. Actions of individual system users should be uniquely traced to those users so they can be held accountable for their actions.
    2. Information System Stewards need to capture information in audit logs. This ensures that they can trace the actions that they audit to a specific user. This may include capturing information from users, including but not limited to:
      1. What type of event occurred;
      2. When the event occurred (i.e. time stamps);
      3. Where the event occurred;
      4. Source of the event;
      5. Outcome of the event (i.e. success or fail indications, event-specific results); and Identity of any individuals, subjects, or objects/entities associated with the event.
    3. Security Logs should be created and retained to the extent needed to enable the monitoring, analysis, investigation, and Reporting of unlawful or unauthorized system activity. Audit logs must be retained for a minimum of 60 days. Official records should be retained in accordance with the UMGC Records and Information Management Policy.
    4. System capabilities should be provided that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
    5. Security Logs shall be reviewed periodically and at a minimum, quarterly.
    6. All security events found shall be reported to
    7. Updated logged events shall be reviewed on an annual basis.
    8. Alerts shall be configured that will be triggered in the event of a Security Logging process failure.
    9. Automated notifications need to be sent to designated security personnel to immediately take appropriate action.
    10. If technically and administratively feasible, audit information should be collected (e.g., logs) into one or more central repositories.

      For example – Information System Stewards should aggregate and store audit logs in a centralized location or locations within the organization. Storing audit logs in a centralized location supports orchestration, automation, correlation, and analysis activities by enabling a full picture of the audit logs and can support automated analysis capabilities including correlation of events across the enterprise. Information System Stewards should ensure that the central repository has the appropriate infrastructure, including protection mechanisms, and the capacity level to meet the logging requirements of the organization.
    11. Audit information and audit logging tools should be protected from unauthorized access, modification, and deletion.
    12. Security Logs should be properly secured so that the information may not be modified or deleted, either intentionally or unintentionally. Only those with a legitimate need-to-know should have access to audit information, whether that information is being accessed directly from logs or from audit tools.
    13. Management of audit logging functionality should be limited to a subset of Privileged Users.
    14. Audit logging functions should have restricted access by a limited number of Privileged Users that can modify Security Logs and audit settings.
    15. Audit record review, analysis, and reporting processes should be correlated for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
    16. Audit record reduction and report generation should be provided to support on-demand analysis and reporting. In addition, the security relevant audit information must be made available to personnel on-demand for immediate review, analysis, reporting, and event investigation support.
  5. Exceptions

    Exceptions to this policy should be submitted to the Sr. Director, Information Security for review and approval. If an exception is requested a compensating control or safeguard should be documented and approved.

  6. Enforcement
    1. Any Employee, Contractor, or third-party performing duties on behalf of the University with knowledge of an alleged violation of this Policy shall notify the Sr. Director, Information Security as soon as practicable.
    2. Any Employee, Contractor, or other third-party performing duties on behalf of the University who violates this Policy may be denied access to Information Resources and may be subject to disciplinary action, up to and including termination of employment or contract or pursuit of legal action.
  7. Standards Referenced
    1. USM IT Security Standards, v.5, dated July 2022
    2. NIST SP 800-171r2 “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” dated February 2020.
    3. Cybersecurity Maturity Model Certification (CMMC), v.2.0, December, 2021
  8. Related Policies
    1. UMGC Policy X-1.02 Data Classification 
    2. UMGC Policy X-1.03 Records & Information Management
    3. UMGC Policy X-1.04 Information Security 
    4. UMGC Policy X-1.06 Information Security Incident Response
    5. UMGC Policy X-1.08 IT Resources Configuration Management
    6. UMGC Policy X-1.10 Identity and Access Management
    7. UMGC Policy X-1.12 Acceptable Use
    8. UMGC Policy X-1.22 System and Information Integrity
  9. Effective Date: This policy is effective as of the Version Effective Date set forth above.