Defining Incident Response Policy

Defining Incident Response Policy

Once the members of the incident response team have been identified, they should convene to build an incident response process and a supporting policy. Some of the related policies might already be in place in your organization, but the team will need to review how each of these policies relates to incident response and recommend changes that support incident response activities. The team must also formalize the approach to take should responding to an incident become necessary.

Categorizing Types of Incidents

Up to this point, we have been using the term incident in a generic manner. An incident is an occurrence that creates some level of crisis and requires action to reduce or eliminate the risk caused. Possible incidents, or threats, range from computer intrusion, denial of service, virus infestation, and inappropriate access to events that normally call for disaster recovery measures, such as power outages and other forms of force majeure.

Because of the wide range of incident types, it is helpful to define policies and procedures for each type of incident. Steps appropriate to foiling an attacker might not work as well when dealing with a citywide blackout or an insider viewing the salary details of the rest of the company s employees. By categorizing each type of threat and defining both proactive and reactive responses to them, your team can eliminate much of the ambiguity that occurs when executing a response.

Whether the occurrences your incident response team responds to are accidental, malicious, or happenstance, the team members will require guidance on the response techniques expected of them. Such techniques must be defined in advance so that valuable response time is not wasted defining them during the crisis. As part of the overall incident response policy and process, a number of difficult decisions must be made and documented in advance of any incident. Doing so ensures that the roles and responsibilities of any given team member are not called into question during an incident response and that the boundaries of the activities that can be conducted without seeking additional approval are clear.

Ensure that the incident response team s escalation path, priorities, process, and constraints are clearly defined and documented before an incident occurs. Failing to do so will likely result in wasted time during critical periods of the incident response as team members try to define their roles and responsibilities on the spot or locate members of management team for additional approval or instruction.

Outlining Proactive and Reactive Responses

Once you have detailed the different types of threats, you should examine the methods needed to exploit each of them. Once you have developed a list of methods, you should go through the list methodically to define the proactive and reactive approaches your team will take for each incident type.

From a proactive standpoint, you should predict the following:

  • The possible damage your organization can incur

  • Any potential vulnerabilities in your network

  • The security measures and controls needed to minimize those vulnerabilities

  • The contingency plans needed should your protective measures fail

From a reactive standpoint, you will need to determine the following:

  • The amount of damage inflicted and its cause

  • How to prevent additional damage from occurring

  • How to repair the damage that has been done

  • How you will document and learn from the experience

  • How to implement any contingency plans necessitated by the event

Determining Whether to Prosecute the Attacker

When defining procedures for a reactive response, you need to make a number of difficult decisions. Though primarily business decisions, these decisions will have a dramatic effect on the tasks your team members perform. One example of how business requirements can impact an investigation is the decision to prosecute an attacker. If your organization intends to prosecute the offender, the proper collection of evidence will often take precedence over the restoration of service. For instance, if a system will be used as evidence in a court of law, that system must not be modified at all, from the moment the incident occurred until the court date which makes securing the system and restoring service problematic.

We will discuss specific investigative techniques in more detail in Chapter 27, Responding to Security Incidents, but this example illustrates some of the challenging decisions the incident response team must make. By making such difficult decisions proactively during your incident response planning stage rather than reactively making them during an incident response you buy yourself a great deal of time to discuss the relative merits of each approach. Of course, this also allows for the possibility of analysis paralysis , where an extended discussion is the only thing that gets accomplished. Be wary of that outcome in your response planning meetings.

A corollary issue to deciding whether to pursue a law enforcement solution (rather than simply restoring service) is the likelihood that such prosecution will bring media attention to your organization. Weigh carefully the impact that this could have on your company s reputation and brand image. Although a positive outcome is possible when pursuing law enforcement, your team s handling and communication of the incident will play a significant role in shaping the outcome. We will discuss this in greater detail in the Creating a Communications Plan section of this chapter.

Deciding Whether to Stop the Attack

Another frequent challenge faced by incident response teams is whether to stop the attack or collect additional information about its root cause. Although preventing the spread of an attack or virus might seem like the obvious choice, tipping off an attacker that you are onto him could have devastating results for example, if the attacker decides to wipe out the entire system in an effort to reduce his risk of being caught. By disconnecting a computer from network to preserve its state for further examination, you could be alerting the attacker that you have discovered his presence. This could result in the attacker attempting to compromise other computers on your network that have not yet been compromised or immediately initiating destructive methods on other computers he has already compromised to prevent collection of evidence that could be used to track him. In a similar vein, deciding to watch the attacker and gain more information about the extent of control he has over systems in your network and the techniques being employed to expand influence could open your firm to downstream liability if your network becomes a launching point for an attack against another network.

Constructing Policies to Support Incident Response

The incident response team cannot be successful if the rest of the organization is not prepared to properly support the team s activities. The most effective way to drive behavior that will support the team is to codify these behaviors into policies and guidelines and use them to direct the organization as a whole. When crafting these policies, be sure to consider how staff will receive them. If the policies are written in a dictatorial manner, they might lack effectiveness because of people s inherent resistance to change. If, however, they are written as thoughtful explanations outlining not only the what but also the why, they will be better received and more diligently followed.

