Incident Response Notes

http://www.securityfocus.com/infocus/1467

How to Design a Useful Incident Response Policy Timothy E. Wright 2001­10­02 How to Design a Useful Incident Response Policy  by Timothy E. Wright  last updated September 18, 2001  Perhaps you're the Information Security Officer for your company. Or, maybe you're a technology auditor. Maybe you're in  charge of data security for your university's computing department. Regardless of your title and circumstances, you've been  working on implementing an information security program (you have been working on your program, right?!) Such an  endeavor has a tremendous scope, requiring great feats of perception and planning. This article aims to help you with an  important facet of any information security program: the incident response policy.  Policy: Does Anybody Read This Stuff?  Policy: lifeblood of bureaucrats! But does anyone actually read policy? In truth, any properly constructed information security  policy can perform several worthwhile services. First, it acts as an informed guide for your organization's information  activities: good policy can help an organization manage its security risks better. Next, it brings structure to chaos: sensible  rules and recommendations, tailored to your organization, can resolve confusion about handling information under different  circumstances. Finally, it streamlines activities in the face of a security issue. If people know what to do and when to do it,  they will be able to protect their organization through decisive and correct responses.  In addition to these pragmatic functions, there is, in fact, another benefit that good information security policy can perform.  Good policy can demonstrate that an organization has thought through its information security needs, and has properly  configured itself to meet these needs. In some instances, there may be a legal requirement for this! For example, the Gramm­ Leach­Bliley Act (GLB) states very clearly that "...each financial institution has an affirmative and continuing obligation to  respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal  information." (In fact, GLB requires that financial institutions document and implement a full­blown information security  program.) In other situations, an organization may have to present a cogent information security program in order to conduct  business.  Towards a Useful Policy  Having established the reasons for devising information security policies, we can now consider the elements of truly useful  policy. Good information security policy should be succinct, understandable, practicable, cooperative, and dynamic. Let's  consider each of these in turn.  Succinct  By succinct, we mean that the policy should be clear and concise. It should be stated as briefly as possible without omitting  any vital information. Long winded policies are more difficult to understand, less likely to be read, and harder to implement.  Understandable  When we say a good policy is understandable we mean that the policy's text actually makes sense within the context of the  organization. As the aphorism from the world of business an aphorism states, there are two types of people: those who don't  manage what they understand, and those who don't understand what they manage.  In the realm of information security, sense can only be achieved if the person writing the policies has a grasp of information  security concepts as well as their organization's structure and purpose.  Practicable 

Regardless of how succinct and understandable a policy might be, if it isn't possible to practice it's worthless. A great example  of this issue would be the implementation of a policy prohibiting the connection of modems to server machines in an  organization that has a service contract in place whereby a software vendor must dial into a server to do maintenance. An  example related to incident response might be a policy stating that members of a response team have to be reachable 24 hours  a day, even though no reliable means of contact is provided by the company except when the members are at work. Policies  that aren't practicable are not only, by definition, ineffective, they are also quickly ignored by an organization's employees.  Cooperative  A good information security policy is cooperative in that it is crafted and maintained with the input of all relevant departments  within an organization. In general, information security can only succeed when everyone participates. Where incident response  is concerned, departments such as Legal, Human Resources, Public Relations, Audit, and Information Technology all have to  contribute to the creation and review of policy documentation. During an incident response it's very likely that some or all of  these departments will play a significant role in the management of the situation. If relevant departments haven't given their  endorsement for a policy, the policy is sure to experience problems during implementation.  Dynamic  Finally, any useful information security policy is dynamic in that it is capable of changing and growing with an organization.  The rate at which technology changes is immense. And while organizations may or may not keep pace with this, they  inevitably must make changes and minor course corrections as a result of the technologies they deploy. It would be negligent to  create an information security policy and believe that the needs it serves today will be adequate in the long run.  Incident Response: Where the Rubber Meets the Road in the Information Security Program  Much of an organization's information security program is passive. Policies that prescribe how systems are to be used,  passwords to be managed, and system audit activities to take place are all designed to prevent something bad from happening.  In contrast, items like disaster recovery and incident response are entirely action oriented. In fact, in many ways, responding to  an incident is similar to responding to a disaster: money, public relations, and time are all considerations. Of course, for  incident response, the level of success is inversely proportional to the degree of public relations exposure.  No organization wants to appear as though they have a weak information security posture. Such an appearance can tarnish the  corporate image, precipitate law suits, attract unwanted hacker attention, and damage good will. Yet, there is no such thing as  fool­proof security: sooner or later, all organizations must respond to a security incident. The speed and decisiveness with  which an organization can mount its response will determine whether or not a serious incident turns into a nightmare. If the  response is methodical and well orchestrated, invariably the incident will be controllable.  A poor response capability equals financial and public relations trouble. How is this risk managed? By devising an effective  incident response policy from the outset. Such a policy's documentation will consist of the following sections: background,  definitions, incident classification, reporting, business continuity, process flow, and example incidents.  Background  All policies need to have a background section in order to explain the motivation and purpose driving the policy. For incident  response the objective is somewhat obvious: to adequately respond to electronic incidents that take place within an  organization's purview. This background not only identifies the objectives of the incident response policy, it provides the  context within which those objectives will be met.  Definitions  Here, the policy will need to define exactly what an electronic incident is. Are we talking about computer fraud and computer  abuse (the difference being that computer fraud is a crime whereas computer abuse is a policy violation)? What about  incidents that are accidental on the part of the organization or a vendor? Does this type of activity warrant an incident response  or something more low­key? Unfortunately, this article cannot answer these questions, since the answers will be contingent  upon your organization's goals and priorities. A good tip, however, would be to carefully read through any regulations (e.g.  GLB, FERPA, etc.) that apply to you and grasp the totality of what they are requiring. 

Another item that requires definition is that of the Computer Emergency Response Team (CERT). An incident response policy  won't be practicable unless there is someone who puts that policy into action during an incident. The CERT must be a highly  skilled and available group. Members should represent expertise within the various information systems belonging to an  organization, be on call twenty­four hours a day, and be capable of responding within a nominal amount of time. There should  be backup available for when members are out of town or on vacation. Members of the CERT need to be familiar with the  fundamentals of gathering and handling computer evidence.  Incident Classification  To be effective in managing its incident response process, an organization should create an event classification system. Such a  system will enable the filtering of background noise from items that are more serious: for example, does an organization really  need to respond to every port scan. One effective approach is to assign events a degree of urgency and then further assign a  priority ranking to anything of high urgency. Incidents that fall into the low and medium urgency classes may be logged, with  medium events being examined later on by a system administrator. High urgency events would be treated immediately. This  response would require the attention of other relevant departments and groups.  An escalation list should be used for all incidents. Such a list designates responsibilities for incidents in which the degree of  urgency increases as the incident progresses. As an event increases in urgency and priority, an appropriate individual further  up the escalation list is contacted. Ultimately, for incidents of the highest urgency and priority, the CERT is activated.  As an incident escalates, it is likely that departments other than network administration will need to become involved.  Executive management will have to be very careful to not hamper the CERT's ability to do its job (e.g. by assigning it  unreasonable or time consuming chores). The Legal and Public Relations departments may also need to become involved. If  the situation warrants it, executive management should be prepared to contact law enforcement.  Note that an organization's information system vendors should be included on the escalation list. In particular, relevant vendors  should provide a twenty­four hour contact and be given such a contact at the organization. It is also recommended that some  type of information security service level agreement be included in any contract between an organization and its vendors.  Reporting  Before, during, and after an electronic incident, various kinds of data will be gathered. How will these data be processed, and  to whom will they be presented? Very little beyond intrusion detection system and server audit logs will be available for  reporting during normal business operations. However, when an incident is being managed there is a great potential for  additional information. For example evidence that might be collected, additional log data, and documentation of the incident  can all contribute to the data available. After an incident has passed there will no doubt be new information pertaining to the  aftermath: what the incident has cost the organization, what resources will be needed to fully recover, etc. It's important for the  incident response policy to outline when reports are generated, what they will contain, and to whom they will be made  available.  Business Continuity  A crucial element to consider in a useful incident response policy is that of business continuity. In the event that a serious  incident should take place, a decision to halt certain information systems may need to be made. For example, during a denial of  service attack it may be better to undergo a self­imposed service outage rather than wait for an overwhelming flood of service  requests. Who should be responsible for determining when to pull the plug on a service, and under what circumstances is this  an option? This needs to be set out in the Incident Response Policy. The converse is also of importance: who should be allowed  to re­enable a service, and under what circumstances? As with other difficult policy questions, answers will vary from  organization to organization.  Process Flow  Now we come to the heart of the incident response policy; it is within the process flow that the steps for response are outlined.  The flow should start wherever an incident comes into being, and then trace the incident via the classification system up to the  point where the CERT and other departments are notified. It's a good idea to use both a written description and diagram to  describe the incident response process. Also, be sure to include a means for dealing with incident response at a vendor's site.  Here is a very simplistic process flow that follows the classification system discussed above. 

Example Incidents  The last element to be included in a useful information security policy is a table of example incidents and responses. The  concept here is to provide sample incidents of varying degrees of nastiness, along with brief response summaries. The effect of  such a table is two­fold. First, it will help you to think through the application of your response policy in a variety of situations.  This is a great way to search for inadequacies within a policy's process. Second, a table of examples will anchor an incident  response policy to the real world. It will allow an organization to better comprehend why the policy is needed.  Conclusion  By now, Information Security has become part and parcel of most organizations' business processes. This entails the  development and deployment of useful policies to control and monitor information systems, and respond to electronic  incidents. Without an incident response policy an organization will be unable to properly respond to an information security  event. This can lead to a loss of money, bad public relations, and even additional security risks. The ingredients of a useful  incident response policy include the following components: background, definitions, incident classification, reporting, 

business continuity, process flow, and example incidents. 

http://www.datasecuritypolicies.com/tag/incident-response-policy

