CIRT - Framework and Models

{LANG_NAVORIGIN} Incident Handling Incident Response Team
Ajoy Kumar 01/31/2005



Definition of CIRT: “An organization or team that provides services and support to a defined constituency for preventing, handling, and responding to computer security incidents.” [12]

CIRT is a carefully selected and well-trained group of people whose purpose is to promptly and correctly handle an incident so that it can be quickly contained, investigated, and recovered from. It is usually comprised of members from within the company. They must be people that can drop what they’re doing (or redelegate their duties) and have the authority to make decisions and take actions [11].


Need of CIRT

In 1988 “internet worm” incidence happened and that caused a failure to a large number of systems. In response to that incidence and improve the security of computers CERT ® (Computer Emergency Response Team) [2] Coordination Center came into existence. (CERT or CERT/CC is copyrighted and organizations/communities use CIRT instead of CERT). Since 1988 the internet hosts have risen to a number of over 172 million hosts as advertised on Domain Name Service. Clearly a single CIRT (CSIRT – S for Security) is not enough for such a huge community; this has lead to formation of many CIRTs. CIRT are like fire department they are involved in putting out security fires. CIRT have role reactive as well as proactive situations. Policies, procedures and services of CIRT are to be determined based on role that is charted out for CIRT. Like Fire departments they may need to coordinate with other CIRT for responding to emergencies and may need help from other CIRT (including legal help).

Legal Requirement of CIRT:

US Government mandates following legislature on Incident Response team:

1. Sarbanes- Oxley Act of 2002: It indicates of severe liability for destruction of electronic records – up to $25 million fines and 20 years of prison terms. Important due diligence for internal controls.
2. ISO 17799: Outlines comprehensive Incident Response and Internal Investigation procedures. It also explains detailed provision on computer Evidence Preservation and Handling.
3. Some states have elaborate laws on Incidence handling. For example California, SB 1386/ Civil Code 1798.82 describe in details following:
   • Mandates full disclosure to Residents of any compromised data
   • Law triggered upon a computer security incidence.
   • Identifying and documenting event determines compliance
   • Delayed disclosure could draw investigations
4. OMB A-130 circular,1996

Vulnerabilities reported

1995-1999

Year	1995	1996	1997	1998	1999
Vulnerabilities	171	345	311	262	417

2000-2004

Year	2000	2001	2002	2003	1Q-3Q 2004
Vulnerabilities	1,090	2,437	4,129	3,784	2,683

Total vulnerabilities reported (1995-3Q 2004): 15,629

National Cyber Alert System documents published (published on www.us-cert.gov)

2004

Year	1Q-3Q 2004
Technical Cyber Security Alerts	22
Cyber Security Alerts	14
Cyber Security Tips	18
Cyber Security Bulletins	21
Totals	75

Total National Cyber Alert System documents published (1Q-3Q 2004): 75

Security alerts published

Note: Information previously published in CERT advisories, incident notes, and summaries is now incorporated into National Cyber Alert System documents.

1988-1989

Year	1988	1989
Advisories	1	7
Totals	1	7

1990-1999

Year	1990	1991	1992	1993	1994	1995	1996	1997	1998	1999
Advisories	12	23	21	19	15	18	27	28	13	17
Incident Notes									7	8
Vendor Bulletins					2	10	20	16	13
Summaries						3	6	6	8	5
Totals	12	23	21	19	17	31	53	50	41	30

2000-2004

Year	2000	2001	2002	2003	1Q 2004
Advisories	22	37	37	28	2
Incident Notes	10	15	6	4	2
Summaries	4	4	4	4
Totals	36	56	47	36	4

Total security alerts published (1988-1Q 2004): 484

Incidents reported

Since the attacks have become so common place that counts provide little information in assessing the scope of impact of attacks. As of 2004 CERT has stopped publishing number of incidences.

1988-1989

Year	1988	1989
Incidents	6	132

1990-1999

Year	1990	1991	1992	1993	1994	1995	1996	1997	1998	1999
Incidents	252	406	773	1,334	2,340	2,412	2,573	2,134	3,734	9,859

2000-2003

Year	2000	2001	2002	2003
Incidents	21,756	52,658	82,094	137,529

