Feedback

7-7: SFCC Information Technology Incident Response Procedures

  1. CSIRT Documentation
    Cyber Security Incident Response Team (CSIRT) documents, including membership and responsibilities, are available internally or in designated physical locations. These documents are confidential and accessible only to CSIRT members and assigned stakeholders.
  2. Monitoring
    Office of Information Technology (OIT) and CSIRT utilize a range of tools and methods to prevent, detect, monitor, and recover from security incidents. These include:

    • Logging and proactive monitoring
    • Identity and Access Management (IAM), including:
      – Single Sign-On (SSO)
      – Role-Based Access Control (RBAC)
      – Multi-Factor Authentication (MFA)
      – Centralized access control
    • Endpoint Detection and Response
    • Data Encryption
    • Firewalls, including Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS)
    • Patch management
    • Penetration testing
    • Vulnerability scanning
    • Cybersecurity training for all employees (student training may be offered in the future)
    • End-user reporting of suspected incidents.
    • Examples of incidents include:
      • Social engineering attacks (e.g., phishing, spoofing)
      • Malware infections
      • Unauthorized access to systems or data
      • Breaches involving sensitive or confidential data (digital or physical)
      • Distributed Denial of Service (DDoS) attacks
      • Ransomware
      • Insider threats
      • Man-in-the-middle attacks
      • Zero-day exploits
      • Compromised credentials
      • Cryptojacking
  3. Planning
    OIT and CSIRT proactively develop and maintain incident response plans, runbooks, and related documentation. These include:

    • Incident Response and Handling Plans
    • Incident Runbooks
    • Incident Documentation
    • Incident Response RACI Matrix
    • Incident Response Communication Plans
    • Documentation of lessons learned
    • Documentation of Incidents
      All system owners must maintain an incident response and handling plan. A system owner is defined as anyone with primary responsibility for the security and management of a technology system or service.
      This is especially critical for systems where OIT lacks access or control, such as:
    • Department-managed websites
    • Department-managed Cloud services
    • Data sharing agreements or MOUs that involve storing data
    • Systems with decentralized access management
    • Assistance in developing these plans can be requested via the OIT Service Desk or directly through the CIO. All response plans must include notification to the OIT Service Desk in the event of a known or suspected incident.
  4. Response
    OIT may need to respond rapidly to incidents to protect the college’s IT Resources. The severity and impact of the incident will determine the response. While we will attempt to communicate in advance, circumstances may not allow for this.  Possible actions may include:

    • Temporarily disabling accounts
    • Credential resets
    • Shutting down systems or services
    • Bulk removal of spam or malicious messages
    • Isolating systems or devices
    • Revoking access or privileges
    • Creating new accounts
    • Replacing compromised systems or services
    • Rebuilding of systems
    • Immediate patching and enforced reboots
  5. Incident Response Testing
    CSIRT will coordinate Incident response testing each fiscal year. Stakeholders may be required to participate. These stakeholders may include:

    • System Owner
    • HR
    • Legal
    • Student Services
    • Finance
    • Security
    • Testing will include:
    • Walk-through of incident scenario(s)
    • Review of related incident response and handling plan documentation and processes.
  6. Exceptions
    Requests for exceptions must be submitted to the OIT Service Desk for review by the CIO or designated CSIRT member.
    Requests must include:

    • Reason for the exception
    • Technical or logistical barriers to compliance
    • Risk to the organization from non-compliance
    • Mitigating controls or standards proposed as alternatives
  7. User Risk and Violations
    Users may be held liable for data breaches, damage to IT resources, theft of IT resources, or loss of data that occur due to user negligence.

View 7-7 Policy.