What is the primary purpose of the Forum of incident response and Security Teams (FIRST)

Security Incident Response is a dynamic, varied, and ever-changing field. This ability to respond to and compensate for the multiple sources of potential security incidents is vitally important to any organization. From the smallest to the largest organization, Security Incident Response is valuable, necessary and in many case, the highest priority for safety and security of all people involved. Proper security incident response requires dedication to proper procedures and attention to great detail which often yields great satisfaction. Forensics is a growing, ever-expanding subfield of Security Incident Response with demanding precise requirements for investigators, examiners, and analysts.

Agency CSIRC

Each agency CSIRC will have unique responsibilities. You should list high-level bullets of the expected responsibilities of your agency CSIRC in your C&A Incident Response Plan. Typical CSIRC responsibilities are as follows:

Develop and maintain the agency computer security incident response capability policy and procedures

Maintain an incident response capability to ensure timely reporting of security incidents

Provide implementation guidance for processes and procedures

Establish procedures to ensure timely reporting of security incidents

Report significant computer security incidents to US-CERT as soon as possible but no more than one hour after detection with a follow-up report every four hours thereafter until the incident is resolved

Report minor incidents in a monthly incident report to agency CIO

Report all planned penetration testing and vulnerability assessments to the CIO

Write lessons learned and follow-up reports on agency computer security incidents

Implement tools and processes supporting the agency computer security incident response capability and procedures to collect and safeguard evidence for use in legal or administrative functions

Distribute advisories and vulnerability bulletins received from the CSIRC to appropriate agency CSIRC personnel and designated points of contact (POC) at their respective sites

Agency CSIRC

Each agency CSIRC will have unique responsibilities. You should list high-level bullets of the expected responsibilities of your agency CSIRC in your Incident Response Plan. Typical CSIRC responsibilities are as follows:

Develop and maintain the agency computer security incident response capability policy and procedures

Maintain an incident response capability to ensure timely reporting of security incidents

Coordinate the remediation of incidents agency wide

Provide implementation guidance for processes and procedures

Establish procedures to ensure timely reporting of security incidents

Analysis of net flow data during incident investigations

Report significant computer security incidents to US-CERT as soon as possible but no more than 1 hour after detection with a follow-up report every 4 hours thereafter until the incident is resolved

Obtain assistance from external sources, or US-CERT, if necessary

Report minor incidents in a monthly incident report to the agency CIO and CISO

Report all planned penetration testing and vulnerability assessments to the CISO

Write lessons learned and follow-up reports on agency computer security incidents

Implement tools and processes supporting the agency computer security incident response capability and procedures to collect and safeguard evidence for use in legal or administrative functions

Distribute advisories and vulnerability bulletins received from the CSIRC to appropriate agency CSIRC personnel and designated points of contact at their respective sites.

US-CERT monitors net flow data for all U.S. federal agencies and coordinates incident response across the government. CSIRCS and ISSOs should not hesitate to call upon US-CERT for assistance. It is better to ask for assistance, and close a security incident quickly, than to try to resolve an incident without assistance, and allow an intruder to remain on your network for a long period of time. The US-CERT Web site can be found at the following URL: http://www.us-cert.gov.

The Security Incident Response Team should always follow a structured documented process, wherein the content of the items to be investigated need to be preserved, validated, and documented. Any investigation must be understood at the onset as to its dimensions, scope, and investigative methods which are best based upon proven techniques, such as proper and legal collection of evidence and obtaining proper bit-stream “hash encrypted” copies of evidence. The linear nature of investigation always needs documentation and supporting evidence, for technology can give unexpected results. So, always document everything and report everything.

CERTs and CSIRTs

The primary purpose of CERTs and CSIRTs is to coordinate and disseminate cyber security information within an entity. That entity could be a company, agency, a group of companies/agencies, a state, country or the world. CERTs are generally looking for broad security events that impact large swathes of their users. Sometimes the users are security teams in an organization and sometimes the users are the end users. CERTs generally serve as a clearinghouse and usually function almost like a funnel. They take in a great deal of information, coordinate that information, and release the results in a manageable format that is easily digestible by the widest possible audience.

CERTs do not serve as incident response team (usually); instead, they work with incident results teams to coordinate their findings with other security vendors and other incident response teams to deliver an alert. The CERT is supposed to see the big picture: similar attacks are happening at organizations A, B, and Q. The CERT can help determine if it is a coincidence or part of an ongoing campaign. Used correctly and with a willingness to share, a CERT can be a powerful tool that improves the security for everyone.