Sample Incident Response Policy Cynthia Bonnette, the Director of Information Security Risk Assessment for NETBankAudit in Arlington, VA wrote a sample  incident response policy which appeared in this issue of the AML Compliance Alert here. Here’s an exerpt: INCIDENT IDENTIFICATION, CLASSIFICATION AND ESCALATION Once detected, suspected incidents (e.g., anomalous activity) must be reported. The nature and severity of the incident will  determine the appropriate response strategy. The Information Security Officer (ISO) or Security Officer classifies the threat  severity based on the definitions below. The ISO or Security Officer is also responsible for determining when to escalate or  downgrade the severity level of an incident based on changes in circumstances and the discovery of additional information. Severity levels are as follows: High. A high level event is an event that can cause significant damage, corruption, or loss (compromise) of confidential,  critical and/or strategic bank and customer information. The event can result in potential damage and liability to the bank and  to its public image and may degrade customer confidence concerning the bank’s products and services (e.g., online banking).  Examples: computer intrusions, compromise of critical information, widespread virus infection, attacks against the IT  infrastructure (e.g., domain name servers, firewalls and backup systems) and denial­of­service attacks that disable a critical  service or impede business performance. Medium. A medium level event is an event that may cause damage, corruption, or loss of replaceable information without  compromise or may have a moderate impact on the bank.s operations or reputation. Examples: misuse or abuse of authorized  access, accidental intrusion, confined virus infection, unusual system performance or behavior, system crashes, installation of  unauthorized software, unexplained access privilege changes or unusual after­hour activities. Low. A low level event is an event that causes inconvenience, aggravation, and/or minor costs associated with recovery,  unintentional actions at the user or administrator level, or unintentional damage or minor loss of recoverable information. The  event will have little, if any, material impact on the bank.s operations or reputation. Examples: sharing of passwords, policy or  procedural violations, and scans of bank systems (except online banking or investing systems, which are medium level events). Worth looking at for a jump start on developing your own incident response policy. Check it out!

http://www.corrections.govt.nz/about-us/fact-sheets/managing-offenders/incidentresponse-policy.html

Incident Response Policy The Department of Corrections, through the Public Prisons Service (PPS), currently manages more than 6,000 offenders daily,  at 20 locations throughout the country. The Department contributes to a government key goal of safer communities by protecting the public and reducing re­offending.  As part of protecting the public we need to provide as safe an environment as possible for our people, offenders and the public. As part of its efforts towards achieving these goals, PPS has developed a National Incident Response Policy that identifies how  incidents in prisons will be dealt with to ensure that the response brings the incident to a safe and swift conclusion, minimising  the risk to life and damage to property.

Incident Response Policy Framework Serious incidents in prisons are not common, but when they occur they have the potential to result in injuries to both staff and  inmates, as well as damage to property. To ensure consistency and effectiveness in its response to serious incidents, PPS has  developed an Incident Response Policy Framework. This framework provides for: A structure for incident response, including the level of resource which is applied to different incidents; Different roles and responsibilities for incident response; The establishment of an incident response capability, on an “as required” basis, to perform incident response functions; and Each prison to develop and maintain emergency response plans to assist with the management of incidents and emergencies.

Incident response structure PPS has adopted the Coordinated Incident Management System (CIMS) for managing incident response. This international standard provides a framework for handling incident response, and is particularly useful when coordinating  an incident response with other agencies (e.g. Police, Fire Service, Ambulance Service). Each of the 20 prisons has developed comprehensive emergency response plans that outline how civil defence emergencies and  critical incidents will be managed. The emergency response plans are reviewed at least annually, and are developed based on best practice principles. The  Department uses the SMEAC (Situation, Mission, Execution, Administration and Logistics, Command and Communication)  format for the development of emergency plans. Emergency plans are an important part of the Department’s requirement, under the Civil Defence Emergency Management Act  2002, to continue essential functions to the optimum extent. PPS has developed a business continuity plan (BCP) for each  prison to return the prison site to business as usual quickly and minimise risks during an emergency.

Clear roles and responsibilities for managing incidents/incident response The PPS National Incident Response Policy has clear roles and responsibilities for managing incidents. These guidelines  identify the different roles, and recognise that responsibilities will vary based on the type and seriousness of an incident. A clear statement of role and responsibility will allow all staff to understand the authority for calling up, authorising  deployment and managing the incident when an incident response is required.

Responding to incidents The implementation of this policy (other than for low level incidents) involves mobilising suitably trained and equipped staff  on an ‘as needed’ basis to respond to serious incidents. The policy uses rostered custodial staff who have received additional  training to respond to incidents when and where required. This approach is similar to the New Zealand Police Armed Offenders  Squads (AOS) where AOS members are part­time, drawn from all branches of the Police, and operate on a call­out basis. Staff trained in incident response initiatives will be located at most of the 20 prison sites, and can provide support on a regional  (and where required, national) basis. Specialist training includes negotiation skills, fire fighting and advanced first aid. Comprehensive debriefs are conducted at the conclusion of an incident response. These debriefs are a good opportunity to  review how the incident was managed, and utilise lessons learned for future incident responses. Implementation of the Incident Response Policy has begun and will continue into 2005/06.

http://www.instantsecuritypolicy.com/defs-incident_response_policy.html

Incident Response Policy (aka Incident Response Plan) The Incident Response Policy specifies exactly how the organization will respond in the event of suspected security incident.   This policy defines security incidents, both physical (such as the loss of a laptop) and electronic (a suspected attack or  malware infection).  This policy includes preparation plans, response activities for different scenarios, and forensics/recovery  based on your stated goals.  Incident Response Policies are required by a number of regulations and security standards. An Incident Response Policy is clearly one of a company's most important policies, as it can reduce risk of a security incident  as well as reduce data loss and speed recovery times in the event an incident were to occur.  Most importantly, an Incident  Response Policy outlines roles, responsibilities, and actions to take in advance, so that these decisions don't need to be made  during the stress of responding to a security incident. An Incident Response Policy developed with the InstantSecurityPolicy.com application will include the following detailed  sections: 1. Overview 2. Purpose 3. Scope 4. Policy     4.1. Types of Incidents         4.1.1. Electronic         4.1.2. Physical     4.2. Preparation     4.3. Confidentiality     4.4. Electronic Incidents         4.4.1. Step­by­Step Response     4.5. Physical Incidents         4.5.1. Response             4.5.1.1. If Loss Contained             4.5.1.2. If Data Loss Suspected     4.6. Notification     4.7. Applicability of Other Policies 5. Enforcement 6. Definitions 7. Revision History Available in the Silver and Gold Packages only, this is a policy that is intended to be used by technical staff and management  only. Your custom Incident Response Policy will be delivered immediately upon completion of the wizard via email, as both a PDF  and an RTF file.   RTF files are editable in all major processing programs, including Microsoft Word. Our security policies were written based on a cohesive and integrated approach using security best practices stemming from  the C­I­A triad of confidentiality, integrity, and availability.  This approach aligns with both real­world and industry standard­ based objectives, resulting in an invaluable resource for your security policy management.  A Incident Response Policy  developed with the InstantSecurityPolicy.com wizard will provide the foundation for a realistic, practical implementation of  your IT security policy program.

http://www.evergreen.edu/policies/policy/biasincidentresponsepolicy

Bias Incident Response Policy Category(ies) Student Affairs Approval(s) President and Vice Presidents: October 31, 2005 Signature (pdf) President and Vice Presidents: November 16, 2005 Signature (pdf) Introduction The reality for Evergreen students is that hate crimes and bias incidents can occur in their living communities, in their  classrooms, at co­curricular activities, and in employment situations and at off campus college related activities. The College  already has policies, procedures and protocols in place to respond to different kinds of incidents, enabling the college to attend  to the health and safety of students, manage individual complaints or grievances, and adjudicate possible violations of college  policies or local, state or federal laws. Examples of such policies, procedures, and protocols' include but are not limited to:

•

Living communities — the housing contract, the Student Conduct Code and the Peer Arbitration Board and the college Non-Discrimination Policy local, state and federal civil rights laws and regulations

•

Classrooms - program covenants, the Faculty Handbook, college NonDiscrimination Policy, academic administrative policies and deans

•

Co-curricular activities — the Student Conduct Code, college NonDiscrimination Policy and local, state, and federal civil rights laws and regulations

•

Employment settings - student employment agreements, policies and procedures, college Non-Discrimination Policy, local, state and federal civil rights laws and regulations

•

Case Coordinating Protocol

•

Sexual Assault Protocol

Protocol for Bias Incidents The following protocol is to ensure a timely, efficient, and effective response to campus incidents involving Evergreen students,  which may be characterized as hate crimes or bias incidents. The protocol should be implemented whenever a hate crime or  bias incident is believed or perceived to have occurred. This protocol is specific to addressing hate crimes or bias incidents  directed at Evergreen students. The protocol does not cover faculty and staff. The protocol may apply in incidents off campus.  This proposed interim protocol is not in lieu of and does not override established college or external processes and services  available to students. 

Circumstances When the Protocol Is To Be Initiated The bias incident protocol is initiated in cases of what may be a hate crime, bias incident, or when it is clear that the incident  would have a serious impact on groups by virtue of their race, color, religion, ethnic/national origin, gender expression, sex,  age, disability or sexual orientation identities. The purpose of convening the protocol response team is not to respond to more  private incidents, especially when victims are uncomfortable with a public response, but rather to deal with more visible  incidents that are likely to significantly affect the community.

A hate crime is an actual criminal offence motivated in whole or in part by the offender's bias towards the victim's status based  on race, color, religion, ethnic/national origin, gender expression, sex, age, disability or sexual orientation identities. A bias incident is conduct, speech or expression that is motivated by bias based on perceived race, color, religion,  ethnic/national origin, gender expression, sex, age, disability or sexual orientation identities but does not rise to the level of a  crime. To constitute a bias incident, sufficient objective facts must be present to lead a reasonable and prudent person to  conclude that the actions in question may be motivated by bias toward the status of a targeted individual or a group. The College has a zero tolerance for hate crimes and bias incidents and will act swiftly and effectively when such are reported.  The College aspires to create an environment that is inclusive and safe for all students to learn. This protocol is specific to  addressing hate crimes or bias incidents directed at Evergreen students identified as protected classes under the College's Non­ Discrimination Policy, local, state and federal civil rights laws and regulations. The College realizes the scope of the laws,  policy and regulation extends to the abovementioned protected classes. Though socio economics status is not covered under  existing laws and college policies, the College also recognizes, that students from lower socio economic groups may experience  discrimination or bias.

