UCF Security Incident Response Plan High Level



Similar documents
Minnesota State Colleges and Universities System Procedures Chapter 5 Administration. Guideline Information Security Incident Response

Information Security Incident Management Guidelines

Data Security Incident Response Plan. [Insert Organization Name]

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

CREDIT CARD MERCHANT PROCEDURES MANUAL. Effective Date: 5/25/2011

Information Resources Security Guidelines

LAMAR STATE COLLEGE - ORANGE INFORMATION RESOURCES SECURITY MANUAL. for INFORMATION RESOURCES

RUTGERS POLICY. Section Title: Legacy UMDNJ policies associated with Information Technology

Computer Security Incident Response Team

CHAPTER 1 COMPUTER SECURITY INCIDENT RESPONSE TEAM (CSIRT)

Cyber Security Incident Handling Policy. Information Technology Services Center (ITSC) of The Hong Kong University of Science and Technology

Computer Security Incident Response Team

Information Security Plan May 24, 2011

R345, Information Technology Resource Security 1

Ellucian Cloud Services. Joe Street Cloud Services, Sr. Solution Consultant

SITA Security Requirements for Third-Party Service Providers that Access, Process, Store or Transmit Data on Behalf of SITA

Utica College. Information Security Plan

Anatomy of a Breach: A case study in how to protect your organization. Presented By Greg Sparrow

Page 1 of 15. VISC Third Party Guideline

Vulnerability Management Policy

CITY UNIVERSITY OF HONG KONG Information Security Incident Management Standard

DUUS Information Technology (IT) Incident Management Standard

Information Technology Policy

plantemoran.com What School Personnel Administrators Need to know

IMS-ISA Incident Response Guideline

The University of Tennessee Chattanooga Incident Response Plan

Computer Security Incident Response Plan. Date of Approval: 23- FEB- 2015

IT Security Incident Management Policies and Practices

Responsible Administrative Unit: Computing, Communications & Information Technologies. Information Technology Appropriate Use Policy

micros MICROS Systems, Inc. Enterprise Information Security Policy (MEIP) August, 2013 Revision 8.0 MICROS Systems, Inc. Version 8.

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

Standard: Information Security Incident Management

Incident and Disaster Tolerance/Response Policy

Information Security

Client Security Risk Assessment Questionnaire

Information Security Program CHARTER

University of Pittsburgh Security Assessment Questionnaire (v1.5)

Cyber Incident Response

Computer Security Incident Reporting and Response Policy

UBC Incident Response Plan

Information Security Program

Data Management Policies. Sage ERP Online

University of Colorado at Denver and Health Sciences Center HIPAA Policy. Policy: 9.2 Latest Revision: 04/17/2005 Security Incidents Page: 1 of 9

Attachment A. Identification of Risks/Cybersecurity Governance

Data Management & Protection: Common Definitions

Miami University. Payment Card Data Security Policy

Information Security Program Management Standard

UMHLABUYALINGANA MUNICIPALITY PATCH MANAGEMENT POLICY/PROCEDURE

Sierra College ADMINISTRATIVE PROCEDURE No. AP 3721

AUGUST 28, 2013 INFORMATION TECHNOLOGY INCIDENT RESPONSE PLAN Siskiyou Boulevard Ashland OR 97520

Title: Data Security Policy Code: Date: rev Approved: WPL INTRODUCTION

Host Hardening. Presented by. Douglas Couch & Nathan Heck Security Analysts for ITaP 1

IBX Business Network Platform Information Security Controls Document Classification [Public]

BALTIMORE CITY COMMUNITY COLLEGE INFORMATION TECHNOLOGY SECURITY PLAN

University of Sunderland Business Assurance Information Security Policy

Cal Poly Information Security Program

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

Virginia Commonwealth University School of Medicine Information Security Standard

INFORMATION SECURITY California Maritime Academy

California State University, Chico. Information Security Incident Management Plan

Information Security Policy

Bendigo and Adelaide Bank Ltd Security Incident Response Procedure

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

CREDIT CARD SECURITY POLICY PCI DSS 2.0

FACT SHEET: Ransomware and HIPAA

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

Information Security: Roles, Responsibilities, and Data Classification. Technology Services 1/4/2013

STATE OF NEW JERSEY Security Controls Assessment Checklist

C. Author(s): David Millar (ISC Information Security) and Lauren Steinfeld (Chief Privacy Officer)

