Information security solution providers, including VARs and consultants, have long understood how they can assist their customers in creating defenses against attacks.
Unfortunately, despite the best efforts of both the solution provider and the customer, some attacks are successful. When a successful attack occurs, a well-thought-out
Solution providers should consider carefully before specifying their own roles in the incident response team. Consider the worst-case scenario: What if simultaneous attacks were made on many of the solution provider’s customers at the same time?
Solution providers can add value by guiding the development process of the security incident response plan for customers, ensuring no required component of the plan is missed, offering insights about what has worked and not worked in the past, and leveraging their expertise with tools such as network and database log analyzers to train technical staff in their use.
Security incident response plan: Getting started
The first and the most difficult step is to convince a customer to allocate the resources needed to develop an incident response plan. Of course, after working with customers to select and install best-in-class security products and services, solution providers may be challenged to explain why a breach may still occur, despite careful, well-researched product choices.
This step can be the most challenging part of the whole process. If a customer doesn’t see the value in security preparedness, there are plenty of relevant, recent examples (such as the recent attacks against RSA and Lockheed Martin, to name a few) when organizations that already made significant investments in security technology were attacked and avoided greater damage thanks to effective incident response.
Once the customer has agreed to develop an incident response plan, the next step for the solution provider is to assemble an incident response team. This team will include technical staff members who will be responsible for detecting attacks, taking action to further block attacker access, and then identifying the compromised data.
Include staff from the customer’s public relations and the legal departments, who will be responsible for quickly and accurately communicating with stake holders and, if necessary, government authorities.
Finally, designate a team leader to coordinate activities within the team and communicate status to upper management. These team members may be the solution provider’s own staff or they may come from the customer’s IT department. However, solution providers should consider carefully before specifying their own roles in the incident response team. Consider the worst-case scenario: What if simultaneous attacks were made on many of the solution provider’s customers at the same time?
Once the security response plan is developed, each team member must be thoroughly familiar with it and understand his or her role. Newly hired team members must be immediately trained on procedures; there will be no time to begin reading the plan after a breach occurs.
Security incident response plan: Staying flexible
No single plan can address all of the potential incidents. The response to attacker access to millions of credit card numbers will differ from loss of a laptop containing a few hundred employees’ Social Security numbers.
Work with the customer to develop processes to maintain accurate, up-to-date documentation with a detailed description of the data maintained within the network and all attached systems. Applications and business processes change rapidly. For example, network staff may be unaware an application has been updated to maintain an additional data item. Virtual processing and cloud computing can make the location of data uncertain.
Log files are critical. An incursion may continue for months if logs covering all critical points in the network are not examined on a regular basis. Make sure the incident response plan specifies a schedule and one or more designated individuals responsible for monitoring and analyzing logs, and ensure logs are backed up and retained. Regulations such as HIPAA and Sarbanes-Oxley specify how long logs must be maintained for specific types of data. In cases where there is no legal requirement, determine and document how long to maintain logs.
Disclosing a security event
Any breach may negatively affect the customer’s reputation in the marketplace. But delay in reporting the incident or providing incomplete or inaccurate information to the public can greatly increase the negative consequences.
The incident response plan must include a public relations plan that specifies a small set of individuals responsible for external communication. It is critical all team members understand only designated individuals speak to the public or to the press.
Legal disclosure requirements are constantly changing and differ across geographies. The incident response plan should specify one or more individuals among the customer’s legal staff who stay current on the laws in every location where the customer does business. Solution providers may offer to take on the responsibility of tracking changing laws as a particularly valuable service for small customers without an in-house legal staff.
Internal communication within the response team is equally critical. Designate a coordinator to gather status updates, and specify communication procedures that don’t bog down the team with daily status meetings or extensive written daily reports. Make clear all team members must communicate only through specified channels to control the flow of incomplete or contradictory information.
Rehearsing the plan
Rehearsals are a useful way of verifying all mechanisms are in place in case of an actual attack. The solution provider should create an attack scenario, with each response team member responsible for assuming his or her role as if an actual attack took place. It will become immediately apparent if system documentation and logs are not current or team members do not understand their roles.
Finally, solution providers can offer a valuable service by notifying customers when it is time to update the incident response plan or stage a rehearsal. Given today’s limited resources and false security about an attack probability, it’s easy to postpone allocating the needed time. The bottom line is a solution provider’s timely reminder can make the difference between being prepared or being caught off-guard when an attack occurs.
About the author
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.
This was first published in August 2011