Procedures to Enforce Policies

Procedures to Enforce Policies

Policies are only the basis for procedures to implement the Policies. The procedures should not be part of the Policies themselves . They are standard operating procedures that lay out the execution of the Policies. The procedures need to define who is responsible, what they are responsible for, and what they need to do to ensure compliance with policies. While the policies are the "what" (and often the "why," which can increase buy-in), the procedures are the "how." However, as technologists (the polite termsome would rather use " geeks "), we usually are much better at the " hows " than the " whats ," so we do not go into as much detail on that. Besides, procedures are highly technology dependent and in large part follow from everything else we cover in this book. A few exceptions are worth noting, however.

You must absolutely have a procedure for managing emergencies. Unfortunately, when we ask system administrators what the emergency response procedure looks like, the answer we usually get is something like this:

1.	Get call from police.
2.	Panic.
3.	Update resum .

This is, obviously, suboptimal. You need a better emergency response process. At a very minimum the process needs to cover the following:

1. Disconnect the system . Do not allow attackers to get any farther in than they already are. Of course, this presupposes that you know you have been compromised, which is nontrivial. You may not want to just turn off the system. That could compromise in-memory data needed for forensics. Deciding whether to disconnect also depends on what the intruder is doingif he is just poking around and not affecting the $10,000-per- hour revenue generation of your Web server, maybe you should not disconnect the cable because if you do, you will cause a loss of revenue. Conversely, if the attacker is destroying data, disconnecting the cable right now is probably a good idea!

2. Who to contact and how ? Most organizations have a call list. Unfortunately, it is usually full of mobile phone numbers that no longer work. When the network is melting around you is the wrong time to find out that your sys admin's old cell phone number now goes to a 93-year old grandmother in Spokane. Not that she is not very nice, she is just not very useful to you at the time, unless the emergency is a critical shortage of butter cookies.

3. Who will analyze what ? The people involved in the emergency need to have very clear responsibilities, the skills to fulfill those responsibilities, and the tools they need to do that job. Again, when the network is under attack is the wrong time to go looking for a hex editor.

4. How do we restore service ? Perhaps more important than anything else is getting back online. After all, that's what your systems are for in the first place. This process should be defined in the emergency response plan. The plan also should include how to restore basic services for the people who are running the emergency response process. You may want to consider having a "network in a box" ready to go for those people charged with responding to emergencies. This could consist of a few clients , a server, a printer, maybe an e-mail or Web site already configured on the server, etc.

5. What to do afterward . When things settle down, you should conduct a post-mortem activity. Review what happened , how the attacker got in, any damage done, and the effectiveness of your response. Feed your results back into your process for improvement the next time.