Total incidents reported (1988-2003): 319,992

All Statistics information is taken from [15]. This highlights needs for organizations to have dedicated CIRT. A CIRT may provide a wide range of services in addition to incidence handling; it may offer IDS or vulnerability handling. It is important to have established a frame work for CIRT. CIRT mission, constituency, roots and peers should be defined. Here are some benefits of having a CIRT:

1. Helps companies to recover quickly from security incidents in efficient manner thereby minimizing loss of information and services.
2. Respond to incidents in a systematic manner.
3. Use incident experience to further strengthen CIRT capability and share with coordinating CIRT.
4. Deal adequately with legal issues.

Purpose of this Paper

In this paper I will be discussing significance of CIRT, high level framework of CIRT and describe two standards for forming a CIRT. Comparing two standards could be a topic for a PhD research.


Framework of CIRT

It is essential to understand structure and needs of an organization in which CIRT operates. Frame work for a typical CIRT is based on simple questions ‘what to we do’, ‘who needs it’, ‘what are local needs’ and ‘how to cooperate’ etc. This leads to following frame work [2]:

Mission Statement: High level goals, objectives and priorities.

Constituency: Constituency type and relationship with constituency.

Place in Organization: Position within organizational structure and particularly within risk management.

Relationship to others: Setting of (inter)national CIRT cooperation and coordination and other interactions.

Mission Statement: Mission statement should provide a basic understanding of what the team is trying to achieve and focus on clear goal and objectives of CIRT. In lack of clear understanding of their goals and objective or failure to communicate effectively to constituents could lead to a crisis situation. Mission statement helps establish service, quality framework, nature and range of services. CIRT also publish purpose statement to explain why the team is being established.

Constituency: Operationally CIRT interacts with a wide range of entities but there is a specific community CIRT was set up to serve: a constituency. A CIRT constituency can be unbound or it could be bound. Typically organizational CIRT are bound. Based onconstituency mission statement of each CIRT varies. For example and International Coordination Center would have a role of serving other CIRT around the world. Its mission will be to build trust amongst other CIRT. A technical CIRT on other hand may serve users of products and may be unbound in nature. Some CIRT service overlapping constituencies and such situations of overlapping constituency lead to some confusions unless all constituents clearly are aware of role and responsibility of CIRT. A relationship with a constituency could be Full, Shared or None. A CIRT could have full authority over constituency in case of an incidence and it may undertake all actions and decisions for constituency. Incase of shared responsibility it’s role may be to advice and influence till an action is taken.

A clear relationship between CIRT and constituency is key for successful handling of incidences. Trust must be nurtured and earned. CIRT should promote itself widely in a given constituency.

Place in Organization: A place CIRT holds in an organization is mentioned in mission statement. CIRT could be part of Security Team of company but due to specialized functions it is kept as separate team with some overlap with Security team. It could be even a set of individuals taking on the responsibility as situation demands (typical for smaller companies). It is possible to have multiple incidence handling capabilities in an organization for example one team may focus on internal outage of networks and another with outside vendor. Different teams may deal with virus outages than a team that deals with network attacks or intrusions. Regardless of specific role a team plays in the organization; role of risk management must be clear to each group. Clear description of group’s duties, escalation procedures and shared responsibilities is key to success of a team and CIRT.

Relationship to other Teams: Since there are many CIRT in international scenario and they are growing in number with a lot of common objectives. Cooperation and interaction at some level is very important. Based on complexity of organization it is possible to have hierarch of CIRT. For example Coast guard, Police Services and other departments of US government could have individual CIRT for their constituents and Department of Homeland Security’s CIRT would be a coordinating CIRT for most of agencies. Importance of Computer Security is raised to a very high level with recent passing of Intelligence Law (2004). CIRT could have different types of working relationship with other CIRT. As explained by a picture from [10].


Picture on relationship of team from [10]


Services of CIRT

CIRT must provide one more services of incidence handling. These services could be all or any of these: incidence analysis, incidence response on site, incidence support, coordination etc. CIRT services can be categorized in three broad categories:

