Testing the Team

‚  < ‚  Free Open Study ‚  > ‚  

Training is only an initial step. After the team is formed and initial training has occurred, the team should be tested . Testing can consist of scheduled events of which the team is aware ahead of time or no-notice tests in which only key personnel know that an incident is actually a test.

It is difficult to realistically simulate a security incident and is virtually impossible to test all aspects of the incident response process. For this reason, it is best to concentrate on critical pieces of the process when designing a test. Team leaders and senior managers should assess the perceived strengths and weaknesses of the team in the context of the corporate culture and decide what portions are most likely to need remedial attention.

The first point to test is probably the notification process. The system by which a user notifies the incident response team can be simulated simply by identifying a typical user, presenting that user with a situation, and observing the results. Did the user know whom to call or contact, how to contact that person (phone, email), and if not, where to get that information (from the intranet, phone listing, employee handbook)?

After the initial contact has been made, is there a process in place to contact individual team members ? Are the phone numbers (including, when appropriate, home, cell , and pager numbers ) correct? Do team members know what to do or where to go when they are contacted?

After the notification process has been tested, management might choose to expand the testing process. Again, it is difficult to accurately simulate an incident, especially if the team has operations members. There are, however, ways to test the response process without impacting mission-critical applications.

The team can be assembled and a scenario presented. This is probably best done by an outsider (or at least not a team member). The scenario would present an initial problem, and members would be asked to describe their actions in response. As they continue, more details would be provided.

For example, the scenario might be that a critical server has started malfunctioning. The team might state that it would review logs, both on the server and on associated machines. [1] The facilitator would then provide more information such as the contents of the logs. Based on that data, the team would be asked to expand its answers and provide details about follow-up steps.

[1] Note:This is intended as an example only, and the information in this scenario is not intended to be the right or wrong answer as to what actions to take in such a situation.

This scenario-based approach can also be valuable as a training aid for the team and management. Senior managers, incident response team members, and operational managers can be pulled into the scenario. Each constituency can be asked what it recommends as response steps and to defend its actions. The difference in perspective between line managers (who probably want to get the system back online quickly), incident response personnel (who want to find out who attacked it), and operations personnel (who want to find out what happened and fix it) can be extremely enlightening to everyone involved.

Finally, it is sometimes possible to actually simulate an incident, provided that proper safeguards are in place to ensure that neither the simulation nor the response actually damages production systems. For example, an external attack can be launched at the web server to test whether the intrusion-detection software catches the attack and whether the notification and response procedures are properly implemented.

It is almost certainly better to employ outside facilitators to conduct team testing. It is unlikely in all but the largest organizations that trained incident response personnel exist with the qualifications to assess the team (unless they are already team members). Bringing in outside facilitators can also help reduce advance knowledge of the test to assist in gaining a more accurate perspective of the actual situation within the team.

Outsiders can range from paid consultants to peers from other organizations. For example, if persons in the company have personal relationships with other incident response teams, members of those teams can be invited in to facilitate and observe the testing. Professional organizations such as HTCIA might be sources of such contacts. Law enforcement might be willing to provide assistance (but keep in mind that law enforcement personnel have their own interests and those interests might not directly coincide with the company's).

There are no easy answers regarding whom to select as facilitators and how to judge their qualifications. Much depends on reputation as well as technical skills. The target audience must be considered as well. If, for example, the team (or the portion of the team being evaluated) consists of highly technical personnel, the facilitators must have technical personnel as well. A group of generalists will probably not be taken seriously by technical specialists. Conversely, if the focus of the test is to demonstrate policy shortcomings to senior management, management consultants with a knowledge of security might be better suited to discuss the business impact of the problems as opposed to the technical details.

A good start for selecting facilitators might be an organization with which the team already has a relationship. This could be the consulting arm of a product vendor or consultants who have previously performed engagements for the organization.

Demonstrating Interteam Communications

One major challenge with incident response is accommodating multiple, often widely varied expectations. Technical personnel tend to focus on the technical side of the problem. Businesspeople tend to ignore the technical realities and focus on the business issues. Other key personnel, such as legal or human resources, might also find it difficult to view the entire incident.

One suggestion for demonstrating the difficulties inherent in such a multidisciplinary approach is to conduct a training scenario specifically designed to illustrate these issues.

Team members (including nontechnical personnel) and other constituents are assembled in separate rooms. The facilitator presents each group with the same scenario. When a group develops a course of action, that information is then presented to the other groups by the facilitator.

The role of the facilitator in this scenario is to present each group's recommendations and explain the rationale behind its decisions. Other groups might have come up with dramatically different ideas as to how to proceed because they approach the problem from a different perspective.

If done properly, all participants will emerge from this training with a new appreciation for all the considerations that go into a holistic and complete understanding of a major incident.

‚  < ‚  Free Open Study ‚  > ‚  


Incident Response. A Strategic Guide to Handling System and Network Security Breaches
Incident Response: A Strategic Guide to Handling System and Network Security Breaches
ISBN: 1578702569
EAN: 2147483647
Year: 2002
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net