Reporting of Bias Incidents Students who experience or witness, and staff or faculty members who become aware of a possible hate crime or bias incident,  are asked to report the crime or incident immediately to a designated college office or official:

•

Vice President for Student Affairs 867-6296

•

Police Services 867-6832

•

Director of Housing and Food Services 867-6137

•

Campus Grievance Officer 867-5113

•

Dean of Student and Academic Support Services 867-6034

•

Director of First Peoples' Advising Services 867-6467

•

Civil Rights Officer 867-5371

•

Provost Office 867-6400

•

Academic Deans 867-6870

Notification of the report will then be made to the Office of the Vice President for Student Affairs. The Vice President will  ensure that the complaint is investigated by the appropriate investigative official as well as convene the response team. This protocol will be used 24 hours a day/7 days a week. During regular business hours, the Vice President for Student Affairs,  the Dean of Student and Academic Support Services, Police Service, the Director of Housing and Food Services or Academic  Dean Should be notified immediately of any incidents which have the potential to be characterized as hate crimes or bias  incidents. During evening and weekend hours, Police Services or housing staff will notify the Vice President for Student Affairs or the  vice president's designee. In the case of incidents in the living community, Police Services or housing staff will first notify the  Director of Housing and Food Service or the director's designee, who will then notify the Vice President for Student Affairs.

Procedural Steps 1. Front-line respondents to the incident should (a) assess and determine the need for emergency services, which may include emergency medical or psychological treatment; (b) determine if there continues to be a threat to parties involved and provide appropriate protection to the targeted individual or group through Police Services. A list of student affairs practitioners who can be contacted to assist will be available in the Office of the Vice President for Student Affairs and in the Police Services office. 2. Once an incident has been reported the Vice President for Student Affairs or the vice president's designee will initiate the case-coordinating protocol. In crises and emergencies the Division of Student Affairs activates the casecoordinating protocol to ensure direct services and support to students in

crisis. The case coordinator is a student affairs practitioner trained in crisis management and emergencies. The coordinator assists the student(s) in accessing campus and local support services and resources and intervenes or facilitates in matters related to the student's(s') academic and personal wellbeing. The case coordinator is assigned to the student(s) until the crisis is resolved. When requested by the student(s), the case coordinator will accompany the student(s) to appointments when appropriate, as well as advise the student(s) regarding college policies. Students residing in the residence halls are assigned a case coordinator by the Director of Housing and Food Service, and students living off campus are assigned a case coordinator by the Dean of Student and Academic Support Services. 3. A student affairs practitioner will be assigned to coordinate services for the student(s) involved. The assigned coordinator will be responsible for maintaining contact with the student(s) throughout the process, from the initial crisis through subsequent periods as needed to address academic and personal issues which may have developed as a result of the hate crime or bias incident. If the student(s) shows any signs of being distraught, contact with the counseling center or crisis center should be made immediately. Based on interactions with the student(s) it may be determined appropriate to assign case coordinators who may be from the individual's affinity group if possible. If this is not possible, every effort should be made for the case coordinator to identify who within the college community could assist as additional support to the student(s). 4. Documentation of the incident should begin immediately. Police Services should be contacted to document possible hate crimes or bias incidents through such activities as photographing physical injuries, offensive graffiti and evidence of vandalism. Depending on where the incident occurs (in the living community, in the classroom, in a co-curricular program, or on the job), the appropriate documentation procedure should be implemented. Reports should include important details such as when and where the incident occurred and who was involved in or witnessed the incident. Any physical evidence of the incident (messages written on doors, physical objects, etc.) should be retained and secured for police to investigate and crime scenes should not be disturbed prior to the arrival of Police Services. 5. Targeted students may feel uncomfortable about cooperating with an investigation due to fear of retaliation by the perpetrator(s). Impacted students should be assured by investigating authorities that their safety and security are important and that every effort will be made to ensure that their safety is protected and measures, such as relocation and when possible anonymous reporting, can be utilized to minimize potential threats. Any retaliatory behavior by the student suspected of the violation or by his or her supporters may constitute an independent violation of college policy. 6. Students who have been identified as suspects in a bias incident or hate crime will be assigned a case coordinator to work with regarding the impact of the incident and the student's rights and responsibilities and the steps for due process that they will be afforded under the Student Conduct Code. 7. Intake investigation and fact finding of all complaints of hate crimes and bias incidents will be conducted by the appropriate investigative teams (police services, campus grievance officer, and civil rights officer). Investigations will be conducted to determine possible violations of college policies and local,

state and federal laws and regulations. Students suspected of violations may be accountable under the criminal justice system, the Student Conduct Code and Non-Discrimination Policy. 8. Once the most immediate needs have been addressed, the Vice President for Student Affairs or the vice president's designee will convene the response team. The response team will be comprised of: ○ Vice President for Student Affairs ○ Dean of Student and Academic Support Services ○ Director, Housing and Food Services and designees ○ Academic Dean (Provost will refer to the appropriate dean) ○ Agenda Committee Member ○ Director of First Peoples' Advising Services ○ Director of Police Services ○ Campus Grievance Officer ○ Civil Rights Officer ○ Executive Associate to the President ○ Associate Vice President for Human Resource Services ○ Director of College Relations ○ Director of Access Services ○ President's Special Assistant for Diversity Affairs ○ Director of Student Activities ○ Students The Vice President may add to the membership of the team, faculty and staff who have scholarship/research and expertise who could add to the analysis of the situation or other faculty and staff in areas based on the circumstances or location of the incident. 9. The response team will identify the needs of the affected communities as well as that of the larger Evergreen community. Informing the affected communities as well as the larger community regarding the incident, as appropriate, will be a major function of the response team. 10.An email will be sent to the appropriate affected community members describing the incident and the steps which are being taken, status of the investigation, and that the response team has been assembled. An update should follow once the response team has had an opportunity to assess the situation and determine next steps. 11.The response team may organize and hold open forums within the affected communities as well as the larger community to provide information regarding those details of the incident which can be revealed outside of the

investigation, to gather suggestions, to denounce such incidents, to reaffirm Evergreen's values and standards around diversity and equal respect and to educate about hate and bias. 12.The response team will be provided with progress reports of the investigation. Given that criminal and judicial investigations are confidential, the team will be kept informed of the investigation's progress to the extent allowable. Whenever possible, the team will provide assistance to ensure that all aspects of bias-related activities are examined and that the investigation is handled in a manner that is efficient, effective and culturally sensitive. The intent is to send a clear message that the college has zero tolerance for hate crimes and bias incidents and will act swiftly and effectively when such incidents are reported. 13.The response team will also determine topic program areas for additional trainings for students, staff and faculty. All efforts should be made to develop trainings for the community that will enhance and encourage inter-group dialogue that focuses on how conversations around issues of racism and discrimination of all types enable all students to be more socially integrated into the campus. Endnotes Division of Student Affairs Case Coordinating Protocol. In crises and emergencies the Division of Student Affairs activates the  case­coordinating protocol to ensure direct services and support to students in crisis. The case coordinator is a student affairs  practitioner trained in crisis management and emergencies. The coordinator assists the student(s) in accessing campus and local  support services and resources and intervenes or facilitates in matters related to the student's(s') academic and personal well­ being. The case coordinator is assigned to the student(s) until the crisis is resolved. When requested by the student(s), the case  coordinator will accompany the student(s) to appointments when appropriate, as well as advise the student(s) regarding college  policies. Students residing in the residence halls are assigned a case coordinator by the Director of Housing and Food Service,  and students living off campus are assigned a case coordinator by the Dean of Student and Academic Support Services. The case coordinator also works with students who may not have been directly involved in the crisis, but who have felt the  impact of the crisis. Another form of support the case coordinator lends is to students who are involved in the college judicial  system, assisting them in understanding their rights and responsibilities and due process guidelines.

Sexual Assault Protocol The sexual assault protocol, under the Health and Counseling Center, provides advocacy support to persons who have been  sexually assaulted. These services are coordinated by a student affairs professional who works closely with Police Services, St.  Peter's Hospital and Safe Place. Note: Permission granted by Syracuse University to adopt selected text from Syracuse's Bias Related Incidents Protocol

Reference Sources Reviewed A Systematic Plan to Fight Hate on Campus, (2004), American Association of Colleges and Universities (AAC&U) Diversity on Campus: Report from the Field, (2000), National Association of Student Personnel Administrators Responding to Hate Crimes and Bias Motivated Incidents on College and University Campuses, (2000), Community Relations  Services, Department of Justice Violent Victimization of College Students, (2003), Department of Justice American Civil Liberties Union Briefing Paper Number 16, Hate Speech on Campus Responding to Hate at School, A Guide for Teachers, Counselors and Administrators, (1999), Southern Poverty Law Center 10 Ways to Fight Hate on Campus, A Response Guide for College Activities, (1999), Southern Poverty Law Center

http://www.zdnetasia.com/techguide/workplace/0,3800010799,39217254,00.htm

Create an incident response policy By Mike Mullins, Special to ZDNet Asia Monday, February 21, 2005 05:16 PM Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down  your organization's network, and your disaster recovery plan effectively details how to respond to a security incident­­so  you feel relatively secure.  But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has  a policy in place that outlines steps to take during potentially disastrous times.  Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize  security vulnerabilities and respond to security incidents in a well­organized and thorough manner should be a critical  component of any company's BCP.  A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can  include unauthorized access, malicious code (such as viruses), network probes, and denial­of­service attacks.  An effective IRP should address eight key areas. Let's take a closer look. 