1. Reactive Service: Services that are triggered by a sudden occurrence or an event. For example malicious code attack, virus attack or serious vulnerability. This is core component of a CIRT. These services extend to send alerts, managing and doing forensics on an event. Vulnerability handling and artifact handling are also covered under this service.
2. Proactive Service: Services that are provided to help prepare, protect and secure constituents systems from attacks or events. For example reviewing information of coordinating CIRT and then adapting for local scenario for protection of assets. CIRT are involved in services like Technology watch, Announcements, Audits, development of security tools, verification and maintenance of configurations of applications and infrastructure.
3. Security quality management service: Services that are provided to enhance services provided by other departments. These are for enhancing overall security of organization by identifying risk, threats and system weaknesses. These tend to be proactive but contribute greatly to reduce number of incidences. For example conducting a Security Fair in an organization with HR or training department for increasing overall awareness in an organization.

List of Common Services CIRT (reference [10])


Operational Framework of CIRT

Services of CIRT should be clearly identified (mission statement) and defined. Each definition should be clearly understood and available to CIRT and constituents. Objectives should be clearly defined for development of right polices and procedures. Each CIRT could have different objectives. For example: International Coordination CIRT could have objective of coordination, documentation, issuing alerts to world wide community, while a National CIRT would focus on supplying a response to an incident in a particular language and a time zone. It would also act as coordinating party with law enforcement, while an Organization CIRT would be involved in dealing with incidences effecting internal assets of a company. It may be coordinating in passing information to other CIRT but prime focus will on organization itself.

Traditionally terms “incidence response” and “incidence handling” are used to define CIRT but these words do not completely define CIRT; it includes all process or (and) tasks associated with handling incidents and events. Frame work for CIRT is evolving and currently there are two industry wide accepted practices:

• CERT/CC Model
  
  
• NIST/SANS Model and

Classification of high level steps in each approach is different but in real life there would be a similarity on operations. These two approaches are similar in terms of natural flow to incidence response. High level steps of both approaches are categorized differently and may make a difference in amount of information available at each step and how it is used.

CERT/CC Model:
Incidence management process is based on set of processes and strategies that are for incidence handling and protection of occurrences (and reoccurrences) of incidences. These processes are based on following requirements:

1. Plan and implement Security Incidence handling capability
2. Secure and harden enterprise infrastructure for prevention
3. Detect, triage and respond
4. Prepare/Sustain/Improve which includes sub-processes of planning, sustaining, doing post mortems and improve

Organizations need to have strategies, processes in place for handling incidences and preventing them. These processes can be classified in following four categories:

1. Protect
2. Detect
3. Triage
4. Respond

CERT Model [10]

Protect: Protect process is for protection of assets. It consists of following sub processes:

• Implement changes to computer (very broad terms) infrastructure to stop or mitigate an event that is occurring at given moment.
• Mitigate or stop potential exploitation of vulnerability in hardware or software or infrastructure.
• Implement improvements in infrastructure protection resulting from post mortem review.
• Process improvement mechanism by evaluating processes, monitoring or protective scanning.
• Communicate all information to ‘Detect’ process about ongoing event(s) and other discovered vulnerabilities.

Detect: This is ability to receive and review event/incident information, incident reports and alerts. Detect process includes following sub processes:

• Notice events and reports (Could be feed from IDS)
• Receive reports on all events.
• Proactively monitor events (IDS/IPS); get and feeds from all monitors (e.g.: MOM).
• Analyze, define and refine incidences being monitored that could identify any threats, malicious activity, compromise to access etc. This is done for enterprise wide activities (infrastructure, applications and other elements included).
• Re-assign (and close) events not belonging to CIRT. Some time help desk departments pass on complaints to CIRT department and that may not be competence area of CIRT.
• Forward notable/suspicious events to Triage Process.

Triage: The actions taken to categorize, prioritize, and assign incidents and events. It includes following sub processes:

• Categorize events.
• Correlate various events. Personnel involved in such teams typically also belong to Forensic teams.
• Prioritize events.
• Assign events for handling and response.
• Communicate information to ‘Respond’ process for further handling.
• Re-assign (and close) events not belonging to CIRT.

Respond: The actions taken to mitigate an incident, coordinate and disseminate information, and implement follow-up strategies to prevent the incident from happening again. This includes process of planning, coordination and execution of appropriate mitigation and recovery actions using planned strategies. It include following processes:

