CASE STUDY AND EXERCISE 4

Global Information Assurance Certification Paper Copyright SANS Institute Author Retains Full Rights This paper is taken from the GIAC directory of certified professionals. Reposting is not permited without express written permission. Interested in learning more?

Check out the list of upcoming events offering "Security Essentials Bootcamp Style (Security 401)" at http://www.giac.org/registration/gsec An Introduction to the Computer Security Incident Response Team (CSIRT) Set -Up and Operational Considerations Author Tom Campbell, CISSP, ABCP Date Submitted March 2003 Practical Requirements GSEC v.1.4bKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 1 Table of C ontents Abstract ................................ ................................ ................................ ................................ ..................... 3 Background ................................ ................................ ................................ ................................ ............. 4 Computer Security ................................ ................................ ................................ ................................ .... 4 Preventative Operations ................................ ................................ ................................ ......................... 4 Detection operations ................................ ................................ ................................ ............................... 4 Response operations ................................ ................................ ................................ ............................... 5 Recovery operations ................................ ................................ ................................ ............................... 5 Computer Security Incident ................................ ................................ ................................ ..................... 5 Categories and Types of Security Incidents ................................ ................................ ............................ 6 Computer Security Incident Response ................................ ................................ ................................ .... 7 Defining a CSIRT ................................ ................................ ................................ ............................... 8 CSIRT Defi ned ................................ ................................ ................................ ................................ .......... 8 CSIRT Acronyms ................................ ................................ ................................ ................................ ...... 8 CSIRT Goal ................................ ................................ ................................ ................................ ............... 8 CSIRT Objectives ................................ ................................ ................................ ................................ ..... 9 The Need for a CSIRT ................................ ................................ ................................ ................... 10 Benefits ................................ ................................ ................................ ................................ .................... 10 Economic ................................ ................................ ................................ ................................ .............. 10 Public Relations ................................ ................................ ................................ ................................ .... 10 Legal ................................ ................................ ................................ ................................ ..................... 11 Return on Investment ................................ ................................ ................................ ............................. 12 Annual Loss Expectancy ................................ ................................ ................................ ....................... 12 Savings Provided by a CSIRT ................................ ................................ ................................ ............... 12 Cost of a CSIRT ................................ ................................ ................................ ................................ .... 13 Actual Savings of a CSIRT ................................ ................................ ................................ .................... 13 CSIRT ROI ................................ ................................ ................................ ................................ ............ 13 Facts and Statistics ................................ ................................ ................................ ................................ .13 Roles and Responsibilities of a CSIRT ................................ ................................ ............... 15 Non -Real -Time Incident Response Activities -Pre -Incident Activities ................................ .............. 15 Charter ................................ ................................ ................................ ................................ ................. 15 Policy ................................ ................................ ................................ ................................ .................... 16 Incident reporting procedures ................................ ................................ ................................ .............. 17 Incident information trac king and handling procedures ................................ ................................ ...... 18 Costing an Incident ................................ ................................ ................................ ............................... 19 Real Time Incident Response Activities ................................ ................................ ................................ 19 Incident Handling ................................ ................................ ................................ ................................ .21 Incident Recovery ................................ ................................ ................................ ................................ .23 Investigation ................................ ................................ ................................ ................................ ......... 24 IT Security ................................ ................................ ................................ ................................ ............ 26 Management/Legal ................................ ................................ ................................ ............................... 26 Communications ................................ ................................ ................................ ................................ ...26 Non-Real -Time Incident Response Activities -Post -Incident Activities ................................ ............ 27 Post Mortem ................................ ................................ ................................ ................................ ......... 27 Requirements of a CSIRT ................................ ................................ ................................ ............ 29 Proper, Up -to-date Technology ................................ ................................ ................................ ............. 29 Correct, Trained People ................................ ................................ ................................ ......................... 29 Complete and Tested Processe s and Procedures ................................ ................................ .................. 30 Defined Authority and Support ................................ ................................ ................................ ............. 30Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 2 Adequate Funding ................................ ................................ ................................ ................................ ..30 Organisational Buy -In................................ ................................ ................................ ............................ 30 Areas Involved in a CSIRT ................................ ................................ ................................ ......... 32 Conclusion ................................ ................................ ................................ ................................ ............ 34 Bibliography ................................ ................................ ................................ ................................ ........ 35Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 3 Abstract The socio -economic environment of today is evolving and becoming more security conscious. People are taking an increasing number of steps to ensure their safety and security and, demanding the sa me of organisations in both government and industry. These changes in turn are being echoed in demands of information technology security. People are demanding that their personal information that is being processed, transmitted, or stored electronically be done so securely. The demands are being recognized by government and industry alike and are beginning to be reflected in the forms of laws and business practices.

Threats and vulnerabilities, in one form or another, will likely always affect informa tion technology. Organisations will need to continually identify where they are at risk and find ways to mitigate it. However, preventative actions are not always foolproof. As such, methods of detection must be put in place to identify when a compromis e has taken place. Response activities, in turn, need to be established to deal with these detections. This is where the need for a Computer Security Incident Response Team (CSIRT) becomes more apparent.

A Computer Security Incident Response Team (CSIR T) is one of the best ways to bring together the expertise necessary to deal with the wide range of possible computer security incidents that can arise. This paper will introduce the reader to the CSIRT and what is required to build and operate one.

Th e paper will define and explain the need for a CSIRT. The paper will go on to introduce the possible roles and responsibilities, requirements for construction and operation and the possible organizational structure of a CSIRT.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 4 Background Before discus sing Computer Security Incident Response it is a good idea to take a minute to see how and where it fits into the whole computer security picture.

First and foremost is to define exactly what constitutes computer security.

Computer Security Computer Sec urity: Computer security is the preservation of the confidentiality, integrity and availability of all information that is processed, stored and transmitted using a computer.

Confidentiality is the property that information is made available or disclosed only to authorized individuals, entities or processes. Integrity is the accuracy and completeness of information and assets and the authenticity of transactions.

Availability is the accessibility of systems, programs, services and information to authori zed users when needed and without undue delay . Computer Security can be divided into four operational categories:  Prevention Operations;  Detection Operations;  Response Operations; and  Recovery Operations. Preventative Operations Preventative operations are all the activities performed to prevent the compromise of the confidentiality, integrity and availability of all the information that is processed, stored, and transmitted using a computer.