1. Demonstrate management support  First and foremost, your policy should clearly outline management's support of the policy. A member of senior  management­­or anyone with the same authority to address the included provisions­­should sign the policy. These  provisions might include any financial resources, personnel, equipment, and training dedicated to implementing the  policy as well as internal consequences of violation. 

2. Decide an organizational approach  There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The  method your organization chooses should depend on whether the goal is to seek prosecution and/or compensation or  to quickly restore services. 

3. Determine outside notification procedures Allowing your network to participate in a distributed attack and  remaining silent is a legal landmine waiting to explode. In our collaborative world, it's important to determine  procedures for notifying third parties if you're involved in a distributed event. Decide whom you'll inform as well as  when and how. 

4. Discuss remote connections  Your policy must address remote connections. This should encompass all remote employees or contractors, and it  needs to outline your rights to disconnect and remove access during a security incident. 

5. Define partner agreements  Describe downstream and upstream agreements with your service providers and customers that define your right to  monitor and disconnect the network as required. 

6. Develop an incident team  Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, 

responsibilities, and functions. The team should encompass a variety of skills and areas of expertise, including  security, administrators, human resources, and legal. 

7. Design an internal communications plan  Develop an internal communications plan that identifies who you will notify and how you will contact them. In  addition, decide on the person who's responsible for initiating this contact. 

8. Demand a follow­up report  Define a method for reporting and historically archiving the incident. Use that information to tune your operations to  prevent a similar incident from reoccurring.  Every network is unique, and the type of business your organization conducts on the Internet will influence the level  of your response to a security incident. As your network changes, make sure you adjust your IRP accordingly and  address newly discovered vulnerabilities as they occur.  Final thoughts  If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a  security incident. An IRP policy can't solve your problems, but it can offer a cool­headed method for dealing with a hot issue.  For more in­depth information on incident response, check out SANS' Information Security Reading Room , which offers a  wealth of available information that can help you create a comprehensive incident response policy. 

http://technology.iusm.iu.edu/body.cfm?id=99

SUBJECT: Incident Response Policy  SOURCE: Office of the Dean, IU School of Medicine  POLICY NO: IUSM SEC­04  DATE ISSUED: 12 Nov 04  REVISION: March 31, 2005  PURPOSE:  The purpose of this policy is to outline the different responsibilities of the Information Services and Technology Management  (ISTM) office and the IUSM departments with regards to reacting and responding to various types of network and information  security incidents that may occur within IUSM.  SCOPE:  This policy applies to all employees and faculty of IUSM; as well as vendors, contractors, partners, students, collaborators and  any others doing business or research with the IUSM will be subject to the provisions of this policy. Any other parties, who  use, work on, or provide services involving IUSM computers, technology systems, and/or data will also be subject to the  provisions of this policy. IUSM computing resources have been developed to encourage widespread access and distribution of  data and information for the purpose of accomplishing the educational, clinical, and research missions of the school. This  policy will not supercede any Indiana University developed policies but may introduce more stringent requirements than the  university policy.  DEFINITIONS:  Security incidents can generally be defined as "the act of violating an explicit or implied security policy" (Definition taken  from the Carnegie Mellon Computer Emergency Response Team Coordination Center Incident Reporting System Guidelines.)  An IUSM security incident is defined as an event that exposes IUSM­held data to unauthorized individuals and impacts or has  the potential to impact negatively either patient safety or privacy, IUSM employee safety or privacy, or the reputation of IUSM.  The Core incident response team consists of those members of various IUSM offices, departments, and centers who will assist  in the conduct of a major incident investigation. The incident response team will be activated at the discretion of the CIO. The  core IUSM incident response team members will be the Chief Information Officer, the Chief Security Officer, a physician  advisor, a Legal Office representative, a Media Relations Office representative, and a Compliance Office representative.  Adjunct incident response team members are those members of various IUSM centers, departments and offices who have  specific skills needed at times during incident investigations.  POLICY:  1. The Chief Information Officer is granted authority through the ISTM Charter, dated 1 Oct 03, to take actions necessary to  protect IUSM people, resources, data and/or communications in the event of a security incident.  2. The Chief Security Officer serves as the investigative and operational lead for the conduct of all IUSM security incident  investigations. The Chief Security Officer will be the primary authority for invoking incident response procedures.  3. Various IUSM departments and centers will provide core and adjunct members of the incident response team to assist the  Chief Security Officer during security incident investigations. All incident response team members will be assigned duties  based on the circumstances of the incident. Specific members and their respective roles are outlined in IUSM incident response  procedures.  4. IUSM personnel must immediately report: a. a security incident that involves unauthorized physical access to a building or  secure location, physical threat, imminent danger, or personal safety issue to the IUPUI Police Department. b. an actual or  suspected security incident that involves unauthorized access to electronic systems owned or operated by IU and/or IUSM;  malicious alteration or destruction of data, information, or communications; unauthorized interception or monitoring of  communications; and any deliberate and unauthorized destruction or damage of IT resources to the Indiana University IT  Security Office (ITSO) as outlined in IT Policy Office (ITPO) incident reporting procedures.  5. All communications with the media regarding an incident will be coordinated through the IUSM Public and Media Relations  office.  VIOLATION OF POLICY: 

If it is suspected that this policy is not being followed, report the incident to the Center, Departmental IT manager or  representative and the Chief Security Officer. Any exceptions to this policy must be approved in advance by both the Chief  Security Officer and the Chief Information Officer.  ENFORCEMENT:  Any person found to have violated this policy will be subject to appropriate disciplinary action as defined by the provisions of  Indiana University Policy IT­02, Policy on Sanctions for Misuse or Abuse of Indiana University Technology Resources.  REVISION HISTORY:  1. IUSM SEC­04, 12 Nov 04, original policy  2. Revision, March 31, 2005: Added "Centers" to the following: Definitions section, Core Incident Response Team and Adjunct  Incident Response Team definitions. 

http://www.gsu.edu/ist/incident_response.html

Incident Response Policy Policy Rationale Standards & Procedures Revisions Approval Dates (Summary of Changes/Additions/Deletions) 

Policy Information security incidents occurring on the university network or attached devices will be managed centrally by the  University Information Security Officer (ISO) and will include other campus resources as determined by the ISO. 

Rationale Centralized notification and control of security incident investigation is necessary to ensure that immediate attention and  appropriate resources are utilized to control, eliminate and determine the root cause of events that could potential disrupt the  operation of the university or the compromise of university data or sensitive information.  

Standards & Procedures Standards Computer Security Incident Response Team (CSIRT). The ISO, with the advice and assistance of college and departmental  IT representatives, will have the capability to establish a CSIRT to respond to security incidents.   Campus­wide Outage. A campus­wide outage is a fault, event or other unforeseen issue causing failures to all or large  portions of the campus communication and computing infrastructure, services and devices or key communication and  computing resources such as a DNS failure or a loss of campus Internet access.  This type of incident would be treated as a  Critical Incident. Incident Types.  An incident is defined an as adverse event in an information systems and/or network device or the threat of  the occurrence of such an event.  Events may be characterized as unauthorized use of another’s user account, unauthorized use  of system privileges or execution of malicious code.  Events characterized as environmental (such as natural disasters,  electrical outages, heat damage, etc.) are not within the scope of this policy. The most identifiable types of event are:  Malicious code attacks—Attacks by programs such as viruses, Trojan Horse programs, worms, and scripts to gain privileges,  capture passwords, and/or modify audit log to hide unauthorized activity.    Unauthorized access—Includes unauthorized users logging into a legitimate account, unauthorized access to files and  directories or operation of “sniffer” devices. Disruption of services—Includes erasing of programs or data, mail spamming, denial of service attacks or altering system  functionality. Misuse—Involves the utilization of computer resources for other than official purposes.   Espionage—Stealing information to subvert the interests of a corporation or government entity.   Hoaxes—Generally an e­mail warning of a nonexistent virus. Incident Severity. Incidents will be classified by the ISO based on the perceived impact on university resources: Critical—Severe risk to the university network and/or external systems over the Internet.  May be characterized by widespread  risk of compromise of multiple systems or high risk of compromising sensitive information. Criteria for determining if an 

incident is critical include but are not limited to: health and safety of personnel, legal issues, possible harm to the university’s  reputation. Medium—Medium risk to the university network and low risk to external systems over the Internet. May be characterized by  risk of compromising more than one system, no risk to sensitive data, or isolation to a single system. Low—Low risk to the university network and no risk to external systems over the Internet. May be characterized by  compromise of a system that does not host or process critical/sensitive information, does not pose a risk to other systems or  types of devices.  

Procedures Compromised System Procedure (PDF) Computer Security Incident Response Team Procedure (Word)  

Revisions  

Approval Date(s) Reviewed by IS&T Reviewed by Information Security Subcommittee Reviewed by ISAT Senate Committee Approved by: University Administrative Council Approved on: 3/8/06 Version number: 1.0.0 Effective Date: 3/8/06  

Summary of Additions/Deletions/Changes

http://boisestate.edu/oit/iso/incresponsepolicy.shtml

Boise State University Information Technology Incident Response Policy   DRAFT 09/09/2008  Purpose  The purpose of this policy is to define general requirements for responding to an information security incident.   I.  Policy Statement    The IT Incident Response Policy and subordinate procedures define standard methods for identifying, containing, eradicating  and documenting response to computer­based information security incidents.  Information Security incidents occurring on the  University network or attached devices will be managed centrally by the University Information Security Officer (ISO) and  will include other campus resources as determined by the ISO.  Centralized notification and control of security incident  investigation is necessary to ensure that immediate attention and appropriate resources are used to respond to events that could  potentially disrupt the operation of the University or compromise University data.     A.  Definitions    Incident Types   An incident is defined an as adverse event in an information systems and/or network device or the threat of the occurrence of  such an event.  Events may be characterized as unauthorized use of another’s user account, unauthorized use of system  privileges, or execution of malicious code.  Events characterized as environmental (such as natural disasters, electrical outages,  heat damage) are not within the scope of this policy. The most identifiable types of event are:    Malicious code attacks—Attacks by programs such as viruses, Trojan Horse programs, worms, and scripts to gain privileges,  capture passwords, and/or modify audit log to hide unauthorized activity.        Unauthorized access—Includes unauthorized users logging into a legitimate account, unauthorized access to files and  directories, or operation of “sniffer” devices.   Disruption of services—Includes erasing of programs or data, mail spamming, denial of service attacks, or altering system  functionality.    Misuse—Involves the use of computer resources for purposes other than those defined in the Information Technology  Resource Use policy (BSU 6460­C).        

