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
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.
How can the computer security incident response team help with a data breach response
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