Prevention activities range from creating an Figure 1 –Security Operations information security policy to conducting user training sessions to implementing technical solutions such as access controls or firewalls.

Detection operations Detection operations are all the activities performed to detect the com promise or attempted compromise of the confidentiality, integrity, and availability of all theKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 5 information that is processed, stored and transmitted using a computer Detection activities range from compliance inspections to whistle -blowers to implementing technical solutions such as Intrusion Detection Systems or Integrity Assurance Software.

Response operations Response operations are all the activities performed to respond to the compromise or attempted compromise of the confidentiality, integrity, and availability of all the information that is processed, stored and transmitted using a computer. Response activities range from unplugging the network cable to blocking an IP address at the firewall.

Recovery operations Recovery operations are all the ac tivities performed to recover the confidentiality, integrity, and availability of the information that is processed, stored and transmitted using a computer after a compromise. Recovery operations range from initiating the Business Continuity or Disaster Recovery Plan to conducting user awareness sessions to implementing technical solutions such as disk mirroring or automated backups.

Computer Security Incident The next step is to learn what it is exactly we are responding to, and as the name suggests, we are responding to computer incidents. So let’s define exactly what constitutes a computer security incident.

Computer Security Incident:

A Computer Security Incident is an adverse event that negatively impacts the confidentiality, integrity and availa bility of information that is processed, stored and transmitted using a computer.

Although they may not always be readily apparent, a computer incident has the following characteristics: - The attacker or attack origin; - The tool used; - The vulnerability exp loited; - The actions performed; - The intended target; - The unauthorized result; andKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 6 - The attack objective. Categories and Types of Security Incidents The following table from the Incident Cost and Modelling Project, outlines some possible categories and typ es of security incidents. Category Types Service Interrupts - Denial of Service - Mail Bomb - Ping Attacks - Multiple Request Attack - Root Compromise - Packet Floods - IRC Bots - Virus Infections Computer Interference - Port Scans - System Mapping - System Probe Unauthoris ed Access - Identity Theft - Unauthorised Release of Data - Theft or Modification of Data Malicious Communication - Threats - Hate Mail - Harassment Mail - IRC Abuse - Flaming directly to Individual Copyright Violation - MP3 - Warez: Sites - Video Copyright - Content Violation Theft - Physical Theft of Hardware and Peripherals - Theft of Software - ID Theft - Credit Card Theft - Password Theft Commercial Use - Unauthorized Commercial Activity Unsolicited Bulk Email - Spam - Chain Mail - Mass MailKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 7 Other Illegal Activities - Child Pornography Table 1 –Categories and Types of Incidents 1 Computer Security Incident Response W ith a computer security incident defined, it is fairly easy to then define computer security incident response.

Computer Security Incident Response:

Computer Security In cident Response is the set of activities performed in response to a Computer Security Incident.

Now, hopefully with a better understanding of how and where Computer Security Incident Response fits into the whole computer security picture, it is time to look at the Computer Security Incident Response Team.

1Committee on Institutional Cooperation. Incident Cost and Analysis Model ling Projects (ICAMP) II.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 8 Defining a CSIRT CSIRT Defined A Computer Security Incident Response Team (CSIRT) is a prearranged group, comprised of personnel with expertise from various facets within an organisation, prepared t o deal with the response activities related to computer security incidents for a defined constituency.

It is important to note that for the purpose of this paper, prevention activities are not the responsibility of the CSIRT, though in some organisations this may not be the case. In addition, detection and recovery activities are not the direct responsibility of CSIRT but are not entirely removed from its operation.

CSIRT Acronyms A CSIRT can go by other names and acronyms including but not limited to: Acronym Name CIRT Cyber or Computer Incident Response Team CERT Cyber or Computer Emergency Response Team CIRC Cyber or Computer Incident Response Capability CERC Cyber or Computer Emergency Response Capability SIRT Security Incident Response Team SERT Security Emergency Response Team SIRC Security Incident Response Capability SERC Security Emergency Response Capability IRT Incident Response Team ERT Emergency Response Team IRC Incident Response Capability ERC Emergency Response Capability Table 2 –CSIRT Acronyms CSIRT GoalKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 9 The overall goal of the CSIRT is to maintain the security service triad of confidentiality, integrity, and availability to electronic information and information technology assets in response to computer security inci dents. CSIRT Objectives The objectives of the CSIRT are: 1. Define the incident response policies, procedures and services provided. 2. Create an incident reporting capability. 3. Handle the incident: a. Identify the incident; b. Contain the incident; and c. Eradicate the incident. 4. Recover from the incident: a. Determine the cause of the incident; b. Repair the damage; and c. Restore the system. 5. Investigate the incident: a. Identify the cause; b. Collect evidence; and c. Assign blame. 6. Assist in the prevention of a reoccurrence of the incident.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 10 The Need for a CSIRT Computer Security Incident Response is not an option. No matter how well protected an organisation is there is no such thing as zero risk, even with trained personnel, proper technology and tested procedures. It is im possible to accurately and consistently, predict the type, frequency or severity of attacks.

Vulnerabilities are published at an ever -increasing rate and as the complexity of technology increases, so does the likelihood that the number of vulnerabilities will in turn. The nature of computers and networking is increasing the initial threat base and introducing new motivations and capabilities that did not previously exist. The result is that computer security incidents will occur.

There is an entire secu rity operational phase dedicated to detection. Numerous detection mechanisms including technological, human, and procedural exist and are often employed but it is of little sense to put intrusion monitoring and detection mechanisms in place if there is no plan to deal with the intrusions when they occur.