Espionage—Stealing information to subvert the interests of a corporation or government entity.        Hoaxes—Generally an email warning of a non­existent virus.   Campus­wide Outage­­A campus­wide outage is a fault, event, or other unforeseen issue causing failures to all or large portions  of the campus communication and computing infrastructure, services, and devices or key communication and computing  resources such as a DNS failure or a loss of campus Internet access.        B.  Incident Severity   Incidents will be classified by the ISO based on the perceived impact on University resources:   Critical—Severe risk to the University network and/or external systems over the internet.  May be characterized by widespread  risk of compromise of multiple systems or high risk of compromising sensitive information.  Criteria for determining if an  incident is critical include but are not limited to: health and safety of personnel, legal issues, possible harm to the University’s  reputation, a campus­wide outage.        Medium—Medium risk to the University network and low risk to external systems over the internet.  May be characterized by  risk of compromising more than one system, no risk to sensitive data, or isolation to a single system.   Low—Low risk to the University network and no risk to external systems over the internet. May be characterized by  compromise of a system that does not host or process critical/sensitive information, does not pose a risk to other systems or  types of devices.     C.  Computer Security Incident Response Team (CSIRT)  

The ISO with the advice and assistance of college and departmental IT representatives will have the capability to establish a  CSIRT to respond to security incidents.    D.  Incident Reporting

Any individual or organization internal or external to Boise State can notify the ISO of an activity or concern.   II. Scope   This policy applies to all Boise State employees, contractors, vendors and agents.   

  III. Responsibility All users of Boise State IT resources are reponsible for compliance with this policy. IV.  Procedures A.  Incident Response Procedure:  The ISO maintains internal procedures for Incident logging, tracking, and reporting.  The  current procdure can be found at http://boisestate.edu/oit/iso/IncidentResponseProcedureBSU.html

B.  Non­Compliance with this Policy:  Any employee found to have violated this policy may be subject to disciplinary action,  up to and including termination of employment. Adapted with permission from Georgia State University and Yale University

http://www.certiguide.com/secplus/cg_sp_542IncidentResponsePolicy.htm

 5.4.2     Incident  Response Policy      Incident Response Policy will vary with the particular needs of an organization. For example, while it may be acceptable to disconnect the router that connects to the Internet in one firm, this could lead to serious liability in another firm, such as an ISP. It is beyond this work to detail all forms of policy regarding Incident Response. The footnote443 will take you to a page supported by Fred Cohen who has more than a half dozen links to specific policies from the Naval Research Lab to generic templates to be filled in. One of the most important things to say about incident response policies is, have one before you need it. Decide before you’re faced with a computer security incident, how you are going to handle it, who will be involved, what their duties will be, etc. This enables you not to waste valuable time deciding these things during an actual incident.

https://security.tcu.edu/IncidentResponsePolicy.htm

TCU Technology Resources Incident Response Policy The purpose of this policy is to define the procedures that are to be followed when an incident is reported to, or discovered by, Technology Resources. This policy does not apply to major incidents involving widespread loss of sensitive or confidential personal information. These latter incidents are dealt with in the TCU Major Computer Incident Response Plan which is under development.   When an incident is reported through any means to any staff in Technology Resources, the matter is referred to the Associate Provost for Technology Resources or their designee.   A determination is made as to whether the incident primarily involves the authority of other departments and if so the matter is forwarded by Technology Resources as follows 1. Legal matter - Campus Police 2. Solely a breach of the Computer Resources Policy - Technology Resources 3. Student Code of Conduct or other student issue - Campus Life 4. Faculty/Staff Code of Conduct issue or other faculty/staff issue - Human Resources   If the incident is handed off to another department the Associate Provost for Technology Resources or their designee will act as the liaison with these other departments.   If the issue is deemed to be an immediate threat to the security or stability of TCU information resources such as the network or servers, Technology Resources may take immediate action to isolate the problem in accordance with the Computing Resources Policy. Under these circumstances Technology Resources staff may disable network or account access for persons or equipment inside or outside TCU without prior notice. This action will be reported to the Associate Provost for Technology Resources or the Provost as soon as is possible.   If the incident is investigated initially by Technology Resources and it is discovered that there are legal issues involved, or possible violations of any policies concerning TCU students, faculty or staff then the incident will be handed to Campus Police, Campus Life or Human Resources along with any evidence collected to that point. From that point on Technology Resources will assist the department now responsible for the investigation.   During an investigation by Human Resources, Campus Police, or Campus Life personal information including traffic logs, email, files etc. may be requested through the Associate Provost for Technology Resources by these unit heads or their designee. If information is requested for any other reasons it will be provided only after the approval of the Provost, or in their absence the Associate Provost for Technology Resources. In any case personal or private information will be protected in accordance with the TCU Privacy of Information Policy and the Computing Resource Policy as well as other applicable policies.

http://infrastructure.fedoraproject.org/csi/security-policy/en-US/htmlsingle/#IncidentResponse-Standard

2.2. Security Incidents Security incidents are serious matters. Any detection of a security breach or malicious behavior should immediately be reported. Users should contact the security team directly at admin fedoraproject.org. Please do not share any details related to the incident with anyone other than the initial contact. Maintaining confidentiality protects you and The Fedora Project from further internal attacks. A potential attacker that becomes aware of detection may cover tracks or change behavior suddenly, which makes investigation more difficult. On the other hand, if the security team is aware of and tracking an attack in progress, the chances of catching the attacker greatly increases.

2.3. External Sources and References •

Hardening RHEL5 http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf

•

CentOS OS_Protection http://wiki.centos.org/HowTos/OS_Protection

Chapter 3. Incident Response Mike McGrath Fedora Infrastructure Lead Fedora Project 3.1. Introduction 3.1.1. The Rules 3.1.2. Incident Response Team 3.1.3. Management 3.2. Prerequisite Tasks 3.3. Assessment and Communication 3.3.1. Management Chain Notification 3.3.2. Threat Assessment 3.3.3. Entry Investigation 3.3.4. Impact-Assessment 3.3.5. Partner Communication 3.3.6. Public Disclosure

3.4. Actions 3.4.1. Investigation 3.4.2. Data Integrity Plan 3.4.3. Re-secure Environment Plan

3.1. Introduction This document sets out the procedures that are to be followed in the event of a security-related incident. Each incident will have an acting incident coordinator at all times. The incident coordinator is charged with coordinating task responsibilities, and with finding another coordinator in the event that he or she becomes unavailable. 3.1.1. The Rules You have been directed to read this policy because you are either involved in an incident, or because you have been asked to be part of an investigation related to a security incident. While performing the tasks below please keep the following in mind. Incident Rules Complet Requireme e nt

Action

Comment

Unless it is part of a task that is assigned to you, do not make any changes to a host without Make Must Not permission from the incident coordinator. This Changes includes shutting services down, logging in or out, and other configuration changes. Incident team members must not work on tasks Task that have not explicitly been assigned to them Must Not Assignment without discussing it with the incident coordinator or the task leader. [37] Discussion of the incident must only happen between the members of the team chosen by Information Must the incident coordinator. Before discussing any Disclosure incident with someone, make sure they are on the list of team members. [38] Do not make any assumptions about task Must Assumptions assignments or completion. Discuss any concerns you have with the incident coordinator. 3.1.2. Incident Response Team Anyone specifically contacted and assigned responsibility for a task related to this incident automatically becomes a member of the incident response team. The team may include non-technical members involved with marketing or legal tasks. 3.1.2.1. Incident Coordinator The incident coordinator is accountable for all technical issues related to the incident. If a compromise is involved, the incident coordinator is ultimately charged with discovering the nature of the incident; assessing the extent of any damage or risk to services, users, or data; concluding the incident as quickly and efficiently as possible; and creating and implementing a plan for mitigation and prevention of future damage or risk. This role is largely technical, but the incident coordinator must also work with team members to coordinate and delegate tasks. This coordination includes, but is not limited to, working with hosting providers,

providing or summarzing information for reporting or dissemination, and ensuring that team members are following the incident respose plan. The tasks below must be completed in an order determined by the incident coordinator. Tasks that require or depend on another task are to be explicitly so defined. As each task is completed it should be marked completed on the task list. Some tasks require written answers to questions. Coordinate the answers to these questions for factual correctness among chosen parties via a secure communications channel. 3.1.2.2. Task Coordinator Each task is to be assigned to a task coordinator. Each task must be completed and the results (if any) should be given back to the incident coordinator. Do not work on tasks that have not been assigned to you. Multiple team members may be working on one task, though only one of them is to be designated the coordinator of that task. Many tasks can be accomplished in parallel, but some tasks must be processed sequentially. Tasks are to be labeled if they must be completed sequentially. Any assignment with a "sign off" field must be signed off by the task coordinator to ensure it has been completed and verified. It is also the responsibility of the task coordinator to ensure that once a task is done, the task is marked as completed along with the identity of the team member who completed it. If a team member is unable to complete a task, it is the team member's responsibility to inform the incident coordinator. The team member should then attempt to find a replacement from the incident response team, and must notify the incident coordinator whether a replacement has been found. The incident coordinator is ultimately responsible for ensuring that all tasks are assigned properly. 3.1.3. Management Generally the incident coordinator reports to or works with one or more further managers. Although managers may not be involved directly in specific tasks, it is important to keep them informed of the plan for investigation and recovery, and the overall progress. Managers are responsible for ensuring the technical members of the incident response team are able to work as unfettered as possible, and that the appropriate entities outside the team are kept informed properly. For instance, it should not be the responsibility of the technical team to also manage communication with end users.

