Computer Security Incident Response Team (CSIRT) Guide Maliha Alam Mehreen Shahid Plan Establish Connect Be Secure! CSIRT Coordination Center Pakistan 2014 i
Contents 1. What is CSIRT?... 1 2. Policy, Plan and Procedure Creation... 1 2.1 Incidents and Events... 1 2.2 Incident Response Policy, Plan and Procedure... 1 3. CSIRT Framework... 2 3.1 Mission Statement... 2 3.2 Incident Response Team Structure... 3 3.3 CSIRT in different hierarchies and their relations... 4 4. CSIRT Services... 4 4.1 Reactive Services... 5 4.2 Proactive Services... 5 4.3 Security Quality Management Services... 5 5. Incident Management... 6 5.1 Incident Handling Phases... 7 5.1.1 Preparation... 7 5.1.2 Identification... 7 5.1.3 Containment... 8 5.1.4 Eradication... 8 5.1.5 Recovery... 8 5.1.6 Lessons learned... 8 5.2 Incident Handling Process Workflow... 9 5.3 Information Flow for CSIRT... 10 5.4 Incident Management Systems... 12 5.4.1 Need for Incident Management Systems... 12 5.4.2 Functional Overview of Incident Management Systems... 12 6. NUST CSIRT... 13 6.1 Mission Statement... 13 6.2 NUST CSIRT Website... 13 6.3 NUST CSIRT Services... 13 6.4 Incident Reporting methods... 14 6.5 Staying connected with NUST CSIRT... 14 References:... 15 ii
List of figures Figure 1 CSIRT Team Structure... 3 Figure 2 Organizational Hierarchy [Ref: CMU/SEI 2003 HB 002]... 4 Figure 3 CSIRT Services... 5 Figure 4 Relation of Framework Elements [Ref: CMU/SEI 2003 HB 002]... 6 Figure 5 Incident management... 7 Figure 6 Incident Handling Process Workflow... 9 Figure 7 Information Flow for CSIRT... 10 Figure 8 Incident Handling Process... 11 Figure 9 Overview incident magnet systems... 12 Figure 10 NUST CSIRT web page... 13 iii
1. What is CSIRT? CSIRT stands for Computer Security Incident Response Team. The term CSIRT is used predominantly in Europe for the protected term CERT, which is registered in the USA by the CERT Coordination Center (CERT/CC). There exist various abbreviations used for the same sort of teams: CERT or CERT/CC (Computer Emergency Response Team / Coordination Center) CSIRT (Computer Security Incident Response Team) IRT (Incident Response Team) CIRT (Computer Incident Response Team) SERT (Security Emergency Response Team) At the moment both terms (CERT and CSIRT) are used synonymously, with CSIRT being the more precise term. 2. Policy, Plan and Procedure Creation 2.1 Incidents and Events A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. A very common of example of an incident is an attacker commands a botnet (malicious code) to send high volumes of connection requests to a web server, causing it to crash. Any incident causing an observable occurrence in a system or network is generally addressed as an event. 2.2 Incident Response Policy, Plan and Procedure Organizations should have a formal, focused, and coordinated approach to responding to incidents, including an incident response plan that provides the roadmap for implementing the incident response capability. Policy: Policy governing incident response is highly individualized to the organization however they have mainly the same key elements in their policies. Some of these are as follows: Statement of management commitment Purpose and objectives of the policy Scope of the policy (to whom and what it applies and under what circumstances) Definition of computer security incidents and related terms Organizational structure and definition of roles, responsibilities, and levels of authority 1
Prioritization or severity ratings of incidents Reporting and contact forms Computer Security Incident response Team (CSIRT) Guide Plan Each organization needs a plan that meets its unique requirements, which relates to the organization s mission, size, structure, and functions. The plan should lay out the necessary resources and management support. The incident response plan should include the following elements: Mission Strategies and goals Senior management approval Organizational approach to incident response How the incident response team will communicate with the rest of the organization and with other organizations Roadmap for maturing the incident response capability Procedures Procedures should be based on the incident response policy and plan. Standard operating procedures (SOPs) are a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the priorities of the organization are reflected in response operations. In addition, following standardized responses should minimize errors, particularly those that might be caused by stressful incident handling situations. SOPs should be tested to validate their accuracy and usefulness, and then distributed to all team members. 3. CSIRT Framework In the search for a quick fix to establishing guidelines under which a new team will operate, many people go in search of existing CSIRT guidelines with the hope that they can simply be adopted for use in their environment. However, they soon realize that no single set of service definitions, policies, and procedures could be appropriate for any two CSIRTs. Moreover, teams with rigid guidelines in place find themselves struggling to adapt to the dynamic world of computer security incidents and attacks. To obtain that goal in a structured fashion, it is best to start with and to recognize a basic framework for a CSIRT. That framework consists of the questions what to do, for whom, in what local setting and in cooperation with whom. 3.1 Mission Statement An organization must define its mission statement in order to acquire basic understanding of what the team is trying to achieve; and more importantly, it will provide a focus for the overall 2
goals and objectives of the CSIRT. It should be non ambiguous and consist of at most three or four sentences specifying the mission with which the CSIRT is charged. A mission statement is the essence of CSIRT to establish a service and quality framework, precisely defining its goals, scope and the services. 3.2 Incident Response Team Structure An incident response team should be available for anyone who discovers or suspects that an incident involving the organization has occurred. One or more team members, depending on the magnitude of the incident and availability of personnel, will then handle the incident. Team Structure for CSIRT is as follows: Director Manager (Core Team) Manager (Tech Team) Incident Handlers Help Desk Website management Developers/ Solution providers Forensics Team Malware Team Pen testing Team Network Admin Figure 1 CSIRT Team Structure Incident handlers analyze the incident data, determine the impact of the incident, and act appropriately to limit the damage and restore normal services. They perform the coordination between all responsible departments for incident response. Help Desk is responsible to receive all the reported incidents to CSIRT from all means of communication made available to contact. The help desk then forwards the reported incident to the incident handlers after proper categorization and numbering of the incident reported. Website management is responsible for developing, updating and managing the CSIRT website that has been developed for required CSIRT services. Developers/ Solution Providers is a team of technical experts that develops independent patches to eradicate the cause of incident and complete recovery of the system or network. 3
Forensics, Malware, Pen test and Networking teams provide their services in their respective areas of technical expertise. 3.3 CSIRT in different hierarchies and their relations Different CSIRT(s) work in coordination and collaboration at organizational, national and international levels. The hierarchical level could have different scopes and responsibilities depending on the organization s size, structure and functions. Figure 2 Organizational Hierarchy [Ref: CMU/SEI 2003 HB 002] 4. CSIRT Services There are many services that a CSIRT can deliver, but so far no existing CSIRT provides all of them. So the selection of the appropriate set of services is a crucial decision. For a team to be considered a CSIRT, it must provide one or more of the incident handling services: incident analysis, incident response on site, incident response support, or incident response coordination. CSIRT services might be provided by the CSIRT alone or in cooperation with other organizational units (such as the IT or security department). These services are mainly categorized in three groups Reactive services, Proactive Services and Security Quality Management Services. 4
A CSIRT must take great care in choosing the services it will offer. The set of services provided will establish the resources, skill sets, and partnerships the team will need to function properly. NUST CSIRT services are talked about in section 6 of the document 4.1 Reactive Services Reactive services are designed to respond to requests for assistance, reports of incidents from the CSIRT constituency, and any threats or attacks against CSIRT systems. Some services may be initiated by third party notification or by viewing monitoring or intrusion detection system (IDS) logs and alerts. It is a response to the incident that has already occurred. 4.2 Proactive Services Proactive services are designed to improve the infrastructure and security processes of the constituency before any incident or event occurs or is detected. The main goals are to avoid incidents and to reduce their impact and scope when they do occur. 4.3 Security Quality Management Services These services are designed to improve the overall security of an organization. By leveraging the experiences gained in providing the reactive and proactive services described above, a CSIRT can bring unique perspectives to these quality management services that might not otherwise be available. These services incorporate feedback and lessons learned based on knowledge gained by responding to incidents, vulnerabilities, and attacks. The figure below lists these services: Figure 3 CSIRT Services 5
Governed by services, policies and quality procedures, the figure below shows that how elements are enacted. Figure 4 Relation of Framework Elements [Ref: CMU/SEI 2003 HB 002] 5. Incident Management Incident handling involves receiving, triaging and responding to requests and reports, and analyzing incidents and events. This section will describe the fundamental components of an incident handling service and incident management. Moreover, the procedures that needs to be in place to support them. Incident management is broadly categorized into four stages of preparation, detection analysis, containment eradication & recovery and Post incident activities. These stages are inter related and supportive to each other. The figure below shows the four categories and the relation between them: 6
Figure 5 Incident management 5.1 Incident Handling Phases Keeping these stages in mind, SysAdmin, Audit, Network and Security (SANS) defined standard 6 phases of incident handling. These phases are listed and briefly explained as under: 5.1.1 Preparation This phase as its name implies deals with the preparing a team to be ready to handle an incident at a moment s notice. There are several key elements to have implemented in this phase in order to help mitigate any potential problems that may hinder one s ability to handle an incident. These majorly includes definition of roles and responsibilities, complete organizational structure of CSIRT, defining service and quality frameworks, determining ways to report incident, making policies and response strategies, developing technical skills with training and certifications. 5.1.2 Identification This phase deals with the detection and determination of whether a deviation from normal operations within an organization is an incident, and its scope assuming that the deviation is indeed an incident. Other than determining the type and level (e.g. network/system/routers/firewalls) of the incident, identification phase also covers for the initial assessment of the incident. This is known as triage. Triage The goal of triage function is to ensure that all information destined for the incident handling service is channeled through a single focal point regardless of the method by which it arrives (e.g., by email, fax, telephone, or postal service) for appropriate redistribution and handling within the service. Different tools are used in CSIRTs to carry out the triage function. 7
The results reflect the impact and urgency of the incident for incident responders. Triage is also helpful in efficient use of tracking numbers for incident handling process. 5.1.3 Containment The primary purpose of this phase is to limit the damage and prevent any further damage from happening. It is the first course of action once the incident has been identified. One thing to understand here is that it is important to both limit the damage and keep the system in running state. An essential part of containment is decision making (e.g., shut down a system, disconnect it from a network, and disable certain functions). Such decisions are much easier to make if there are predetermined strategies and procedures for containing the incident. Organizations should define acceptable risks in dealing with incidents and develop strategies accordingly. Containment strategies also vary based on the type of incident. 5.1.4 Eradication Eradication is the phase that deals with the actual removal and restoration of affected systems. The cleanup can take many forms. In a simple situation it could just be running a virus or spyware scanner to remove the offending files & services and updating signatures. Or in a complex situation the system might need restoring from backup and then apply patches. Technical experts are required for eradication as the incident may require developing specific patches for completely removing the root cause. This phase is also the point where defenses should be improved after learning what caused the incident and ensure that the system cannot be compromised again (e.g. installing patches to fix vulnerabilities that were exploited by the attacker, etc) 5.1.5 Recovery The purpose of this phase is to bring affected systems in operational state carefully, as to insure that it will not lead another incident. It is essential to test, monitor, and validate the systems that are being put back into production to verify that they are not being reinfected by malware or compromised by some other means. 5.1.6 Lessons learned The purpose of this phase is to complete any documentation that was not done during the incident, as well as any additional documentation that may be beneficial in future incidents. It is a follow up on all that was done during the incident handling process. The overall goal is to learn from the incidents that occurred within an organization to improve the team s performance and provide reference materials in the event of a similar incident. The documentation can also be used as training materials for new team members. 8
5.2 Incident Handling Process Workflow Based on the 6 step approach to incident handling NUST CSIRT has developed its own process flow for incident handling. The figure below shows the flow of information from receiving an incident to responding back to the reporter with a solution. Figure 6 Incident Handling Process Workflow Multiple reporters from a defined scope report to the CSIRT by four means of communication. These ways to report an incident include fax/telephone, email, incident reporting forms and collaboration with international CERT(s). They are available on the NUST CSIRT website () Every reported incident is given a ticket (numbering system to manage incidents) After identification and triage by incident handlers, the ticket is then forwarded to the respective CSIRT s supporting technical teams as a verified incident. The technical experts of the CSIRT support teams come up with relevant fixes, patches or solutions to eradicate the possible cause of the incident. Support teams then send the complete solution and course of action back to the incident handlers at CSIRT coordination centers. Incident handlers at CISRT coordination center are responsible to send the solution, provided by technical teams, to respective customers/reporters. 9
5.3 Information Flow for CSIRT The incident handling service usually includes other activities that support the delivery of the service, consisting of the triage, handling, announcement, and feedback functions. These functions and their relationships are shown in the figure below (According to CMU): Figure 7 Information Flow for CSIRT In light of the incident handling phases, incident handling workflow flow designed and effective flow of information by SANS, a flowchart has been developed to present a clear step by step approach to any incident that may occur and its outcomes. The flowchart is given below: 10
Computer Security Incident response Team (CSIRT) Guide Figure 8 Incident Handling Process 11
5.4 Incident Management Systems Computer Security Incident response Team (CSIRT) Guide 5.4.1 Need for Incident Management Systems Incident management systems enable organizations to accurately collect monitors, analyze, and identify security threats to their environment within a single integrated solution. It s of utmost importance that the managers, investigators, analysts, engineers and operators are on the same page of knowledge of what is going on. These systems are able to connect logs to organizational regulations, policy, plan, procedures, organizational divisions, and even by individual project requirements. Alerts can be personalized to correlate between identified events, known threats, and critical assets. Reports can be automated and customized to fit any manner of output requirements rather than being limited hand made spreadsheets. 5.4.2 Functional Overview of Incident Management Systems Different technologies such as endpoint systems, network systems, data inventories, application infrastructures etc. act as data sources for varied scenarios. The data is then collected and summarized to be analyzed in detail. In the data correlation layer malicious summarized data is compared to the authentic unaffected data to find out the possible cause of the incident. This data is fed to Incident handling process. The figure given below shows an overview of CSIRT inputs, its layers of process and incident management. Figure 9 Overview incident magnet systems 12
6. NUST CSIRT 6.1 Mission Statement NUST CSIRT is a National; Government sponsored Computer Security Incident Response Team. It addresses the Nations security & cyber fronts of Pakistan to achieve technological excellence. NUST CSIRT is committed to secure use of technology through standards, best practices, and risk & threat mitigation being at the front end to disseminate the information. 6.2 NUST CSIRT Website A website has been developed as an interface for NUST CSIRT () to provide its reactive & proactive services. Figure 10 NUST CSIRT web page 6.3 NUST CSIRT Services Services provided on the NUST CSIRT website are as follows: Incident Handling (Means of reporting incident) Information Dissemination: Alerts and warnings Vulnerability/ Security updates 13
Latest News on cybercrimes Technical documents to enhance knowledge base Computer Security Incident response Team (CSIRT) Guide Recommended tools for supporting incident handling and management Newsletters CVE database 6.4 Incident Reporting methods Following incident reporting methods are available on the website in the helpdesk section: Incident report form Contact via Telephone Contact via Fax Email Incidents can be reported to NUST CSIRT through these input methods. 6.5 Staying connected with NUST CSIRT Keep yourself updated about latest news, threat alerts, warnings and security updates by subscribing to NSUT CSIRT via Email and SMS subscription. Moreover, NSUT CSIRT is connected to the world over social media as well. Follow us on: Facebook: NUST CSIRT (https://www.facebook.com/pages/nust CSIRT/1425321457712540 ) Twitter: @csirtnust (https://twitter.com/csirtnust ) 14
References: An Incident Handling Process for Small and Medium Businesses: SANS Institute 20017 National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide Special Publication [Revision 2] ENISA: A Step By Step Approach on How to Set Up a Csirt CMU Handbook for Computer Security Incident Response Teams (CSIRTs) [CMU/SEI 2003 HB 002] SANS Incident Handler's Handbook Building Global CSIRT Capabilities Southeast Europe Conference SANS Reading Room http://www.sans.org/reading room ENISA Publications http://www.enisa.europa.eu/publications#c2=publicationdate&reversed=on&c5=all&c0=10&b_start=0 NIST Standard Reference Materials http://www.nist.gov/srm/ 15