Corporate Needs to Support the Team Activities

Integration of the SIR&FT into the corporate security and risk management structure ensures the organization can respond to an event before it becomes a disaster to the corporation, the LOB, and the customers/clients of the organization. As part of this integration several areas need inclusion to the team action.

The security detection and monitoring activities of the organization need visibility to the team and its daily activities. This provides a mechanism for possible early response to an active exploit or other suspect act. This also provides the SIR&FT members with the corporate and IT metrics and monitoring results to evaluate for potential risks and current trends in the organizational events, actions, and traffic. This allows the Team Manager to project areas for training and testing events which would be relevant to the goals of the corporation.

Another area in which the corporate activities need to align with the SIR&FT actions is the testing and exercise events for the recovery and the evaluation of the various IT components and systems within the corporate infrastructure. Test and evaluation actions are usually scheduled on an annual basis for most industry verticals, with additional exercises usually scheduled quarterly within the Disaster Recovery area. When these events are planned, designed and tested, the SIR&FT members should participate as Subject Matter Experts (SMEs) or as active responders to ensure close cooperation with the organization’s IT and Business key personnel and staff. This provides additional information for the SIR&FT to adjust and modify the Response and Forensics policies and procedures so they align with the actual LOB and IT response policies and procedures to minimize the business disruption during a real event response. This testing effort also provides valuable interchange and lessons for the Team members on how and why the various LOB operate the way they do within the context of business objectives and critical system recovery actions.

These testing events are also a prime area for training for the team members to practice their evidence capture techniques, the evaluation of tools and their use in the field, and adjustment to procedures for investigation. Practice of evidence collection procedures and techniques in order to identify the vulnerabilities in procedures is just one goal of these kinds of efforts. Another advantage is the development of analytic skills of the team members to adjust their on-scene actions and efforts to properly read, evaluate and respond to various types of incidents and investigations. The lessons learned from these activities provide great insight into the actual knowledge, skills, and abilities of the team members and also provide a great learning experience for all team members and the supporting staff of the organization, without jeopardizing real data or production efforts.

This process also provides ability of the SIR&FT Manager to identify the required reporting needs of the various divisions and to know who should and who should not be notified during real response event. Each of these criteria can become important during a breach response event or during an insider forensics investigation so the correct parties are kept informed and other personnel are not inadvertently told information they should not have access to or knowledge of through this method.

The corporate standards for documentation, policy, and procedure development all need to be available to the SIR&FT Manager as he defines requirements for designs and produces these documents for inclusion within the corporate documentation system. Each form, policy, and procedure needs to meet the corporate criteria for content, format, and approval in order it is within the needs, requirements, and allowed usage by the team members as they respond to each event, investigation, and incident. Included in these criteria are the Incident Response and the Forensics specific needs for each document such as the Evidence Capture and Chain of Custody Log forms which could have applicability external to the organization.

The primary methods of communications within the organization for the Team Manager must be predefined before an event or incident to make sure all appropriate management and key personnel are aware of the status and progress of each activity or investigation. There will be many times when it is not appropriate to inform certain LOB managers of the surrounding event concerning an active investigation, whether it is because an insider may have perpetrated it or because the control of the results is paramount. So the predefined lines of communications become necessary and important from a senior management level. The Team Manager must be sensitive to the political and economic issues around these actions, therefore, the needed communication are kept to a minimum as the event unfolds.

CSIRTs

This subsection provides a skeleton of the process of building a CSIRT, to introduce the whole concept at a high level. Some extra details are fleshed out in particularly important areas.

One of the first CSIRTs was formed when the CERT program was formed at the Software Engineering Institute at Carnegie Mellon University. The CERT program was initiated in 1988, as part of the response to the first major Internet outage due to malicious software: the Morris Worm [29]. The program since has become a repository for the lessons learned in building and operating CSIRTs, and has helped establish and coordinate many influential CSIRTs, such as US-CERT, the CSIRT and coordination point for the United States federal civilian government [30]. The other primary resource for information on response teams is the Forum of Incident Response and Security Teams (FIRST), founded in 1990 [31]. Both of these resources can provide guidance to organizations establishing CSIRTs.

CERT recommendations identify 19 action items for an organization establishing a CSIRT. It is worth quoting this list in its entirety to present a sense of the diversity of tasks required. The action items, with more details and further resources for more detailed reading, are available from the Software Engineering Institute [32].