3.2. Prerequisite Tasks The tasks in this listing must be started prior to any other tasks. Some tasks, like the time line, will be ongoing. Prerequisite Tasks Sign off

Task

Description

If possible, take two LVM snapshots of all volumes on affected systems. If possible, take a snapshot at the disk level to get an Snapshot entire disk image, as opposed to logical volume images. If LVM is not being used, try to dd the block device somewhere piping through ssh. Work with the incident coordinator to copy the images from the "Snapshot" task above to an agreed secure location. Provide a Snapshot Copy size estimate. Include basic details about the images, including the architecture and the requirements to restore these images to a running state.

Sign off

Task

Description

Log Copy

Make an off-site copy of any relevant logs. Create and maintain a list of people who are aware of the Incident compromise and its details. Once the list is made, it must not Response Team grow without the approval of the incident coordinator unless List already specified in this incident response plan. Create and maintain a time line, sorted by the actual time an Time line event took place. The timeline should indicate the actual time of events and not simply the time of discovery. Aside from the incident response team, disable access to any Disabling hosts that are suspected as compromised. In extreme cases Authentication this may involve disabling central authentication altogether.

3.3. Assessment and Communication These tasks are designed around threat assessment and communication. Communication tasks include apprising appropriate management chains of the problem and assembling correct information for dissemination to the public. 3.3.1. Management Chain Notification This section sets out the method by which the management chain is to be informed that an incident has been discovered, and reports and updates are to be sent as investigation, mitigation, and repairs are completed. Management Chain Notification Sign off

Task

Description

This is the initial contact through which management is notified that an incident has either occurred or is in progress. Contact is to be made by phone, and all contact numbers should be used until Notify either the manager has been reached, or the list of contact Managemen numbers has been exhausted. A message is to be left at each t number if no one answers. Phone contact must be followed up by email, whether or not the manager was reached directly. Ensure the following people have been contacted: [email protected], [email protected] Complete the Threat Assessment below, and email it to: [email protected], [email protected]. Inform the Threat recipients that until the final assessment has been completed, the Assessment information provided should be considered preliminary. Additionally include a copy of the time line in its current state. 3.3.2. Threat Assessment The Threat Assessment is to be written for dissemination to management and communication personnel listed as team members. Provide high level technical details, and remember the people reading this assessment may not be technical. Include appropriate explanations for all technical terms used in the assessment. Threat Assessment Sign off Sign off

Task

Description

Threat Answer the questions Assessment below. For each of the following questions, provide an answer that takes into account each of the hosts that have been affected and the information on those hosts.

Threat Assessment Complet e

Question

Answe r

Could this incident impact end users or customers? Could this incident impact contributors, contractors, co-workers, or partners? Could private data have been read or written to by the attacker? Has private data been read or written to by the attacker? Provide an estimate of how long the incident has been occurring. 3.3.3. Entry Investigation In the event that the incident involves a compromise of security such as an intrusion, it is important to determine the point of entry. Below are questions that should be answered in the event of such a compromise, prior to any mitigation efforts such as rebuilding or repairing services. Entry Investigation Sign off Sign off

Task

Entry Investigation Entry Investigation Complet e

Description Answer the questions below.

Question

Answe r

How did the attacker gain entry to the services? What is the likelihood the incident was caused by (1) a malicious associate, or (2) someone without any prior association with The Fedora Project? Did the attacker use a known or unknown vulnerability in software installed on the system? Did the attacker use physical access to any of the host(s) covered by this plan to gain additional access? Did the attack appear to come from other machines operated by The Fedora Project? Did the attack appear to come from machines operated by any of our hosting providers? 3.3.4. Impact-Assessment The impact assessment is closely related to the threat assessment but measures in greater detail what services and servers are are affected by this incident. Include as much specificity as possible at the time of the assessment. As new facts or details emerge, updates of the impact assessment are to be emailed to the incident response team. Impact Assessment Sign off Sign off

Task

Impact Assessment Impact Assessment

Description Answer the questions below.

Complet e

Question

Answe r

Which hosts are impacted? Which services are potentially impacted? Which databases or other data stores require auditing to ensure their integrity? 3.3.5. Partner Communication Partners include any hosting providers, contractors, or other professionals that are impacted by or involved with this incident. Partner involvement may arise from coownership of equipment, provision of services, or shared connections of network hardware. For example, an incident that involves unauthorized physical access to a console may involve the hosting provider responsible for the security of that console. Any incident that involves a previously undisclosed software vulnerability should include the upstream software provider as a partner. Any partner notified as part of this incident response plan is considered part of the incident response team. Partner Notification Sign off

Task

Description

Partner At the discretion of the incident coordinator, contact partner Notification with details about the incident for further investigation. 3.3.6. Public Disclosure [email protected] must sign off on these tasks unless he/she delegates one or more of them to someone else. These tasks should be completed as soon as is feasible, and may consist of multiple notifications and updates, or be combined into one notification if the incident is discovered and fixed quickly. Each of the tasks listed below must be completed. Notification Tree Sign off

Task Initial Notification Partner Integrity

Service Repair Credentials

Entry Time

Description Let everyone know that an incident has happened. When a partner has been determined to be affected and therefore notified (refer to Section 3.3.5, “Partner Communication”), outgoing notifications must not jeopardize the integrety of any investigations underway by those partners. Once a service repair plan is formulated, notify all affected parties about any service availability changes during rebuild and repair. Once the environment is deemed secure, notify all affected parties and institute a system-wide password change by all account holders. Once the entry point has been located, assessed, and repaired, and investigations are completed, notify all affected parties of the cause of the incident and the specific repairs undertaken to prevent recurrence. Once the rebuild/repair phase is complete and services are

Sign off

Task line/Postmorte m

Description returned to normal, send a summary of the repairs undertaken and, if appropriate, the rationale for these actions. This communication should include the same time line used by the incident response team.

3.4. Actions The following actions must be taken to correct issues related to the incident and ultimately restore service to nominal levels. Work with the incident coordinator or task manager to complete the tasks listed below. 3.4.1. Investigation This section of the incident response plan includes some techniques that should be used in the event an incident involves an intrusion or other unauthorized access, to determine the nature of the access and whether it is ongoing. Investigation Sign off

Task

Description

Investigatio Once the intrusion entry point discovered, send a summary and n details to the incident coordinator. Mitigation Ensure the point of entry is closed or properly secured. Investigation Tasks Complet e

Task

Description

Increase logging of any and all services suspected of being involved in the attack to a level sufficient to determine that no unauthorized access is ongoing. Compare files to known good copies, as well as backup copies. File Use best practices such as the rpm ­V command to ensure the Notification integrity of system contents. If appropriate, examine file s metadata such as change, modify, and access times to develop information about the nature of the incident. 3.4.2. Data Integrity Plan The data integrity plan is designed to identify data that may have been accessed in an unauthorized fashion, to identify data that may have been changed as a result of that access, and to ensure that all impacted data is safe for continued use. Data Integrity Plan Increase Logging

Sign off

Task

Description

Data Ensure the below table has been completed and is Integrity accurate. Data Integrity Plan Complet e

Task

Description

Ensure the configuration management repository is intact Configuration and has not been altered as a result of an unauthorized Management access. Compare to off-site backups if necessary. Database Verify hosts containing any databases, and the data that Data resides therein. The nature of this task depends on the

Complet e

Task

Description

extent of any unauthorized access. The incident response team must reach an informed consensus on the procedures required. Verify shared data has not been altered as a result of an unauthorized access. Malicious files that may have been left Shared data behind during the incident should be listed and removed from the system. Make a list of files that have changed during the incident window and verify them. Remove any temporary or cached data and rebuild from Temporary or scratch. If this procedure is not feasible, verify the local Cached Data cache against a known good remote cache. 3.4.3. Re-secure Environment Plan The Re-secure Environment Plan is designed to ensure the attacker has not left back doors or other malicious software on covered hosts. Even if the intruder has been blocked from re-entry through the original unauthorized access point, it is possible for an intruder to leave alternate re-entry points using certain files on the file system. Verification of each file is a time-consuming process. Therefore simply rebuilding hosts is often a faster and more reliable alternative. This possibility is one of the reasons for a robust configuration management policy. Secure Environment Sign off Sign off

Task

Secure Environment Secure Environment Complet e

Task

Description Ensure the tasks below have been completed successfully.

Description

Rebuild any hosts that have been compromised or are suspected Host of compromise. Work with the incident coordinator and task Rebuilds coordinator to develop a strategic order for rebuilding if necessary.

http://www.da.ks.gov/ITEC/Documents/ITECITPolicy7320.htm