Benefits There are numerous benefits spanning various quantifiable and qualifiable categories that the existence of a CSIRT provides to an organisation. Benefits include such areas as: Economic The exi stence of a CSIRT often reduces the amount of staff and staff time required to handle an incident compared to not having a CSIRT. This translates to less time required by the incident handlers to manage the incident and reduces the amount of lost producti vity of the workers affected by the incident. As the age old adage professes: time is money. The less time wasted handling incidents the less spent on the costs of the incident handlers and the smaller the loss to productivity. This is all in addition, o f course, to lost revenue, cost of damages and any insurance deductible. Public Relations News of incidents can severely damage an organisation’s reputation but efficient handling minimises potential for negative exposure. The existence of a CSIRT demons trates that an organisation is taking the responsibility of incident handling seriously. In addition, a CSIRT will usually have communication procedures in place to deal specifically with communicating the proper information to the proper audiences. This will help dispel rumours and ensure only factual information is reported toKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 11 audiences such as employees, the public, the press, the shareholders, other organisations or the authorities. Legal Legal responsibilities are changing as the industry matures th at may soon place the onus on organisations to secure their networks and stop attacks originating from them as the result of an attack, also known as downstream liability. A CSIRT may become a necessity to comply with government regulations. A CSIRT will also help deal with any liability issues that may arise due to the distribution of information whether correct or erroneous on attacks involving another organisations or product vulnerabilities.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 12 Return on Investment The return on investment (ROI) of a CSIRT is not a straightforward or easily calculated number but just as with the return on security investment (ROSI), with a little effort it can be determined. In short, a CSIRT doesn’t make money but rather focuses on reducing the losses due to the occur rence of an incident by containing, eradicating, and recovering from it as quickly and efficiently as possible. The earlier the incident is contained, the lower the chances of widespread damage. Additionally, a shorter the recovery period translates into a reduction in the amount of lost productivity. Annual Loss Expectancy To determine the costs of security incidents, we must first examine the Annual Loss Expectancy (ALE) of security incidents. The ALE of a security incident is the amount of losses in dollars multiplied by the likelihood of the loss occurring multiplied by the amount of times it is likely to happen over the course of a year. This gives us the calculation: ALE of security incidents = Loss ($) x Likelihood (%) x Frequency (#) This is where incident costing comes into play. Incident costing will be examined in further detail later in the paper. Two types of costs exist when dealing with security incidents: quantifiable costs, such as the wages of the incident handlers, and qualifiabl e costs, such as loss to reputation. In addition these cost categories can be divided into costs incurred responding to and repairing damages resulting from the incident and costs associated with lost productivity and non -realized revenue. This calculati on needs to be performed for each type of incident. This will help identify what types of security incidents result in the largest losses.

This may be the area of focus when defining the services the CSIRT will provide.

Savings Provided by a CSIRT Dete rmining the savings provided by a CSIRT for a particular organization requires a little research work combined with some educated guessing.

You need to build some numbers. It will require looking at how the amount of damage increases over time. With cer tain incidents, such as viruses, damage can grow exponentially over time. W ith other types of incidents damage will grow at a steady rate. W hat needs to be determined is difference in containment, eradication, and recovery time a CSIRT provides versus no t having a CSIRT. This will calculate into theKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 13 savings in terms of the reduction in damage to the system and reduced lost productivity.

Cost of a CSIRT The costs of building and operating the CSIRT need to be examined. The costs will depend on the numbe r and types of services provided, as well as, the size of the constituency they are provided to. This will help identify which services will cost the most to provide to which constituencies. This will help focus which services should be provided and to whi ch constituency.

Actual Savings of a CSIRT The cost of building and operating the CSIRT for a particular service and constituency should be weighed against the overall savings it provides.

This gives us the calculation: Actual Savings of a CSIRT = Sav ings Provided –Cost of Building and Operating CSIRT ROI The ROI of a CSIRT is a calculable number, which will vary according to the services provided and the constituency they are provided to. It translates not into a positive gain for an organization but rather a reduction in the losses. Facts and Statistics The following list of facts and statistics is meant by no means to be all -inclusive and is merely for the purpose of further illustrating the necessity of the CSIRT within the organisation. They are of excellent use in support of a business case in favour of a creating a CSIRT.

 Over time the level of knowledge required to attack has decreased while the attack complexity and the potential level of damage has increased.  Carnegie Mellon’s CERT Coordination Centre (CERT/CC) illustrates the number of reported cyber incidents has increased from six in 1988 to eighty - two thousand in 2002.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 14  The time required for malicious code to spread to a point where it can do serious infrastructure damage halves eve ry eighteen months.  The speed with which an organisation can recognise, analyse, and respond to an incident will limit the damage and lower the cost of recovery. 2  Results from Computer Security Institute (CSI) seventh annual "Computer Crime and Security Survey":  Ninety percent of respondents (primarily large corporations and government agencies) detected computer security breaches within the last twelve months.  Twenty -five percent (25%) of those acknowledging attacks reported from two to five incidents. Thirty -nine percent (39%) reported ten or more incidents. 2CERT©/CC:ComputerIncidentResponseTeamFAQ.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 15 Roles and Responsibilities of a CSIRT The roles and responsibilities of the CSIRT need to be clearly outlined, and the services the CSIRT provides need to be clearly defined and understood b y both the CSIRT itself and its constituency. It is essential to define services, service levels, and the constituency they will be provided to. The exact functions of the CSIRT will vary depending on the organisational resources and requirements for inf ormation protection. If resources are lacking in the requisite expertise then it may require outsourcing or funding which would require a limit to the services.

The activities performed by the CSIRT can be divided into two categories: real - time incident response activities and non -real -time incident response activities. Non -real -time incident response activities can be subdivided into pre -incident and post -incident activities. Non -Real -Time Incident Response Activities -Pre -Incident Activities In ord er for a CSIRT to be effective and successful in their response activities, a good deal of preparation is required. Issues, such as what services will be provided, to which constituency, under what authority and at what cost to whom, need to be determined prior to handling an incident. There are a number of activities that can be performed including creating a charter, policy, incident reporting procedures, incident tracking and handling procedures, and incident costing. When the legwork is handled prior to the onset of an incident, the handling of the incident is more structured and likely to have a more positive outcome. It is wise to adhere to the age old adage, “an ounce of prevention is worth a pound of cure”. Charter The first piece of work that needs to be tackled is writing a CSIRT project charter. The charter will address issues such as the mission statement, the types of incidents addressed, the services provided, the constituency, the authority and the funding.

The mission statement shou ld define the core activities of the CSIRT. It should also clearly outline the overall goals and objectives. Refer to the ‘Defining a CSIRT’ section of this paper for more information on the goals and objectives of a CSIRT. In addition, it should align with your organization’s security policy. The types of incidents that the CSIRT will address must also be outlined. Refer to the ‘Background’ section of this paper for examples of categories and types of computer security incidents.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 16 In addition to the t ypes of incidents that the CSIRT will respond to, should be the actual services that will be provided for each one. It is essential that there are clearly defined services for each type of incident to eliminate ambiguity. In addition to the services that will be provided, should be the service levels that accompany them. Include the hours of operation and levels of support. Is this a 24 -7 capability or are incidents handled with one service level during working hours and another service level for evening s and weekends? Next is the issue of the constituency. To whom will these services be provided?

For small organisations this may not be an issue, but for large organisations a perimeter will need to be established based on boundaries such as:

- Geograph ical location; - Organisational Group or Division; or - Organisational function. The next issue that the charter should address is that of authority. The CSIRT authority must be granted from management and clearly outlined in the security policy.

Finally t he issue of funding needs to be addressed. W here will the CSIRT receive the budget it requires to provide its services? The services could be charged out proactively, like insurance, where in order to operate you must pay a premium, or reactively, by att empting to recover costs from the party responsible for the cause.

Policy In order to eliminate any ambiguity that may arise, it is necessary to have clearly defined security policies, based on or in adherence to acts and laws, which map to procedures and standards. Simply stated, a policy is the rule and a standard or procedure is how to acceptably perform the process or function in adherence to the rule.

The first step is to research the laws of the country or region in which the organisation is ope rating. It is good idea to refer to legal counsel for input. Any policy an organisation writes, whether a security policy or not, must adhere to these. In addition, the organisation policies must comply with industry regulations. International and mult inational organisations need to consider the legal and cultural differences of the areas in which they operate.

The main policy of importance with respect to incident response is the security policy. A complete security policy should address topics such as, access to information, information storage and disposal, and communication. If they areKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 17 not currently addressed in the security policy, they will need to be addressed prior to or during the construction of the CSIRT. Other policies, should they exist within the organisation, include the incident reporting policy, which should encourage an open reporting environment, and include the incident response policy, which should differentiate between human error and malicious intent.

The legal department shou ld review all policies prior to putting them in place. W ith respect to the computer incident response policy, the legal department should be consulted at the very least on the liability issues. Issues of importance include downstream liability, liability of the distribution of information, and liability due to monitoring. Downstream liability deals with when a compromised computer damages another computer. Liability due to the distribution of information, whether the information was correct or erroneous , includes activities such as distributing information on an attack involving another organisation or publishing product vulnerabilities. Liability due to monitoring, deals with whether you must inform users of monitoring or any changes in monitoring pract ices. Incident reporting procedures In order for a CSIRT to respond to an incident, there must be a mechanism in place to notify it that an incident has, is, or will occur.

The first step is to determine a Point of Contact (PoC) responsible for the coo rdination of receiving reports and notifying the CSIRT. Reports can be received from a number of different sources, both human and non -human, Incident may be reported in the real or non -real time review of logs from an Intrusion Detection System (IDS), a n Intrusion Prevention System (IPS) or Firewalls. Employees of affected systems may report an incident or symptom of an incident. W histleblowers may report something they have witnessed or heard. Outsiders, such as other affected organisations or, in so me cases, the attackers themselves, may report the incident.

In order to ensure the efficient and timely notification of the CSIRT, accurate and up -to-date contact Information should be kept. The primary method of contact should be indicated and the CSIR T contact information should include:  Telephone number;  Facsimile number;  Electronic mail address;  W eb site;  Mailing address; and  Additional information:

 Operating Hours;  Time zone; andKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 18  Team members. Incident awareness and incident reporting awareness p rograms should be engaged. Users should be made aware of symptoms that may constitute an incident and encouraged to report incidents without fear of reprisal.

Some of the possible symptoms of an incident are listed in the following table, which has been divided into two categories obvious and discrete:

Obvious Discrete W eb Defacement New, modified or deleted User Accounts Unauthorized access New, modified or deleted files System Crash Anomalies Suspicious or unexplained activity Table 3 –Incid ent Symptoms Incident information tracking and handling procedures In order to maintain control over all the information regarding the incident and reduce any possible confusion, it is a good idea to create an incident ticket.

Tickets must have a uni que identification number. In the case of multiple tickets opened pertaining to the same incident, designate one the master and the subsequent the dependents, providing links between them.

Tickets should capture all the incident information. Everything should be documented including the date and time and where it was reported. If it was reported from a person, include their name, location, and contact information. If it was reported from an automated system, include the hardware manufacturer, operatin g system type and version, the name of the host, the physical location of host, the network address and the MAC address. This information should be collected for both the reporting system and affected system. Another important piece of information that s hould be kept up -to-date is the status. Handoff procedures should be determined for when tickets are transferred between individuals or departments. Part of these procedures should include escalation and de -escalation procedures. Finally track all time spent on CSIRT activities by all parities. This should be done at regular intervals to ensure accurate reporting.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 19 Costing an Incident Unfortunately costing an incident is not an exact science but with a little effort a reasonably accurate amount can be determined. The Incident Cost Analysis Modelling Project or ICAMP has provided some excellent insight into costing methodologies.

To cost an incident, both the quantifiable and qualifiable costs must be included.

Additionally, not only do the actual lo sses need to be considered, but also, the lost opportunity for gains. W hat this means is, all other factors equal, if you have one of only two web sites that sells widgets and your web site becomes unavailable for a time period, customers are likely to pu rchase their widgets from the other web site. So the sales you would have normally realised during that time period, the gains, are lost or not gained.

W hen trying to cost an incident there are several considerations. There is the cost of damages, the c ost of the wages of incident handlers and those prevented from working, lost revenue, loss to reputation and insurance deductible.

The wages of both the incident responders and those of the people prevented from working. There are a number of questions yo u will need to ask:  W ho worked on responding to or investigating the incident?  How many hours did each of them spend?  How many people were prevented from working because of the incident?  How much productive time did each of them lose?  How much do you pay each of those people to work for you?  How much overhead do you pay (insurance, sick leave, etc.) for your employees? 3 Lost revenue again deals with non -realised gains. Data can be extrapolated from the current revenue stream and compared against in dustry trends. Loss to reputation is difficult to quantify but can result in the loss of current and potential clients.

Other considerations are lost contracts or bids, penalties for delays in payments or projects or lawsuits for breach of contract.

Re al Time Incident Response Activities 3Dittrich, David A. Developing an Effective Incident Cost Analysis Mechanism .Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 20 Real time incident response activities deal with the actual handling and response measures taken once the incident has occurred.

First and foremost, the protection of human life and safety takes precedence over ever ything. The figure below outlines, sequentially, the categorised activities performed by the different functional areas or groups during the handling of an incident. Every organisation is distinct in its structure and the division of the roles and respo nsibilities. Incident handling is made up of the incident identification, containing the incident, and eradicating the incident, and is handled by the CSIRT. Incident recovery includes identifying the damage, repairing the damage, and restoring the syste ms. The Business Continuity Planning or Disaster Recovery Team usually performs the recovery activities. The incident investigation is comprised of activities to identify the cause of the incident, collect evidence, and assign blame. The Security Team us ually performs the investigative activities. The IT Security Team performs incident reoccurrence prevention. During the incident restitution activities the decision of whether to seek reparation for any damages or losses suffered needs to be decided by management with input from the legal department or legal counsel. Finally the incident communication activities, handled by a communications team, include the various internal and external communications.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 21 Figure 2 –Incident Response Flow Incident Handling The Incident Handling phase is handled by the CSIRT and is divided into three stages: identifying the incident, containing the incident, and eradicating the incident.

Incident Identification Identifying the incident is comprised of a number o f activities. The first step is to determine whether it is an actual incident or simply perceived. This requires that the incident report be verified. It also needs to be determined whether this is the first report or a duplicate report. How to handle duplicate reports should be laid out in the tracking and handling procedures.

Next, it should be determined whether it is a security incident or non -security incident to determine whether it falls under the jurisdiction of the CSIRT. TheKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 22 types of incide nts qualified as security incidents should be indicated in the CSIRT policies.

The scope of the incident needs to be determined by uncovering what has been affected.

A priority level needs to be assigned to determine the immediate resource requirements . Certain incidents, such as a virus outbreak, may need all necessary resources activated in order for it to be handled immediately to reduce the amount of damage that will occur.

Other types of incidents, such as receiving a piece of SPAM mail, will n ot cause immediate or widespread amounts of damage. As well, prioritising incidents will help an organisation better co -ordinate its resources if it is hit by multiple incidents simultaneously.

A simple scale that can be used to prioritise incidents is loc ated at the right in figure 3 –Incident prioritization matrix. The factors it uses to prioritise the incidents are the level of confidentiality of the information and the severity of the damage. Both are measured using a low -medium -high scale that needs t o be decided on by each individual organisation, in terms of how it will be measured. Figure 3 –Incident Prioritization Matrix Once it has been verified that it is an actual security incident, the initial scope and priority assigned, it is time t o activate the CSIRT. In some organisations the CSIRT is an operational team, in which case the previous steps would likely have been handled by it, and in others it is a group brought together at the time of an incident. It is absolutely essential that an up -to-date contact list be established and maintained for an emergency situation, such as an incident, where time is of the essence. Procedures should be established for the creation, maintenance, and testing of this contact list. The CSIRT contact li st should include entries such as the persons job function, since in larger organisations employees may not know the name of the person to contact, as well as, their level of authority.

The employee’s name and contact information, including phone numbers,both office and cell, pager number, email, and any other means of contacting the individual must be included. The employee’s hours of work and availability, as Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 23 they could be away on vacation and in both cases there may be a backup employee designated to replace him or her. Some additional information that may want to be included on the contact list are the numbers for contacting emergency services, such as the fire or police departments or third party support providers.

Incident Containment The purpo se of containing the incident is simply to limit extent of the attack. Temporary countermeasures should be taken should be taken appropriate to the situation. Some of these can include:

 Change network address;  Quarantine the affected files or systems;  Pull plug, either network or power;  Change firewall rules;  Increase the amount of bandwidth;  Apply system patches;  Monitor the system or network activity;  Set traps; or  Disable certain functions. Eradicate Incident Eradicating the incident deals with e liminating the threat from the systems to prevent it from causing further damage. Ensure all the necessary information was collected and copies were made and tested. Archive bogus files before deleting them. Correct any hardware or software bugs or confi guration errors. W hen dealing with software, ensure the most current anti virus software is installed and operating. Clean and reformat all the infected media. When making backups, ensure they are clean.

Incident Recovery The Business Continuity Planni ng or Disaster Recovery Teams are best suited to handle the recovery activities surrounding an incident. There are three stages to the incident recovery: identifying the damage that has occurred, repairing the damage, and then restoring the system. Integr ity assurance software can assist in identifying subtle or hidden changes to a system. Restoring the system is simply returning the system to normal operations. The recommended recoveryKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 24 order is critical systems first, non -critical but high demand systems second, and finally all remaining systems.

Investigation The security team responsible for investigations should handle the incident investigation as they will have the most knowledge and experience in these situations. The three main activities inclu de identifying the cause, collecting evidence, and assigning blame.

Identifying the Cause Identifying the cause of an IT security incident will often require forensic analysis.

Sometimes the vulnerability exploited will be obvious, other times it will require an extensive search. Passive Techniques Active Techniques Logs –Network/Host IDS, FW, Apps, Email, IRC Scan Network/Host Monitor Engage Attacker Network Traffic Interview Host Activity Video Surveillance Phone Records Timecards Build ing Entry/exit logs Honey Pot Table 4 –Forensic Techniques 4 There is wide variety of forensic tools in existence, both commercial and freely available.

W hen conducting an investigation there are some important actions to perform prior to shuttin g down host including:  Make a list of all the processes running;  Make a note of the status of network interface, is it in promiscuous mode;  Make list of all the listening ports and active network connections; and  Make copies of executable files associated with every running process on the system or dump the contents of system memory to a file. 5 4Hillier, Peter, Fortier, Christian. Cyber Incident Response . Presentation for the 15 thCanadian Information Technology Security Symposium 2003.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 25 Collect Evidence Computer evidence can often be divided into two types, volatile and non -volatile. Volatile evidence refers to evidence that is easily comprom ised or lost if not handled properly. The table below outlines some of the types of volatile and non -volatile evidence. Volatile Non -Volatile Memory Physical Equipment Active Processes Persistent storage Active Network Connections Printouts Contents of a computer screen Recorded Video Surveillance Table 5 –Evidence Types Make a bit -for -bit copy of the file system for evidence. Always remember to perform as few operations as possible prior to making the copy to maintain its integrity. Make two c opies, one for forensics use and one for creating a new system disk. Finally, remove the hard drive and secure it as evidence.

It is important to preserve evidence in its original form. Record the names and contact information of all the people present and clearly detail any actions performed. Remember sometimes a picture is worth a thousand words.

Record each piece of evidence. Include a description, the location and the time it was found. For physical evidence, indicate who has handled the evidence and for electronic evidence, indicate any processing that has occurred. W hen the evidence has been properly recorded tag and seal it. Finally assign an evidence handler responsible for the storage of the evidence.

Take detailed notes during the investi gation as they can be used in legal proceedings. Good notes will include your actions and the actions of others, when the action was taken, along with the reason for the action taken.

Remember to sign and date the bottom of each page.

Assign Blame The final step performed by the Investigative Team is to assign blame based on the evidence collected. A simplistic chart was created to assist in determination.

5Brezinski, Dominique, and Dittrich, Dave. Black Hat Las Vegas '00 Training Intruder Discovery / Tracking and Compromise Analysis.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 26 Cause Origin Intent Target Direct Attack Intention al Indirect Attack Internal Acci dent al N/A Direct Attack Intention al Indirect Attack Human External Accident al N/A Random -Nature N/A N/A Direct Attack Intention al Indirect Attack Non - Human Non -Random - Initiated by Humans Accident al N/A Table 6 –Assigning Blame IT Sec urity The IT Security Team handles the incident reoccurrence prevention activities.

The goal is to put a short -term solution or work -around in place to prevent the further exploitation of the vulnerability. The long -term solution that will mitigate the risk by preventing further exploitation of the vulnerability is also handled by the IT Security Team, but falls out of the context of incident response and into prevention and risk management operational processes.

Management/Legal It is at the decision of management whether or not to seek reparation. The situation will often dictate what the best course of action is for the organization.

The involvement of the authorities can lead to widespread publication of the incident and negative exposure. Legal proceedings can be lengthy and costly and management may not see adequate benefit to make these worthwhile. The legal department should be contacted in these situations to ensure any decision made is in compliance with the laws of the country or region in which it is operating.

CommunicationsKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 27 Communication during an incident is essential to ensure efficient and effective containment. To maintain control, the “need-to-know” principle should be observed. A communication plan must be developed. It should detail what information is to be communicated to whom, when, how and by whom.

The plan should detail precisely what information is to be communicated. Any statements made should be clear, concise, qualified, and based on substantiated facts.

The intern al and external audiences that have a need -to-know should be indicated in the plan. Communication should occur with the appropriate stakeholders including the affected areas within the organisation, the affected clients or partners, the press or the author ities. It is important to realise that information communicated with audiences external to the organisation may become public.

The plan should indicate under which circumstances communication should occur. Is it for strictly informational purposes, such as status reports, or as part of notification procedures used to alert other organisations?

Additionally, the point in time that communication should take place needs to be determined. W ill communication occur when an incident is declared or after it ha s been handled? Will communications be an ongoing process or a single occurrence?

How will communications be carried out? W hat communications media is appropriate, phone, cell, fax, email?

W ho carries out the communications? Does a designated communica tions department or team handle all communications?

W hen creating a communication plan organisations spanning geographical areas that are subject to differing laws, such as countries, must take that into consideration.

Non -Real -Time Incident Response Ac tivities -Post -Incident Activities Post Mortem An incident report should be completed at the conclusion of every incident. If possible an independent body should conduct the report. The report should detail:

 W hat the impact to the organisation was; Comment [M1]: I don’t understand the sentence. “Will communications be what?”Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 28  Achronological sequence of events;  The incident identification information including how it was discovered, when and by whom;  How the incident was handled;  A list of all activities performed including personnel contacted, when, by whom and why;  The things that were done well and those that need improvement; and  The lessons learned. The report is valuable for reference for similar incidents in the future, for obtaining a monetary estimate of damage, and to determine whether updates or changes to the CSIRT p rocedures are needed. W hen completed the report should be presented to senior management to decide, with consultation and input from the legal department, whether legal action should be taken. It should also be passed to IT security to introduce preventa tive measures to reduce the likelihood of a reoccurrence of the incident.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 29 Requirements of a CSIRT In order to operate a CSIRT effectively and successfully, there is a need to add to the requirement triage of people, process, and technology, with author ity and funding. Additionally, there is a need to qualify the requirements accordingly:

- Proper, up -to-date technology; - Correct, trained people; - Complete and tested processes and procedures; - Defined authority and support; and - Adequate funding. Proper, U p-to-date Technology The technology required to perform the CSIRT functions timely and effectively is fundamental to the successful handling of incidents. Tools for notification purposes, whether phone, cell phone, web page, email, palm pilot, or other a re necessary for timely response. Forensic tools and investigative tools, including all the hardware and software need to be as advanced as possible to compete with the ever -increasing complexity of incidents and methods. Correct, Trained People Ensur ing the CSIRT members are the right people and are properly trained is key. A CSIRT usually deals with high -stress situations and uncertain hours. Members should have personality traits that are suited for stressful and uncertain situations.

The decisi on needs to be made of whether CSIRT members should be made up of in -house employees or outsourced to a company providing incident response services. If the CSIRT is being kept in -house the decision of whether existing employees will be used or new employ ees hired specifically for the CSIRT. Ensuring the CSIRT member’s chosen receive proper training is essential to its success. Training is offered by several organisations including:

 CERT/CC -www.cert.org ;  FIRST -www.first.org ; and  SANS -www.sans.org . It is important to dedicate a percentage of time to learning about incident trends and security technologies.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 30 Complete and Tested Processes and Procedures Having written plans eliminates much of the ambiguity, which occurs during an incident, and will lead to a more appropriate and thorough set of responses. A Computer Security Incident Response Policy is the basis for all processes and procedur es. It is vitally important that all processes are tested regularly to determine their shortcomings, should they exist. The process to be followed during an incident should be clear and thorough.

Defined Authority and Support The Computer Security In cident Response Policy should clearly indicate the authority granted to the CSIRT. Senior management must buy -in and support the CSIRT. There is often a degree of apprehension during an incident, causing management unrest. As well, certain areas will be forced to surrender control of their area of responsibility. The authority of the CSIRT cannot come into question during the incident, as it will only lead to unnecessary delays in the incident handling.

Adequate Funding How the CSIRT will be funded i s a vital issue. It is impossible to accurately predict either the number or severity of incidents. As such it cannot operate under a normal budget.

There are several possible methods of funding the CSIRT including an insurance model and a cost recovery model. In the insurance model all the different areas of an organisation fund the CSIRT like paying insurance. In the cost recovery model, the areas affected by the incident pay for the cost of the incident response in predetermined proportions. The in surance model can also be combined with the cost recovery model so that each area pays into a CSIRT fund like insurance and at the time of the incident the affected areas pay a deductible to offset some of the loss to the pool of money. There are many pos sible methods to fund a CSIRT but it is essential to predetermine how it will be accomplished.

Organisational Buy -In Finally, to be successful, there must be a buy -in from the entire organisational. To obtain this there must be an understanding of what organisational needs the CSIRT satisfies and how it satisfies them. In addition, there should be an understanding of how the CSIRT improves the overall state of security within theKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 31 organisation. The key players of the CSIRT must understand the needs and benefits the CSIRT provides in order to ensure their buy -in. The key players are examined in further detail in the next section.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 32 Areas Involved in a CSIRT The CSIRT should be proportionally sized with respect to the organization and with the incident t o ensure it has adequate personnel to perform its duty. There is a need to predetermine the chain of command for each incident type, as it may be different depending on type, or, may even change during a single incident.

Representation is suggested from , but not limited to, the following areas (Not all incidents will require representation from all the areas listed but some incidents may require representation from other areas not listed): Area Incident Handler Role Function Management Oversight Make d ecisions on issues not outlined in procedures Information Security Lead Investigations Information Technology Support Provide technical support as required Physical Security Primary Assess Physical Damage Business Continuity Physical Property Investigat ion Safeguarding Evidence Legal Consultation Provide legal advice when requested Audit Secondary IT Audit Financial Audit Human Resources Consultation Provide information with regards to situations involving employees Communications Secondary Communica te with: Internal: shareholders/owner, management, staff External: press, public, vendors, law enforcement Table 7 –Areas Involved W hen choosing CSIRT members, there are certain skills and personality traits that should be sought. The most successful members are individuals who are dedicated, innovative, detail -oriented, flexible, and analytical. They are problem - solvers, good communicators and able to handle stressful situations. 6 6CERT©/CC:ComputerIncidentResponseTeamFAQ.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 33 Few organisations are either large enough or have the budget to empl oy a fully functional, dedicated CSIRT. As a result there are a number of courses of action.

The first is to assemble the team at the time the incident is declared. The CSIRT members must be able to drop, put on hold, or reassign their current activiti es in order to focus on their incident response role.

The second possibility is to have a small, dedicated CSIRT that expands with representation from the appropriate areas depending on the incident. Again all non -dedicated CSIRT members must be able to drop, put on hold, or reassign their current activities in order to focus on their incident response role.

The third course of action is to outsource the incident response role to specialized and experienced computer incident response organisations.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 34 Co nclusion Computer Security Incident Response is not an option. No matter how well protected an organisation is there is no such thing as zero risk, even with the trained personnel, proper technology, and tested procedures. It is impossible to accuratel y and consistently, predict the type, frequency, or severity of attacks. Vulnerabilities are published at an ever -increasing rate and as the complexities of technology increases, so is the likelihood that the number of vulnerabilities will in turn. The n ature of computers and networking is increasing the initial threat base and introducing new motivations and capabilities that did not previously exist. The result is that computer security incidents will occur.

A Computer Security Incident Response Team (CSIRT) is one of the best ways to bring together the expertise necessary to deal with the wide range of possible computer security incidents that can arise.

This paper introduced the reader to the fundamentals of CSIRT and some important considerations of what is required to build and operate one both effectively and successfully.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 35 Bibliography 1. Borodkin, Michelle. Computer Incident Response Team. (September 15, 2001). SANS Infosec Reading Room.

Available at: http://www.sans.org/rr/incident/CIRT.php . 2. Brezinski, Dominique, and Dittrich, Dave. Black Hat Las Vegas '00 Training Intruder Discovery / Tracking and Compromise Analysis.

Available at: http://staff.washington.edu/dittrich/talks/blackhat/blackhat/ . 3. Brownlee, N., and Guttman, E. RFC 2350: Expectations for Computer Security Incident Response. (June 1998). Internet Engineering Task Force, Network W orking Grou p. Available at: http://www.ietf.org/rfc/rfc2350.txt?number=2350 . 4. CERT®/CC:Computer Security Incident Response Team (CSIRT) Frequently Asked Questions (FAQ).

Available at: http://www.cert.org/csirts/csirts_faq.html . 5. Committee on Institutional Cooperation. Incident Cost and Analysis Modelling Projects (ICAMP) II.

Available at:

http://www.cic.uiuc.edu/groups/ITSecurityW orkingGroup/archive/Report/IC AMP.shtml 6. Computer Crime and Security Survey from the Computer Security Institute (CSI) in partnership with the FBI . Available at: http://www.gocsi.com/press/20020407.html . 7. Dittrich, David A. Developing an Effective Incident Cost Analysis Mechanism . Security Focus, June 12, 2002. Available at: http://www.securityfocus.com/printable/infocus/1592 . 8. Fraser, B. RFC: 1244: Site Security Handbook. (September 1997) Internet Engineering Task Force, Network Working Group.

Available at: http://www.ietf.org/rfc/rfc2196.txt . 9. Hillier, Peter, Fortier, Christian. Cyber Incident Response . Presentation for the 15 thCanadian Information Technology Security Symposium 2003. 10. Kaplan, Simone. When Bad Things Happen to Good People. (M ay 2003). CSO Magazine, csoonline.com.

Available at: http://www.csoonline.com/read/050103/bad.html . Formatted Formatted Formatted Comment [M2]: Did you follow any convention styles for your bibliography?I guess since they are all web articles, youcan either alphabetically order by authoror title.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. 36 11. Rhodenizer, Elizabeth. Establishing an Information Protection Centre, Lessons Learned. (Ma y 2003). Paper prepared for the 15 thCanadian Information Technology Security Symposium 2003. 12. W est -Brown, M. J., Stikvoort, D., and Kossakowski, K. (1998). Handbook for Computer Securirty Incident Response Teams (CSIRTs). Carnigie Mellon, Software Enginee ring Institute, Pittsburg, PA. Available at:

http://www.sei.cmu.edu/publications/documents/98.reports/98hb001/98hb001abs tract.html 13. W est -Brown, Moira. Avoiding the Trial -by -Fire Approach to S ecurity Incidents. SEI Interactive: Security Matters, Sep 1999. Available at:

http://interactive.sei.cmu.edu/news@sei/columns/security_matters/1999/m ar/security_matters.htm. Deleted: Rhodenizer, Elizabeth. Establishing an InformationProtection Centre, Lessons Learned.(May 2003). Paper prepared for the15thCanadian Information Technology Security Symposium2003. ¶ Borodkin, Michelle. Computer Incident Response Team.(September 15, 2001). SANS Infosec Reading Room. ¶ Available at:http://www.sans.org/rr/incident/CIRT.php. ¶ Deleted: ¶ ¶<#> Brownlee, N., and Guttman, E. RFC 2350: Expectations for Computer Security IncidentResponse. (June 1998). Internet Engineering Task Force, NetworkWorking Group. ¶ Available at:http://www.ietf.org/rfc/rfc2350.txt?number=2350. ¶ ¶<#> Brezinski, Dominique, and Dittrich, Dave. Black Hat Las Vegas '00 Training Intruder Discovery /Tracking and Compromise Analysis. ¶ Available at:http://staff.washington.edu/dittrich/talks/blackhat/blackhat/. ¶ ¶<#> CERT®/CC:Computer Security Incident Response Team (CSIRT)Frequently Asked Questions (FAQ). ¶ Available at:http://www.cert.org/csirts/csirts_faq.html. ¶ ¶¶¶¶¶<#> Hillier, Peter, Fortier, Christian. Cyber Incident Response . Presentation for the 15 thCanadian Information Technology SecuritySymposium 2003. ¶Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2004, As part of GIAC practical repository. Author retains full rights.© SANS Institute 2004, Author retains full rights. Last Updated: July 9th, 2016 Upcoming Training Rocky Mountain 2016 - SEC401: Security Essentials Bootcamp Style Denver, CO Jul 11, 2016 - Jul 16, 2016 vLiveCommunity SANS Omaha SEC401 - Solutionary/Academy Omaha, NEJul 11, 2016 - Jul 16, 2016 Community SANSSANS Rocky Mountain 2016 Denver, COJul 11, 2016 - Jul 16, 2016 Live EventCommunity SANS San Diego SEC401 San Diego, CAJul 18, 2016 - Jul 23, 2016 Community SANSSANS San Antonio 2016 San Antonio, TXJul 18, 2016 - Jul 23, 2016 Live EventSANS Minneapolis 2016 Minneapolis, MNJul 18, 2016 - Jul 23, 2016 Live EventCommunity SANS Seattle SEC401 Seattle, WAJul 25, 2016 - Jul 30, 2016 Community SANSSANS vLive - SEC401: Security Essentials Bootcamp Style SEC401 - 201607, Jul 25, 2016 - Sep 07, 2016 vLiveSANS Boston 2016 Boston, MAAug 01, 2016 - Aug 06, 2016 Live EventSANS Dallas 2016 Dallas, TXAug 08, 2016 - Aug 13, 2016 Live EventSANS Portland 2016 Portland, ORAug 08, 2016 - Aug 13, 2016 Live EventCommunity SANS Atlantic City SEC401 Atlantic City, NJAug 15, 2016 - Aug 20, 2016 Community SANSCommunity SANS Columbus Collaboratory SEC401 Columbus, OHAug 15, 2016 - Aug 20, 2016 Community SANSCommunity SANS Omaha SEC401 - Solutionary/Academy Omaha, NEAug 15, 2016 - Aug 20, 2016 Community SANSMentor Session - SEC401 New York, NYAug 15, 2016 - Sep 22, 2016 MentorSANS Virginia Beach 2016 Virginia Beach, VAAug 22, 2016 - Sep 02, 2016 Live EventSANS Chicago 2016 Chicago, ILAug 22, 2016 - Aug 27, 2016 Live EventMentor Session - SEC401 Louisville, KYAug 22, 2016 - Oct 24, 2016 MentorCommunity SANS Raleigh SEC401 Raleigh-Cary, NCAug 22, 2016 - Aug 27, 2016 Community SANSSANS Adelaide 2016 Adelaide, AustraliaSep 05, 2016 - Sep 10, 2016 Live EventSANS Northern Virginia - Crystal City 2016 Crystal City, VASep 06, 2016 - Sep 11, 2016 Live EventSANS Network Security 2016 Las Vegas, NVSep 10, 2016 - Sep 19, 2016 Live EventCommunity SANS San Antonio SEC401 - Onward/Academy San Antonio, TXSep 12, 2016 - Sep 17, 2016 Community SANSCommunity SANS Albuquerque SEC401 Albuquerque, NMSep 12, 2016 - Sep 17, 2016 Community SANSCommunity SANS Columbia SEC401 Columbia, MDSep 12, 2016 - Sep 17, 2016 Community SANSCommunity SANS Sacramento SEC401 Sacramento, CASep 12, 2016 - Sep 17, 2016 Community SANSNetwork Security 2016 - SEC401: Security Essentials Bootcamp Style Las Vegas, NV Sep 12, 2016 - Sep 17, 2016 vLiveCommunity SANS Detroit SEC401 Detroit, MISep 12, 2016 - Sep 17, 2016 Community SANSMentor Session - SEC401 Des Moines, IASep 13, 2016 - Oct 25, 2016 MentorSANS London Autumn London, United Kingdom Sep 19, 2016 - Sep 24, 2016 Live EventCommunity SANS Augusta SEC401 - Academy/Fort Gordon Augusta, GASep 19, 2016 - Sep 24, 2016 Community SANS