Identify stakeholders and participants.

Obtain management support and sponsorship.

Develop a CSIRT project plan.

Gather information [from all stakeholders on policies, compliance, history, etc.].

Identify the CSIRT constituency.

Define the CSIRT mission.

Secure funding for CSIRT operations.

Decide on the range and level of services the CSIRT will offer.

Determine the CSIRT reporting structure, authority, and organizational model.

Identify required resources such as staff, equipment, and infrastructure.

Define interactions and interfaces.

Define roles, responsibilities, and the corresponding authority.

Document the workflow.

Develop policies and corresponding procedures.

Create an implementation plan and solicit feedback.

Announce the CSIRT when it becomes operational.

Define methods for evaluating the performance of the CSIRT.

Have a backup plan for every element of the CSIRT.

Be flexible.

This is neither a short nor easy process. However, the road has been traveled many times before. As long as the organization creating the incident response capability can leverage the existing lessons and documentation from past CSIRT creation, it should be able to proceed successfully.

The end result is a CSIRT—a person or persons who will be tasked with responding to computer security incidents within the organization. Although these are technically capable staff, they are not merely IT staff. Incident response requires not just special technical skill but also breadth to understand how systems interact. Since no one can be proficient on every IT system, the CSIRT staff will potentially need access to documentation about all the systems in the organization. There is one more helpful ability for these staff members: detective skills, or the ability to think like an adversary. A common problem in staffing CSIRTs is that staff members are overspecialized and are not cross-trained in each other’s skills [32]. When this happens, if one key staff member leaves, the team is crippled.

The response team also has some material needs. It needs a secure place to store and investigate evidence, and the equipment to do so. The CSIRT needs a defined interface with constituents, whether it is a phone hotline, email address, physical desk, or otherwise.

At the heart of its function, the CSIRT is a service part of the organization—to provide incident response expertise. However, there are some tensions with this characterization, because one of the most useful outcomes of an incident is lessons on how to manage the systems better. However, advice or requirements on system changes is not what the “customers” of the CSIRT requested. Resolving this tension is key to success. If there is no structure for CSIRT recommendations to be implemented, and the culture does not provide support for this function, the CSIRT will be stuck chasing their tail, always resolving the same incidents over again as the underlying problems are not addressed.

Jurisdictional Issues

Another key element in the development of a Cloud Security Incident Response Framework is to determine which jurisdiction applies in the event of a security breach. The customer may be located in a different country to that of the provider, while the data center(s) upon which the cloud service operates could be located across one or many other jurisdictions.

Many countries have cybercrime laws that determine how a computer security breach should be handled. Some of these laws are applied depending on whether the victim, perpetrator, or crime has been committed within that specific jurisdiction. It is possible that a security breach occurring in the cloud could be subject to cybercrime laws from various jurisdictions. For example, the laws applicable to the jurisdiction of the end customer may apply, similarly the cloud service provider may be located in a separate jurisdiction and be subject to local laws there, and the jurisdiction(s) where the data centers physically storing the data may also apply. It is important to understand what obligations parties are under the various criminal laws and whether they are applicable (the privacy chapter, and recent legal ruling applied to Microsoft), and to who they are applicable to (e.g., the cloud service provider, the data center provider, or a combination of any of the above). How to comply with the requirements of these laws will play an important role in the development of the Cloud Incident Respond Framework.

In addition to cybercrime laws, there may also be breach notification laws in place within the various jurisdictions that impact on the cloud service. The provider or customer may have to comply with breach notification laws depending on the laws and regulations within their geographic location or even industry. It is important therefore that an agreement between customer and the cloud service provider exists to determine if any security breach may trigger a breach notification obligation. The customer needs to ensure they do not want to fall foul of any breach notification laws simply because the provider failed to notify a security breach.

Similarly, the cloud service provider may be obligated to disclose a security breach under the laws and regulations within its jurisdiction. The customer needs to ensure they are notified of any such obligations and the prior notice period given in order to be prepared for any inquiries from the media or public regarding the impact.

Knowing the obligations, and those of the cloud service provider, are in relation to cybercrime and breach notification laws is critical in ensuring the Cloud Security Incident Response Framework is best positioned to manage certain types of incidents. How an incident should be responded to and who is responsible for managing the incidents and coordinating disclosures will depend on the obligations under these laws.