Information Security Incident Response Team (ISIRT)

1.0 Preface
2.0 ISIRT Responsibilities
3.0 ISIRT Membership
4.0 Security Incident Response Process
5.0 Related Documents

1.0 Purpose

The Information Security Incident Response Team (ISIRT) is critical to protecting Brown University's IT systems and infrastructure, providing emergency response to significant information security incidents at Brown. A breach of infrastructure directly supported by Brown IT staff will invoke the ISIRT based on an incident’s level of severity and the systems affected. Response to a breach of Brown University data under the control of a third-party vendor will be coordinated by the Director of Information Technology Security and VP/CIO of Computing and Information Services, who determine the appropriate communication required.

2.0 ISIRT Responsibilities

The ISIRT responds to and manages Brown University’s information security incidents. These are generally defined as malicious activity that threatens the University's computing infrastructure, and are characterized by an unauthorized entity gaining access to Brown computing or network services, equipment or data.

Categories of incident types, which are constantly evolving, include but are not limited to the following:

  • Denial of Service attacks
  • Rapidly spreading or highly virulent malicious code (e.g., malware, ransomware, worms, trojans)
  • Compromised servers or accounts
  • Unauthorized access to protected IT services by Brown community members or others
  • Unauthorized utilization of services by Brown community members or others
  • Requests for technical support for investigations approved by authorized Brown representatives, on behalf of the University

In addition to identifying threats to Brown’s computing environment, the ISIRT is responsible for:

  • Coordinating appropriate responses to counter malicious threats
  • Monitoring new and developing security issues that may affect computing and information services
  • Developing group-level response procedures so that there is archival documentation and clear understanding of roles across CIS and non-CIS groups
  • Periodically reviewing incident response processes and making recommendations for improvements
  • Conducting periodic table-top exercises
  • Building comprehensive strategies around emerging threats

The procedures used by ISIRT members and other IT technical support staff (system administrators, departmental computing coordinators, et.al.) with regard to security incidents are under the authority and control of the Director of Information Technology Security in CIS.

3.0 ISIRT Membership

The ISIRT is overseen by the  Director of Information Technology Security, who has the authority to develop guidelines and requirements to meet the security needs of users and to safeguard the University's systems from threats. The ISIRT is composed of key IT personnel in CIS representing the following areas: network technology, infrastructure services, endpoint engineering, and the IT Service Desk.

In addition, depending on the incident and level of severity, the following offices may be called upon to support the work of the ISIRT: Office of University Communications, Office of Internal Audit Services, Government Relations & Community Affairs, Office of the General Counsel, Human Resources, Office of the Provost and Department of Public Safety. Subject matter experts and others will be added as necessary.

4.0 Security Incident Response Process

While the details of each incident response may vary, the process generally includes the following phases:

  • Response Phase: Conduct a triage of the incident, assist in containment of the incident, collect evidence for the post mortem report and if necessary, conduct or assist in a forensic investigation.
  • Recovery Phase: Damage assessment, return to normal operations, rebuilding servers and systems, etc.
  • Follow-up Phase: Sending final incident reports to parties with a need-to-know

5.0 Related Documents

Questions or comments to: ITPolicy@brown.edu

Effective Date: November, 2016
Last Reviewed: March, 2017
Next Scheduled Review: March, 2018