• Analyze the event, this analysis is meant for response and detailed for mitigation.
• Plan a response strategy for incident.
• Coordinate and provide technical management of incidence. Actions of this team are for recovering, resolving, mitigating and containing incidences. This involves seeking advice of legal team, operation team and higher level management.
• Communication with media and external parties is handled by this process (and members).

Some actions may give impression of repeatability in high level processes but they are very different as the incidence is in different stage of handling.

It is noted here, an incident is deemed as ‘incident’ only if it is reached to respond process and prior to that it is called an ‘event’. There is an effort undertaken by Sandia National Laboratories for US government for developing a common language of CIRT [7]. This effort is meant to clear out all such ambiguities as till recent times professionals get inter mixed with this nomenclature.

NIST/SANS Model:
NIST standards are adapted in different departments of US government. For example FCC uses these standards (to be described) in conjunction with OMB A-130 which narrates a requirement “to share information concerning common vulnerabilities and threats” (OMB A-130 circular,1996). Among other requirements for safe guarding computer assets there is a requirement to effectively deal with incident (should it occur). Following are six important processes (steps) for this approach:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery
6. Follow up

NIST Model [6]

Preparation: “The FCC considers being prepared to respond before an incident occurs to be one of the most critical facets of incident handling.” [9]. Advance preparedness helps avoid confusion. Here are salient points:

• Base line Protection: This is considered as first line of defense from happening of incidences and to contain spreading of events from system to system.
• Team in this area is involved with keeping up to date on vulnerabilities, defenses and compliance.
• IDS and IPS are implemented and monitored.
• Planning for containment and response including personnel involved is handled by this team.
• Training and mock incidents are conducted.

Identification: This step has four important sub steps [9]:

Validating the incident: This involves complex symptom analysis of an incidence. This is one of the most difficult steps as this could involve an effort to verify anything (configurations, IDS, IPS, Unsuccessful logging attempt, unexplained new files, system crashes, poor system performance etc.).

Identifying nature of Incident: Although no single symptom may be able to show if incident is ongoing, observing and correlating these symptoms is covered in this sub step. Just to highlight: “More and more exploits are utilizing multiple techniques to spread, such as the use of malicious codes along with the ability to exploit vulnerabilities in software,” notes Dr. Ed Amoroso, chief information security officer for AT&T and Professor at Stevens Institute, NJ. “These blended threats can then cause widespread damage to a large number of networks and users in a very short time.”

Identifying and protecting the evidence: Identify and Protect incidence (if possible on ongoing stage as it may be causing some strange activities) with dates, signs, numbers and securing them for turning over to next step and using for future use. Integrity of this information must be checked and proven. Backups should be preserved.

Logging and reporting the incident. Reporting should be done to CSO and owner (custodian) of system must be contacted. In FCC implementation CSO has responsibility of communicating it to senior management. FCC implementation has a strict policy of not discussing event out side FCC except for designated spokesperson (and/or FBI if involved). Detailed logging is maintained of all steps for correlation and future response planning. Containment: This process has key objective to contain scope and magnitude of an incidence as ASAP. Quick decisions are made at this step, which involve following analysis: criticality of asset, use by owner, scope of spreading to other systems, operational status of system. Incase of multiple incidences prioritization is done at this step. In FCC implementation of this model it is noted “Maintain a Low Profile” incase of incidence in progress as this may tip off intruder. This can be categorized a case of Security through Obscurity in an off beat way. It can also be used to set Honey Pots for intruders.

Protection of backup systems is very important and large emphasis is on avoiding compromised code, hardware, site etc. Backups at this time may be used to bring up ‘hot’ or ‘warm’ site based on spread of impact. Passwords may be changed at this time and even measures are taken for limiting access to critical systems/personnel.

Eradication: After containment this is next priority. For example after a virus attack, an organization must ensure that it is properly removed from all media (floppies, HDDs, tapes etc.) Backups are re-done as if recovery was to be done for another incidence or a DR situation virus (or incident) should not start re spreading. Improvement of defense mechanisms is done at this step, new patches, new filters, further hardening strategies evolve at this step.