BSM for IT Governance, Risk and Compliance: NERC CIP

FINAL May Guideline on Security Systems for Safeguarding Customer Information

Policies and Procedures Audit Checklist for HIPAA Privacy, Security, and Breach Notification

Business & Finance Information Security Incident Response Policy

Incident Response Team Responsibilities

University of Wisconsin-Madison Policy and Procedure

HIPAA Compliance: Are you prepared for the new regulatory changes?

A Websense Research Brief Prevent Data Loss and Comply with Payment Card Industry Data Security Standards

Security Is Everyone s Concern:

DATA BREACH NOTIFICATION POLICY

Credit Card (PCI) Security Incident Response Plan

GEARS Cyber-Security Services

Marist College. Information Security Policy

Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH)

CSIRT Introduction to Security Incident Handling

Supplier Security Assessment Questionnaire

Incident Response Guidance for Unclassified Information Systems

Security Controls What Works. Southside Virginia Community College: Security Awareness

John Essner, CISO Office of Information Technology State of New Jersey

WEST LOTHIAN COUNCIL INFORMATION SECURITY POLICY

Iowa Health Information Network (IHIN) Security Incident Response Plan

Transcription:

UCF Security Incident Response Plan High Level Chris Vakhordjian Information Security Officer Computer Services & Telecommunications Division of IT&R Revision 1.1, 7 June 2007 Information Security Office Page 1 of 6

UCF Security Incident Response Plan PREAMBLE: To properly respond in a consistent manner, with appropriate leadership and technical resources, to an incident that threatens the availability, confidentiality and integrity of information resources or violations of acceptable use policy. A swift response to an incident that threatens the confidentiality, integrity, and availability of university information assets and the networks that deliver the information, is required to protect those assets. Without a rapid response, those assets could be compromised and the University could be in violation of Federal, State, or Local statutes and in violation of its own policies. The security incident response process may start with an explicit report of a security breach, but it is more likely to start as the result of a routine investigation into some anomalous system or network behavior. For example, a server may be operating slowly, or the printing service may stop working. Because of the potential for unauthorized release or modification of data, in addition to service disruption, it is important to assess the possibility that strange behavior may be the result of some security problem before taking steps to correct a normal problem. When it is determined that an incident may be security related, then the nature of the recovery effort must be modified and appropriate personnel need to be involved to ensure that appropriate information is collected and documented to determine the nature and scope of the security breach and, if appropriate, to facilitate an investigation by law enforcement. Depending on the nature and scope of a breach, it may be necessary to make public disclosure which will require the involvement of campus executives and managers. SCOPE: This procedure applies to all university information systems and services with the exception of disaster recover procedures. PROCEDURES: The Security Incident Response Flowcharts provide the process for responding to a security-related incident. While following this process, it is important to keep the following in mind: Discovery o The security incident response process may start with an explicit report of a security breach, or from a routine investigation into some anomalous system or network behavior, or from a vulnerability scan results, or from a formal infringement notification from the RIAA or DMCA, or from internal sources reporting of violations of acceptable use policy, or suspicions activities from intrusion detections systems, etc. Document o The key to proper investigation is proper documentation. The discovery of an incident needs to be properly documented within the NOC incident response web site Notification o Information must be shared with individuals involved in the investigation o It is important that all members of the Security Incident Response Team are up to date as events unfold. Much of the information, however, may be confidential, so care should be taken to protect confidentiality of discussions Information Security Office Page 2 of 6

Acknowledgment o Initial notifications regarding an incident must be acknowledged to demonstrate action will be taken immediately to contain the incident Containment o Swift containment is necessary to prevent the spread of worms, further compromise or disclosure of information. Containment of the incident and investigation may be pursued simultaneously Investigation o After an incident has been contained, system can be freely investigated. Document all action taken in the NOC incident response web site Eradication o Eradication may be necessary to eliminate components of the incident such as deleting malicious code or disabling breached user accounts Recovery o Recover to normal operations o Harden systems or processes to prevent similar incidents Closure o Review incident and close open incidents The CS&T Security Incident Response Team (SIRT) The UCF Information Security Officer will select CS&T staff from selected CS&T Organizational Units deemed technically proficient to provide assistance in his/her specific area to work collaboratively in responding to a security incident. The following CS&T Organizational units will be used for SIRT: Unit UCF Information Security Office ITR CTO NOC Security Group NOC/TeleData Computer Shop UCF Technology Based Crime Unit CS&T Systems Group Technology Integrators Group Local SysAdmin, head IT, IT manager, etc., or other units when necessary General Counsel s Office (GCO) UCF News and Information Purpose ISO s direction and supervision CIO s direction and supervision CTO s direction and supervision Networking security expertise Network and Helpdesk expertise System and hardware expertise Forensic expertise Systems expertise Programming expertise Local expertise within their own IT environment Regulation and policy expertise Public communications and responding to the press The UCF Information Security Officer may from time to time add additional staff or deputize departmental ITes for the process of investigating a security incident. Information Security Office Page 3 of 6