Information Technology Policy 7400 ­ Enterprise Computer  Incident Response Policy 1.0 TITLE: Enterprise Computer Incident Response Policy  1.1 EFFECTIVE DATE: October 23, 2008 1.2 TYPE OF ACTION: New Policy 1.3 KEY WORDS: Kansas Information Technology Security Council, Enterprise Security Policy, Information  Security, User Security, Personally Identifiable Information, Security Incident Response. 2.0 PURPOSE: To define the requirements related to actions and activities before, during and after an IT system security  incident. Agencies may require other policies to address needs relating to privacy or other losses not related to paragraph 5.1  below. 3.0 ORGANIZATIONS AFFECTED: All Branches, Boards, Commissions, Departments, Divisions and Agencies of state  government, hereafter referred to as Entities. 4.0 REFERENCES: 4.1 K.S.A. 1998 Supp. 75­7203 authorizes the ITEC to: Adopt information resource policies and procedures and  provide direction and coordination for the application of the state's information technology resources for all state  agencies. 4.2 Kansas Information Technology Executive Council (ITEC), ITEC Policy 7300R1, Information Technology  Security Council Charter  4.3 Kansas Information Technology Executive Council (ITEC), ITEC Policy 7230, Revision 1, General Information  Technology Enterprise Security Policy. 4.4 Regents Information Technology Council (RITC) Security Incident Policy and Procedure, RITC Security Incident  Policy  4.5 Department of Administration Intrusion Detection Incident Response Security Policy and Procedure. 4.6 USDA Cyber Security Incident Handling Procedures manual (March 20, 2006) 4.7 National Institute of Standards and Technology Special Publication 800­61 “Computer Security Incident Handling  Guide” 4.8 National Institute of Standards and Technology Special Publication 800­100 “Information Security Handbook: A  Guide for Managers. 4.9 Carnegie Mellon University Software Engineering Institute “Handbook for Computer Security Incident Response  Teams (CSIRTs)” 4.10 Forum of Information Response and Security Teams (FIRST) http://www.first.org/resources/guides/csirt_case_classification.html (November 17, 2004) 5.0 DEFINITIONS: 5.1 Security incident is defined as a compromise of a system that has critical, sensitive, or confidential data; any  compromise that significantly affects agency resources; the act of violating an explicit or implied security policy; the  act of violating any Federal, State or local law which may result in the loss of confidentiality, integrity or availability.  Compromises may be the result of failed or successful unauthorized access attempts; unwanted disruption of service;  or use of a system to change or damage system hardware, firmware or software. 5.2 Incident response is defined as the activities and actions undertaken before, during and after a security incident.  This includes the four phases of the Incident Response Life Cycle: 1) preparation, 2) detection and analysis, 3)  containment, eradication and recovery, and 4) post­incident activity.

  6.0 POLICY: 6.1 Statement of Responsibility: The Chief Information Security Officer (CISO) is designated as the central point of  contact and coordinating authority for enterprise IT Security incidents. 6.2 The CISO is responsible for establishing a Computer Security Incident Response Team (CSIRT) and for the  conducting activities according to the Enterprise IT Security Reporting Protocols (ITEC 7320A). 6.3 The CISO is responsible for notification of incidents to entities and Regents institutions according to parameters  and guidelines contained in the Enterprise IT Security Reporting Protocols (ITEC 7320A)  6.4 Entities are responsible for following the Enterprise IT Security Reporting Protocols (ITEC 7320A). 6.5 Regents institutions will report enterprise IT security incidents to the KBOR President & CEO and/or KBOR  Chief Information Officer (CIO) of the Board of Regents within 24 hours of a major security incident. The KBOR  President & CEO or KBOR CIO will then notify the CISO and Executive Branch CITO. 7.0 PROCEDURES: 7.1 The practices and procedures for Enterprise Computer Incident Response shall conform to the requirements set  forth in the “Enterprise IT Security Reporting Protocols”, as amended, included as Attachment A to this policy. 8.0 RESPONSIBILITIES: 8.1 Heads of entities are responsible for establishing procedures for their organizations to comply with the  requirements of this policy. 8.2 The Chief Information Security Officer is responsible for the maintenance of this policy. 9.0 CANCELLATION: None

http://articles.techrepublic.com.com/5100-10878_11-5755543.html

Create an incident response policy by Michael "Mullins CCNA, MCP" | Jul 05, 2005 7:00:00 AM Tags: Michael Mullins CCNA, MCP, incident response policy, security incident, security...

0 comment(s) • Email •

Share ○ Digg ○ Yahoo! Buzz ○ Twitter ○ Facebook ○ Google ○ del.icio.us ○ StumbleUpon ○ Reddit ○ Newsvine ○ Technorati ○ LinkedIn

•

Save

•

Print

•

Recommend

•

8

Takeaway: Even the most secure networks need an incident response policy (IRP). Take a look at eight key areas that an  effective IRP should address. 

Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down your organization's network, and your disaster recovery plan effectively details how to respond to a security incident--so you feel relatively secure. But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has  a policy in place that outlines steps to take during potentially disastrous times.  Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize  security vulnerabilities and respond to security incidents in a well­organized and thorough manner should be a critical  component of any company's BCP.  A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can  include unauthorized access, malicious code (such as viruses), network probes, and denial­of­service attacks. 

Get the TR Blog Roundup Find out who's offering the best advice, the quirkiest comments, and the most compelling life stories every week with  TechRepublic's Blog Roundup. Click here to automatically sign up to receive it every Wednesday.  Use tags to find blog posts about Windows and security. An effective IRP should address eight key areas. Let's take a closer look.  Demonstrate management support  First and foremost, your policy should clearly outline management's support of the policy. A member of senior management­­or  anyone with the same authority to address the included provisions­­should sign the policy. These provisions might include any  financial resources, personnel, equipment, and training dedicated to implementing the policy as well as internal consequences  of violation.  Decide an organizational approach  There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The method your  organization chooses should depend on whether the goal is to seek prosecution and/or compensation or to quickly restore  services.  Determine outside notification procedures  Allowing your network to participate in a distributed attack and remaining silent is a legal landmine waiting to explode. In our  collaborative world, it's important to determine procedures for notifying third parties if you're involved in a distributed event.  Decide whom you'll inform as well as when and how.  Discuss remote connections  Your policy must address remote connections. This should encompass all remote employees or contractors, and it needs to  outline your rights to disconnect and remove access during a security incident.  Define partner agreements  Describe downstream and upstream agreements with your service providers and customers that define your right to monitor  and disconnect the network as required.  Develop an incident team  Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, responsibilities,  and functions. The team should encompass a variety of skills and areas of expertise, including security, administrators, human  resources, and legal.  Design an internal communications plan  Develop an internal communications plan that identifies who you will notify and how you will contact them. In addition,  decide on the person who's responsible for initiating this contact.  Demand a follow­up report  Define a method for reporting and historically archiving the incident. Use that information to tune your operations to prevent a  similar incident from reoccurring.  Every network is unique, and the type of business your organization conducts on the Internet will influence the level of your  response to a security incident. As your network changes, make sure you adjust your IRP accordingly and address newly  discovered vulnerabilities as they occur.  Final thoughts  If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a  security incident. An IRP policy can't solve your problems, but it can offer a cool­headed method for dealing with a hot issue.  For more in­depth information on incident response, check out SANS' Information Security Reading Room, which offers a  wealth of available information that can help you create a comprehensive incident response policy.  Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each   Friday, and get hands­on advice for locking down your systems.

http://www.upenn.edu/almanac/volumes/v53/n18/or.html

OF RECORD  Print Issue January 16, 2007, Volume 53, No. 18  We have adopted a new policy, Information Systems Security Incident Response Policy, which is designed to ensure that  computer security incidents are properly identified, contained, investigated, and remedied. The policy also provides a process  for documentation, appropriate reporting internally and externally, and communication to the community as part of an ongoing  educational effort. Finally, the policy establishes responsibility and accountability for all steps in the process of addressing  computer security incidents.   The policy provides that all Penn faculty, staff, consultants, contractors, students, or any agent of any of the above, must report   “Computer Security Incidents” to their Local IT Management, who in turn must notify ISC Information Security. In cases  involving “Confidential University Data,” an Immediate Response Team will be assembled to investigate, contain, mitigate,  and share learning from computer security incidents. In certain cases, a Senior Response Team is convened as well to address  the need for any additional communications and actions.   This policy helps us meet our compliance obligations regarding applicable security breach notification laws, including  Pennsylvania’s Breach of Personal Information Notification Act, by requiring that each computer security incident be reported  and handled in accordance with applicable law.   We appreciate your compliance with this important policy. —Robin Beck, Vice President for Information Systems and Computing —Mary Lee Brown, Associate Vice President for Audit, Compliance, and Privacy   Information Systems Security Incident Response Policy I. Title A. Name: Information Systems Security Incident Response Policy  B. Number: : 20070103­secincidentresp C. Author(s): David Millar (ISC Information Security) and Lauren Steinfeld (Chief Privacy Officer) D. Status: Approved    E. Date Proposed: 2005­10­24 F. Date Revised: G. Date Approved: 2007­01­03 H. Effective Date:  2007­01­16 II. Authority and Responsibility Information Systems and Computing is responsible for the operation of Penn’s data networks (PennNet) as well as the  establishment of information security policies, guidelines, and standards. The Office of Audit, Compliance and Privacy has  authority to develop and oversee policies and procedures regarding the privacy of personal information. These offices therefore  have the authority and responsibility to specify security incident response requirements to protect those networks as well as  University data contained on those networks.  III. Executive Summary

This policy defines the response to computer security incidents. IV. Purpose This policy defines the steps that personnel must use to ensure that security incidents are identified, contained, investigated,  and remedied.  It also provides a process for documentation, appropriate reporting internally and externally, and  communication so that organizational learning occurs. Finally, it establishes responsibility and accountability for all steps in  the process of addressing computer security incidents.  V. Risk of Non­compliance Without an effective incident response process, corrective action may be delayed and harmful effects unnecessarily  exacerbated.  Further, proper communication allows the University key learning opportunities to improve the security of data  and networks. Individuals who fail to comply are subject to sanctions as appropriate under Penn policies. VI. Definitions Confidential University Data includes:  * Sensitive Personally Identifiable Information–Information relating to an individual that reasonably identifies the  individual and, if compromised, could cause significant harm to that individual or to Penn.  Examples may include, but are not  limited to: Social Security numbers, credit card numbers, bank account information, student grades or disciplinary information,  salary or employee performance information, donations, patient health information, information Penn has promised to keep  confidential, and account passwords or encryption keys used to protect access to Confidential University Data.  * Proprietary Information–Data, information, or intellectual property in which the University has an exclusive legal interest  or ownership right, which, if compromised could cause significant harm to Penn.  Examples may include, but are not limited  to, business planning, financial information, trade secret, copyrighted material, and software or comparable material from a  third party when the University has agreed to keep such information confidential. * Any other data the disclosure of which could cause significant harm to Penn or its constituents. Security Incident.  There are two types of Security Incidents: Computer Security Incidents and Confidential Data Security  Incidents. * A Computer Security Incident is any event that threatens the confidentiality, integrity, or availability of University systems,  applications, data, or networks.  University systems include, but are not limited to: servers, desktops, laptops, workstations,  PDAs, network servers/processors, or any other electronic data storage or transmission device. * A Confidential Data Security Incident is a subset of Computer Security Incidents that specifically threatens the security or  privacy of Confidential University Data. User.  A Penn user is any faculty, staff, consultant, contractor, student, or agent of any of the above. VII. Scope This policy applies to all Users. It applies to any computing devices owned or leased by the University of Pennsylvania that  experience a Computer Security Incident.  It also applies to any computing device regardless of ownership, which either is used  to store Confidential University Data, or which, if lost, stolen, or compromised, and based on its privileged access, could lead  to the unauthorized disclosure of Confidential University Data.  Examples of systems in scope include, but are not limited to, a  User’s personally owned home computer that is used to store Confidential University Data, or that contains passwords that  would give access to Confidential University Data. This policy does not cover incidents involving the University of Pennsylvania Health System (UPHS) information systems,  which has a separate incident response policy. ISC Information Security will coordinate with UPHS as appropriate when  UPHS computing devices, data, or personnel are involved. VIII. Statement of Policy