Recovery: Normal system operations should have been restored to ensure that mission statement of organization is possible. This step is usually coupled with validation and monitoring of system for period of time. ‘Back doors’ are more thoroughly scanned as production usage of system may expose more vulnerabilities than analyzed earlier (and even inputs of owner and custodian may not be sufficient). Further course of actions if further analyzed.

Follow-up: This step is typically for making sure that next incident(s) is better handled and there is learning from this experience. Documentation is analyzed and updated (for missing items if possible). Cost of incidence is determined (this is little difficult – discussed later in paper). A report is prepared and staff awareness is created. Depending on nature of organization and sensitivity of incident information could be shared with coordinating CIRT at any of the steps. This step sometimes is a precursor to revisions in policy and procedures.


Incidence Response Team Structure

An incidence response team should be available for contact for anyone who suspects or discovers of an event. Depending on complexity and magnitude of event one or more persons gets involved to handle the incidence. Incident handlers are trained to analyze incident data, do impact analysis and act appropriately to limit the damage to organization and finally restoration of normalacy. During ‘normal’ times team is involved in vulnerability management, planning, coordinating and other activities. There are three typical models followed for CIRT teams.

1. Central Response Team: A single team handles incidences through out the organization. Typical to small organizations or large organization localized to a small geographical area.
2. Distributed Incident Response Team: Multiple incident response teams, each responsible for handling incidents for a particular logical/physical domain of a company. Peculiar to large or geographically diverse organizations, for example there may be one team per division or one team per geographical area etc. Strong central team for coordinating, maintaining standards and to avoid duplication of work is important. Following of process or working through CMMI model helps in maintaining common practices and processes.
3. Coordinating Team: This team provides advice and guidance to other teams without having any authority over teams. These teams are like CIRT for a CIRT. They are typical to very large organizations. For example one team in DHS (Department of Homeland Security) CIRT team plays a strong role of acting as Coordinating team for all agencies should an incident occur.

These team could by staffed by full time employees, part time employees or could be partially or fully outsourced (Managed Security).


Cost Model

Cost can become an issue for some smaller organizations; as they may not be capable of managing Full or Part time staff for such a dedicated effort. Some short term loss of daily productivity is seen but a long term picture is much better. Estimating cost of Incidence is a tedious process but some initiatives taken in this direction seem to present reasonable model for estimates. Incident Cost Analysis Modeling Project (I-CAMP- II) is one of leading models for cost analysis.


Risk/Benefit Analysis

1. CIRT becomes a brain for coordinating and managing any Security incidents.
2. CIRT is dedicated to identify and follow up on vulnerabilities; which gives organizations a clear respite that someone is constantly on top of security issues.
3. CIRT coordinates with other CIRTs, CERT/CC and FIRST and if there is any known vulnerability that is discovered they work in tandem with main vendors to close the exploit and (or) work on strategies to mitigate risk.
4. CIRT follows-up and maintains knowledge base of incidences.
5. CIRT is knowledgeable in fields of Law and Ethics and works with Legal team for all practical purposes.
6. “Once resolved, an incident can offer an invaluable educational experience for the FCC CIRT. Such efforts may prevent (or at least minimize) damage from future incidents” [14]. Knowledge about the types of threats that are occurring and the presence of vulnerabilities can aid in identifying security solutions. This information will also prove useful in creating a more effective training and awareness program, and thus help reduce the potential for exposure.
7. Based on research it occurs that some companies are really finding great benefits of using CIRT. For example FCC has adapted to NIST model to the strictest possible way. FCC actually instituted mission statement, procedures, policies and support team around this model as based on research this provides fairly extensive methods and structured polices for incidence response.
8. Since it is difficult to access the cost of incidence (for example multiple numbers have been issued for fighting Melissa virus) there is not much publications on cost models of an incidence and this may be a topic for PhD thesis.
9. Also, very few documents indicate that which company picked up a model and why. FCC does indicate using NIST model but does not indicate there reasons of choosing NIST over CERT model.
10. It is accessed that since CIRT offers such a structured and natural approach for life of incidence handling it is just implemented as de facto standard from one of 2 models available. It is clearly evident that if any organization is not choosing to implement CIRT it could be problem some as incident typically gets unmanaged or over managed and it may not be followed through for preventing future occurrences.
11. It is also evident from the available statistics that number of incidents is growing and there is need of people of specialized skills and tools to handle and it is evolving into speciality. In fact research indicates that Computer Forensics could be sub categorized as a sub branch of CIRT and is gaining popularity as a carrier path and is being offered in trainings.
12. “Organizing people to respond to computer security incidents is worth the effort not only when you actually have an incident but also because the analysis and interactions leading to establishment of the CIRT bring benefits even without an emergency.” [16].
13. “CIRT is making hacking hard.” [17]. University of New Mexico is very happy from services of CIRT and CIRT has helped device a Secure Shell program, that allows secure access between a desktop computer and a remote server. The program encrypts the clear text password and sends the encrypted version over the network to be verified by the server the person is trying to contact. Such programs help build reputation of CIRT and bring enormous benefits.
14. CIRT’s criticality of services is enormous. Searchsecurity.com says [18] “When it comes to security, one can see how an enterprise is like the human body. Measures are taken to avoid injury, but if a wound occurs, there are mechanisms in place to minimize the damage. For example, the body has white blood cells to attack invading bacteria. Companies need computer incident response teams (CIRTs) to fend off invading viruses and worms.”

