Tip

Defining an incident response process when short staffed

Dealing with a data security breach is a difficult task for any enterprise. Cleaning up after a data security breach involves many time-consuming steps, including identifying what data was breached, reporting details from the incident and implementing the necessary controls to prevent future incidents. (This is just a short list of the necessary action items.) The fallout from such an event is daunting enough, but doing so with limited staff resources can seem like an impossible task. However, this doesn't have to be the case.

In this tip, we'll outline how to leverage non-security-specific staff members to put together a

    Requires Free Membership to View

computer security incident response team (CSIRT) that can carry out a data breach response plan.

Incident response process: First steps
The best way to ensure a data breach causes minimal damage is to make preparations in advance, and the first step is to assemble a computer security incident response team (CSIRT). Staff from several different areas of the organization should be involved: IT, legal, human resources and corporate management. Staff members involved in the incident response process need to be highly trusted since they will have access to potentially sensitive data, depending on the incident.

Any person involved in the data breach response team needs to understand that the details of their involvement must remain confidential and they must protect the data they have access to or store during the course of the investigation.

Additional details on how to form a CSIRT can be found from CERT, NIST, FIRST, or regional incident response organizations.

More on the incident response process

Creating a proactive enterprise security incident response program

Incident response success in five quick steps

How can the computer security incident response team help with a data breach response plan?
While common sense would dictate that an incident response process would be more difficult amid a down economy when the number of IT and information security staff members has been reduced, it may actually be an opportunity for existing staff members to think creatively and build trust across different groups within the organization. To that end, let's discuss in more detail the various roles within every organization that lend themselves to participation in the computer security incident response team. Each CSIRT should include both core team members and ad hoc team members that are involved only when needed. The core CSIRT team can include representatives from major operating system groups, a network engineer and a member from the application group, for example. Ad hoc team members could be a person from the specific group involved in the potential data breach.

System administrators and application support staff are an obvious choice for a CSIRT. Often among the first to notice when an incident takes place and in turn notify others, they can look through logs to identify suspicious entries, validate administrative accounts, validate what services should be running on a system, provide access to systems or applications to core CSIRT team members, and many other basic tasks.

Other key participants include those from legal, compliance, physical security and public relations departments. Legal and compliance specialists can provide guidance on the laws, regulations, contractual requirements or other aspects of the incident to help guide the response; companies in heavily regulated industries like health care or finance might consider including a legal and compliance representative in the core CSIRT. Those well versed in physical security can provide data about the comings and goings of people in the organization or other aspects. They may even have relationships with law enforcement agencies and experience in reporting and investigating crimes. Public relations team members can help manage any interactions with the media. If there is any notification done to affected parties, all of these groups can help with the notification, as well.

However, in times when various departments are short-staffed, it may be difficult to convince some of them to provide a CSIRT representative, or to fully invest the time that's necessary to prepare for an incident. To help convince other departments to provide a CSIRT representative, convey to them that their time and expertise are both highly valued. This means only involving them when necessary and for the minimum time needed to respond to the data breach. They should be provided with clear procedures to follow that are specific to their roles in preparation for a data breach. Depending on the severity of the breach, they may not even need to be involved, which should be communicated to them so they know they won't be called upon when unnecessary.

When responding to a data breach while short staffed, at the very least a core CSIRT member, an IT contact knowledgeable about the system, and someone who is knowledgeable about the potential data on the system should be involved. These key staff members will provide the expertise needed to identify what data could have been affected, what security controls were in place and what incident response should entail. These individuals can also make recommendations on how to prevent future incidents.

Finally, post-incident analysis is needed to evaluate the effectiveness of the modified CSIRT team, as an incident response effort may be slightly different from the norm with a reduced staff. This evaluation should be prioritized, especially if various CSIRT team members exhibited new efficiency in the data breach response process that improved upon the fully staffed CSIRT methods. It's also good practice to notify management of the extended team's involvement in the data breach response, explaining in detail how they helped minimize the impact on the organization.

About the author
Nick Lewis (CISSP, GCWN) is an information security analyst for a large Public Midwest University responsible for the risk management program and also supports its technical PCI compliance program. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining his current organization in 2009, Nick worked at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University. He also answers your information security threat questions.


This was first published in May 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.