A. Overview of Penn’s Incident Response Program i. All Computer Security Incidents must be reported to ISC Information Security promptly. See Section B below. ii. All Confidential Data Security Incidents must: a. Generate the creation of an Immediate Response Team, as designated by the Information Security Officer (ISO), on a per  incident basis. See Section C below. b. Follow appropriate Incident Handling procedures. See Sections C and D below. iii. ISC Information Security, under the direction of the Vice President for Information Systems and Computing (VP­ISC) is  responsible for logging, investigating, and reporting on security incidents.  See Sections D and E below. B. Identifying and Reporting Computer Security Incidents i. Users and Local Support Providers (LSPs).  In the event that a User or an LSP detects a suspected or confirmed Computer  Security Incident, the User must report it to his or her Local Security Officer or IT Director for issues including but not limited  to viruses, worms, local attacks, denial of service attacks, or possible disclosure of Confidential University Data.   ii. Local IT Management.  Local IT Management must notify ISC Information Security of all Computer Security Incidents,  except for categories of incidents that ISC Information Security may designate in Appendix I of this policy. iii. ISC Information Security.  ISC Information Security shall notify appropriate systems administrators and other personnel of  all emergency and attack incidents, as well as all suspicious activity incidents when it believes that an administrator’s system is  at risk. The system’s administrators will then work with ISC Information Security to properly address the incident and  minimize the risk of future occurrences.  C. Immediate Response Team  i. Purpose.  The purpose of each Immediate Response Team is to supplement Penn’s information security infrastructure and  minimize the threat of damage resulting from Computer Security Incidents. ii. Per Incident Basis.  An Immediate Response Team shall be created for Confidential Data Security Incidents. iii. Membership.  Membership on the Immediate Response Team shall be as designated by the ISO.  In most cases, members  shall include a representative from ISC Information Security and from the affected School or Center’s technical and  management staff.    iv. Responsibilities.  Responsibilities of the Immediate Response Team are to assess the incident and follow incident handling  procedures, appropriate to the incident as determined by the ISO. v. Confidentiality.  Immediate Response Team members will share information about security incidents beyond the Immediate  Response Team only on a need­to­know basis, and only after consultation with all other team members. D. Incident Handling. For incidents requiring the formation of an Immediate Response Team, the following is a list of response  priorities that should be reviewed and followed as recommended by the ISO.  The most important items are listed first: i. Safety and Human Issues.  If an information system involved in an incident affects human life and safety, responding to any  incident involving any life­critical or safety­related system is the most important priority. ii. Address Urgent Concerns.  Schools and Centers may have urgent concerns about the availability or integrity of critical  systems or data that must be addressed promptly.  ISC Information Security shall be available for consultation in such cases.  iii. Establish Scope of Incident.  The Immediate Response Team shall promptly work to establish the scope of the incident and  to identify the extent of systems and data affected.  If it appears that personally identifiable information may have been  compromised, the Immediate Response Team shall immediately inform the VP­ISC and the Chief Privacy Officer (CPO). 

iv. Containment.  Once life­critical and safety issues have been resolved, the Immediate Response Team shall identify and  implement actions to be taken to reduce the potential for the spread of an incident or its consequences across additional  systems and networks.  Such steps may include requiring that the system be disconnected from the network.  v. Develop Plan for Preservation of Evidence.  The Immediate Response Team shall develop a plan promptly upon learning  about an incident for identifying and implementing appropriate steps to preserve evidence, consistent with needs to restore  availability.  Preservation plans may include preserving relevant logs and screen captures.  The affected system may not be  rebuilt until the Immediate Response Team determines that appropriate evidence has been preserved. Preservation will be  addressed as quickly as possible to restore availability that is critical to maintain business operations. vi. Investigate the Incident.  The Immediate Response Team shall investigate the causes of the incident and future preventative  actions.  During the investigation phase, members of the incident response team will attempt to determine exactly what  happened during the incident, especially the vulnerability that made the incident possible.  In short, investigators will attempt  to answer the following questions:  Who?  What?  Where?  When?  How? vii. Incident­Specific Risk Mitigation.  The Immediate Response Team shall identify and recommend strategies to mitigate risk  of harm arising from the incident, including but not limited to reducing, segregating, or better protecting personal, proprietary,  or mission critical data.   viii. Restore Availability.  Once the above steps have been taken, and upon authorization by the Immediate Response Team, the  availability of affected devices or networks may be restored. ix.  Penn­Wide Learning.  The Immediate Response Team shall develop and arrange for implementation of a communications  plan to spread learning from the security incident throughout Penn to individuals best able to reduce risk of recurrence of such  incident.  E. Senior Response Team (SRT).  If the ISO or CPO in their judgment believe that the incident reasonably may cause  significant harm to the subjects of the data or to Penn, each may recommend to the VP­ISC or Associate Vice President for  Audit, Compliance and Privacy (AVP­OACP) that a Senior Response Team be established. The Senior Response Team shall be  comprised of senior­level officials as designated by the VP­ISC or AVP­OACP.  The Senior Response Team shall: i. Establish whether additional executive management should be briefed and the plan for such briefing.  ii. Determine, with final approval by the General Counsel, whether Penn shall make best efforts to notify individuals whose  personal identifiable information may have been at risk. In making this determination, the following factors shall be  considered:   a.  legal duty to notify b.  length of compromise c.  human involvement d. sensitivity of data e. existence of evidence that data was accessed and acquired f.  concerns about personnel with access to the data g. existence of evidence that machine was compromised for reasons other than accessing and acquiring data h. additional factors recommended for consideration by members of the Immediate Response Team or the Senior Response  Team.  iii. Review and approve any external communication regarding the incident. F. Documentation i. Log of security incidents.  ISC Information Security shall maintain a log of all reportable security incidents recording the  date, School or Center affected, whether or not the affected machine was registered as a critical host, the type of Confidential  University Data affected (if any), number of subjects (if applicable), and a summary of the reason for the intrusion, and the  corrective measure taken.

ii. Critical Incident Report.  ISC Information Security shall issue a Critical Incident Report for every reportable security  incident affecting machines qualifying as Critical Hosts, or other priority incidents in the judgment of ISC Information  Security describing in detail the circumstances that led to the incident, and a plan to eliminate the risk. iii. Annual Summary Report.  ISC Information Security shall provide annually for the VP­ISC and AVP­OACP a report  providing statistics and summary­level information about all significant incidents reported, and providing recommendations  and plans to mitigate known risks. IX. Best Practices A. Preserving Evidence: It is essential to consult Penn Information Security when handling Computer Security Incidents.   However, if Information Security is not available for emergency consultation, the following practices are recommended: i. Generally, if it is necessary to copy computer data to preserve evidence for an incident, it is a good idea to use bit­wise file­ system copy utilities that will produce an exact image, (e.g.UNIX dd) rather than to use file level utilities which can alter some  file meta­data. ii. When making forensic backups, always take a cryptographic hash (such as an SHA­1 hash) of both the original object and of  the copied object to verify the authenticity of the copy.  Consult your System Administrator if you have questions. iii. Assigning members to an Immediate Response Team: In cases where an incident involves an investigation into misconduct,  the School or Center should consider carefully whom to assign to the Immediate Response Team. For example, one may not  wish to assign an IT professional who works closely with the individual(s) being investigated. X. Compliance A. Verification:  ISC Information Security and the Office of Audit, Compliance and Privacy will verify any known computing  security incidents as having been reported and documented as defined by this policy.   B. Notification:  Violations of this policy will be reported by ISC Security and the Office of Audit, Compliance and Privacy to  the Senior Management of the Business Unit affected. C. Remedy:  The incident will be recorded by ISC Information Security and any required action to mitigate the harmful affects  of the attack will be initiated in cooperation with the Business Unit Security Officer/Liaison.   D. Financial Implications:  The owner of the system shall bear the costs associated with ensuring compliance with this policy. E. Responsibility:  Responsibility for compliance with this policy lies with the system administrator, system owner, and  Business Unit’s Senior Manager. F. Time Frame:  All incidents involving critical hosts systems and networks must be reported immediately.   All other incidents  should be reported within one business day of determining something has occurred.  G. Enforcement:  Compliance with this policy will be enforced by disconnecting any machines that may compromise the  University network, or other machines with Confidential University Data.  Workforce members not adhering to the policy may  be subject to sanctions as defined by University policies. H. Appeals:  Appeals are decided by the Vice President for Information Systems and Computing. XI. References 1. PennNet Computer Security Policy at www.net.isc.upenn.edu/policy/approved/20040524­hostsecurity.html 2. Critical PennNet Host Security Policy at www.net.isc.upenn.edu/policy/approved/20000530­hostsecurity.html 3. Policy on Computer Disconnection from PennNet at www.upenn.edu/computing/policy/disconnect.html 4. Adherence to University Policy at www.hr.upenn.edu/policy/policies/001.asp 5. Policy on Security of Electronic Protected Health Information (ePHI) at  www.upenn.edu/computing/security/policy/ePHI_Policy.html Appendix I

The following category of incidents need not be reported to Penn Information Security:   * Unsuccessful network scans

http://www.datasecuritypolicies.com/tag/incident-response-policy

http://www.datasecuritypolicies.com/tag/incident-response-policy