To sum up, CIRT is a necessity as for an organization and research suggests enormous benefits that are brought by CIRT. It adds cost to overall functioning of an organization but these costs would be dwarf to overall benefits added to smooth functioning of an organization.


References

1. Security Warrior, by Cyrus Peikari & Anton Chuvakin. O’Reilly, 2004.
2. SANS (http://www.sans.org), Dec 2004
3. CERT (http://www.cert.org), Oct 2004
4. FIRST (http://www.first.org), Nov 2004
5. Washington School: http://staff.washington.edu/dittrich/misc/faqs/incide ntcosts.faq, 29 Jan, 2001
6. Computer Security Incident Handling Guide Recommendations of the National Institute of Standards and Technology by Tim Grance, Karen Kent, Brian Kim Special Publication 800-61, January 2004.
7. A common language for Computer Security Incidences John D Howard, Thomas A Longstaff. I do not have details on date of this paper. I thankfully acknowledge this effort by Tom Longstaff and John Howard.
8. Network Security: Managing the Risk and Opportunity An AT&T Survey and White Paper in Co-operation with the Economist Intelligence Unit, http://www.business.att.com/content/whitepaper/network_security-managing_the_risk_and_opportunity.pdf, 13-Jul-2004
9. FCC Computer Security Incidence Response Guide, http://csrc.nist.gov/fasp/FASPDocs/in cident-response/Incident-Response-Guide.pdf, December 2001
10. Handbook for Computer Security Incident Response Teams (CSIRTs) by Moira J., West-Brown, Don Stikvoort, Klaus-Peter Kossakowski, Georgia Killcrece, Robin Ruefle, Mark Zajicek 2nd Edition: April 2003 http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03 hb002.pdf
11. Computer Incident Response Team GIAC Certification Version 1.2F by Michelle Borodkin www.sans.org 2001.
12. Organizational Models for Computer Security Incident Response Teams (CSIRTs) by Georgia Killcrece, Klaus-Peter Kossakowski, Robin Ruefle, Mark Zajicek, December 2003.
13. The National Strategy To Secure Cyberspace, www.whitehouse.gov, forwarded by President G.W. Bush, February2003
14. CIRT, http://www.iwar.org.uk/comsec/resources/fasp/CIRT -Desk-Reference.pdf, Jul 2002
15. http://www.cert.org/stats/ CERT/CC Statistics 1988-2004
16. CIRT management: Introduction http://www.nwfusion.com/newsletters/sec/2004/0308sec2.html, Sep 2004
17. CIRT is making Security Hard: http://www.dailylobo.com/news/2003/01/22/News/Cirt-Is.Making.Hacking.Hard-349023.shtml, 13-Dec-2004
18. CIRTs must be a certainty, by By Edward Hurley, 10-nov-2003, http://searchsecurity.techtarget .com/originalContent/0,289142,sid14_gci935950,00.html

E-Mail Link

Your IP address will be sent with this e-mail

From e-mail to e-mail