Virtual Teams-Ensuring Availability

Virtual Teams ‚ Ensuring Availability

One major problem with virtual teams is that team members might not be available when required. If their daily responsibility is operations, it might be difficult to pull them when needed ( especially if the affected system in an incident is one for which they are responsible).

The policy that establishes the incident response team should clearly articulate the requirements for availability. Senior management sponsors should affirm the policy that incident response duties must take precedence over normal operational responsibilities. If this is not clearly stated to line managers, they might be unwilling to release team members when they are required. Because team members will eventually go back to reporting to that line manager, they will obviously be reluctant to alienate him or her.

Another major consideration is defining what the actual availability requirements are. For example, do some team members need to be available in real time, or can they contribute on a different schedule? Team members with critical technical skills might still be able to contribute if, for example, they are sent data to analyze and are given a deadline to complete the work. This analysis does not necessarily need to be done concurrently with other response work.

The incident response hotline might need to be staffed around the clock, or maybe a help desk can fill in during normal working hours. In many cases, the help desk is the user 's first contact, so the person staffing it needs to understand the basics of recording incident information and reporting it to the team. Team contacts might be available via cell phone or pager at other times.

Real-time availability is preferable, however. External coordination with other agencies (law enforcement, service providers, other victims, and so on) requires real-time contact ‚ especially if the data is extremely time sensitive ‚ and communications lags can be damaging . For example, if the intruder is still connected, the intrusion is best traced immediately. If the attacker has left the system, it is likely that logs might be overwritten or destroyed unless immediate action is taken to preserve them. Incidents also can have an extremely short duration. If the incident response team is not immediately reachable , constituents might go elsewhere for support or might not receive any support at all until it is too late.

Collection of data might be time sensitive, but analysis of that data might be much less so. Preparatory activities such as analysis of vulnerabilities and preliminary coordination with other operational units within the organization and with external agencies can also be performed on a more relaxed time schedule.

Unfortunately, good incident response team members are probably also good operations personnel. The same character traits that make a system administrator invaluable can quickly burn him or her out when reacting to an incident. One solution is a revolving duty roster. Team members would be responsible for initial response (including answering the hotline and email or wearing a pager) for a set period of time. After that on-call period, they would rotate to a reduced alert status. Although still available for support, the initial steps (including the midnight phone calls) would go to the next person on the list.