That latter point is critical: the best policies are useless if they are not observed. Again, owing to people s resistance to change, the best policies will be those that stand the test of time rather than those continuously rewritten and distributed. A policy should be written in a manner that will not require frequent revision. Lasting policies describe the needs of the business and the direction that must be taken to support those needs not the specific steps to be taken. Lasting policies are the what and the why, but they are not the how.

Acceptable Use Policy

A primary policy supporting incident response is the acceptable use policy (AUP). This policy reduces overall risk by providing guidance to staff about the appropriate use of the company s network (and by extension, the types of activities that are higher risk and therefore not appropriate). In addition, this policy provides a method for paring down the potential traffic types to allow for easier baselining of network traffic.

The AUP should also contain language that covers the employees rights and privacy, in addition to their responsibilities. Although your legal counsel should be involved in crafting this policy, you should consider a couple of key points. First, clarify the company s stance on personal privacy. Is personal use of company resources allowed and, if so, to what extent? Many companies recognize that their staff can make reasonable judgments about when their use of company resources is excessive and use a self-managed approach; others are more strict in their guidelines. Second, note that this portion of the policy should indicate that e-mail is considered a corporate resource that should not be misused and under the course of normal security operations can be monitored.

Clarifying that the possibility of monitoring exists can eliminate the expectation of privacy on the part of employees. Privacy expectations can dramatically impede an investigation. If an expectation of privacy exists, it might not be possible to review e-mail records or, in some cases, to utilize network monitoring software. Furthermore, if your organization uses encryption, a user s unwillingness to share her encryption keys because of privacy concerns could further complicate the investigation. Again, consult with your legal counsel if you have questions on this topic, and note that privacy laws vary by jurisdiction.

Access Policy

Another important policy involves access. This policy will define the conditions under which connections to other networks (such as the Internet, your business partners networks, and so on) can be implemented. The policy should also clarify which groups in your organization can provide the best security practices for ensuring that such connections are deployed and managed appropriately. Access policy should do the following:

  • Include language discussing guest or vendor access to the company network

  • Detail the circumstances under which such access is and is not allowed

  • List the appropriate contacts for any questions or comments

Availability Guidelines

Guidelines for availability are another area to address in incident response policy. Specifically, you need to clarify how availability might be affected during an incident response and during security-related maintenance. By clearly stating that security is a priority for your organization, you support the needs of your team during the inevitability of being forced to take a system or network connection offline to defend your environment. This can help to ensure that incident response needs are not immediately subordinated by uptime requirements. In addition, you send a message on the importance of security to the firm which can be a component of a larger security awareness campaign.

Classification Policies

Defining who should be granted access to which type of information and how broadly that information can be shared is another critical component of ensuring the protection of your company s assets. Classifying data into different sensitivity layers provides guidance to staff on the circulation restrictions of any given document and helps to protect against inappropriate leaks. Examples of classification schemes include unlabeled, secret, top secret, eyes only and public, internal only, internal-restricted viewing, highly sensitive. You must choose labeling that is appropriate to your business rather than blindly copying from another organization s classification policy. You need to do a business analysis of the types of information your company creates and work with your business managers to identify the minimum appropriate levels of confidentiality.

Password Policy

Because one goal of the incident response process is the elimination of incidents throughout the organization, you should consider providing further guidance to all staff on how they contribute to the overall security of the company. Because every employee is a link in your firm s security chain, ensuring that steps are taken to eliminate weak links can be just as important as the work that is done after a breach occurs.

One common place where weak links exist is in an organization s password policy. The password policy will indicate choices the organization has made about authentication. This policy is not limited to text-based passwords it includes other forms of authentication, such as smart cards, biometrics, and tokens. Beyond simply covering the requirements of each authentication type, your organization s password policy should differentiate specific access types that require specific authentication factors. Policy might be different for service accounts, user accounts, administrator accounts, remote access accounts, and so on.

When addressing each access scenario local area network, VPN, wireless, etc. take into account the specific business requirements and the security threats that type of access involves. The password policy should also discuss the following:

  • Whether it is appropriate for individuals to share credential information and under which circumstances

  • The process for granting and receiving assistance on password resets that protect against social engineering (For more information on social engineering, see the sidebar in Chapter 25, Social Engineering. )

  • Standard considerations for the duration of password life

  • The complexity requirements for passwords

  • The number of failed logons allowed before lockout

    See Chapter 3, Securing User Accounts and Passwords, for more information on configuring password policies.

Security Reporting Policy

Policy relating to security reporting is often overlooked, but it plays a critical role in the speed of your incident response. You will need to describe the types of potential threats clearly enough so that all staff can understand those risks and identify when one of those risks is being realized. Security reporting policy will also clarify who should be contacted if a potential compromise to your organization s security is occurring, what information needs to be provided, whether the contact is anonymous, and how information about the incident is collected.

Putting It All Together

Finally, you need to craft an incident response policy that describes how each of these pieces fits together to support your incident response efforts. The overall incident response policy will also detail issues that must be addressed during an incident response that might differ from normal, day-to-day operations. Items such as monitoring, availability, chain of command, and other components of the investigation are essential here. In addition, this blanket policy must include a discussion of the consequences associated with impeding the investigation or performing a policy violation that leads to a security incident.



Microsoft Windows Security Resource Kit
Microsoft Windows Security Resource Kit
ISBN: 0735621748
EAN: 2147483647
Year: 2003
Pages: 189

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