The Security Incident Response Team (SIRT) is tasked with the following responsibilities: SIRT continually updates the Security Incident Response Plan SIRT maintains systems for discovering security incidents involving UCF IT resources SIRT documents IT security incidents in a tracking system (soon to be within Remedy) SIRT will coordinate IT security incidents (level 2/3) from documentation to closure o SIRT reviews incidents, provides solutions/resolutions and closure. SIRT will assess threats to IT resources SIRT will process IT security complaints or incidents SIRT will alert IT managers of imminent threats SIRT determines incident severity and escalates it, if necessary, with notification to CIO, CTO, and ISO. Incident severity classification Level 1 Incident Security incident involving Unrestricted Data Data not protected by law or contract, or whose disclosure would cause no harm to the university or to individuals Local SysAdmin responsible for containment, investigation, rebuild, and hardening system. Properly document the incident, report to DSC, SysAdmins, SIRT, closure. Contact SIRT at sirt@mail.ucf.edu with details of the compromise Level 2 Incident Security incident involving Restricted (non-personal) Data Data whose unauthorized access, modification or loss could adversely affect the university (e.g., cause financial loss or loss of confidence or public standing in the community), adversely affect a partner (e.g., a business or agency working with the university), or adversely affect the public. Local Admin and SIRT (sirt@mail.ucf.edu) are responsible for the response based on SIRT Plan. Level 3 Incident Security incident involving Restricted (personal) Data Data including Personally Identifiable Information (PII): a) information from which an individual may be uniquely and reliably identified or contacted, including an individual s social security number, account number, and passwords; b) information protected under the FERPA regulations and other non-directory information interpreted by the University; c) information concerning an individual that is considered nonpublic personal information within the meaning of Title V of the Gram Leach Bliley Act of 1999 (Public Law 106-102, 11 Stat. 1338) (as amended) and its implementing regulations, and; d) information concerning an individual that is considered protected health information within the meaning of the Health Insurance Portability and Accountability Act of 1996 (as amended), and its implementing regulations. Protection for such data may also be subject to additional operating regulations in accordance with vendor or partner agreements, such as the Payment Card Industry Data Security Standards (PCI DSS) Local Admin and SIRT (sirt@mail.ucf.edu) are responsible for the response based on SIRT Plan. Information Security Office Page 4 of 6

General Incident Response Process Process People Pre-Incident Incident Detection Third party, internally reported, SysAdmin SIRT, NOC Security Group Notification to SysAdmin, ISO, and SIRT SIRT, SysAdmin or NOC Security Group SysAdmin and/or SIRT conducts initial investigation and documents findings SysAdmin, SIRT member or delegate No Is it really an Incident? SysAdmin, SIRT, CIO, CTO, ISO, VP Yes Is incident severity level 1? Yes SysAdmin, SIRT, ISO, DSC Closure/End No Activate SIRT CIO, CTO, ISO, VP SIRT investigates and determines initial response CIO, SIRT, CTO, ISO Is it really an Incident? CIO, SIRT, CTO, ISO No Yes Information Security Office Page 5 of 6

Execute Response strategy based on this plan CIO, CTO, ISO, SIRT, SysAdmin Communicate as appropriate SIRT, DSC, Dean, Chair, VP, GCO, Registrar, UCF News & Info Continue Investigation and Restoration and document findings SysAdmin, SIRT Collect Evidence Apply security measures Preserve log files Forensic backup if necessary Isolate/Contain system if necessary SysAdmin, NOC Security Group, UCF Technology Based Crime Unit (TBCU) Monitor system and network Return to normal operation SysAdmin Identify and implement security/lessons learned SysAdmin, NOC Security Group, SIRT Develop final report and communicate findings SIRT Closure SIRT Information Security Office Page 6 of 6