Policies and Procedures

Policies and Procedures

Before you make any major changes in the way you use your network and resources — and adding encryption is a major step — you shouldn’t dive right into a solution before you have prepared your Encryption Policies. I know paperwork is such a drudge, but in doing this it will also help you decide what your needs really are.

The questions you need to address in your policy are as follows:

  • Who is the big boss when it comes to encryption decision making?

  • What are the responsibilities of the general users, executives, and maintenance staff in regards to encrypting and decrypting data?

  • Are you going to handle this on your own or outsource?

  • Who will handle the day-to-day maintenance of the system?

  • Will your encryption be used internally only or with the outside world?

  • Which algorithms are you going to use?

  • What data will always be encrypted?

  • Is there any data that will be encrypted on an ad-hoc basis?

  • What rules will a person follow in deciding to encrypt on an ad-hoc basis?

  • How much training will you give the staff?

  • Who will be in charge of training?

  • Will you have staff sign a policy statement that says they understand the rules for encryption?

  • If a decrypted document is to be printed, how will you make sure that unauthorized personnel can’t pick it up off the printer?

  • How long will you store encrypted documents?

  • Who is the response team to handle lost keys, lost passphrases, and corrupted data?

  • Will you need authentication as well as encryption to make sure that only authorized personnel can get access to keys and encrypted data?

Believe it or not, this list could go on for pages! What I’ve given you are the top level questions. As you answer these, you’ll realize that there are more questions to be answered. This is best handled by a small team that occasionally works with others within the company for input. Keep your policies on an internal Web site so everyone has access to them. Also keep hardcopies in a folder in case of network outages.

When you have all of your policies together, you can start working on the procedures. I know a lot of people get these two things mixed up. The difference is that the policies are the rules you need to follow; the procedures are how you will implement and enforce the rules. For example, your company has just named Bob as the Grand Poobah of Encryption Decisions. You need to give Bob some parameters with which to make decisions. Does he do this solely on his own or with help? What help should he seek? Does he have the authority (and budget) to hire a consultant? Blah, blah, blah.

The same sort of things hold true for both the general users and the maintenance team. If someone notices that a decrypted document was printed and is now missing, what do you do about it? Who do you report it to? Again, as you work through your policies you’ll realize that some of the questions that come up are actually implementation, use, and maintenance concerns. You should spell out what everyone is expected to do, when they need to do it, and how you are going to handle problems. If you get your policies and procedures started, you’ll be surprised how easily the actual rollout happens. You’ll save yourself a lot of money in aspirin and you’ll be a winner that everyone wants to emulate. Our hero!

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows