It's almost impossible not to recognize the importance of computer security in today's economic and political climate. The national news media devotes ample coverage to computer security issues, often sensationalizing the latest computer virus or so-called hacker attack. In fact, that very sensationalism can distract you from day-to-day security threats. Computer security encompasses a wide range of potential threats and basic concepts, and you can never underestimate the real business costs of security failures. Consider the following:
Most companies store proprietary information regarding their products or services both online and in hardcopy documents. If competitors obtain a company's product specifications and plans, they may be able to drive it out of business.
Companies have a legal obligation to protect the sensitive employee information they collect for payroll and other purposes. If the security of that information is compromised, the company may be subject to lawsuits and legal fines.
Some companies, such as banks, are subject to laws regarding the security of the information they use. For example, if a bank's customer records are accessed by unauthorized personnel, the bank can be subject to hundreds of thousands of dollars in fines, not to mention lawsuits by their customers.
Sixty years ago, companies kept sensitive information in locked filing cabinets. The cabinets made the information difficult to share throughout the company, but they helped keep the information secure. Today, almost every important piece of company information is kept on a computer. Computers make it very easy for employees to share information with one another?even if that information is sensitive and shouldn't be shared. As more and more information is stored on computers, computer security will play a more important role in protecting that information. And because some of that information is more sensitive than others, you should consider defining the security criteria for that information. See the "How Secure Is `Secure Enough'?" sidebar and Chapter 15 for more information.
How Secure Is "Secure Enough"?
How do your company's employees know when the workday is over? Generally, a written policy establishes regular working hours. So how do you know what corporate information is sensitive and how strongly it should be protected? Again, a written policy should tell you. The primary focus of this book is to tell you how to implement security measures, but only your company's written security policies can tell you what security measures are required.
If your company doesn't have a written security policy, it needs one. A security policy provides you with guidelines that tell you how much security is necessary in your environment. The policy also provides you, as a Windows administrator, with the authority to implement actual security mechanisms to protect corporate information. Security policy is discussed in depth in Chapter 15.
Too often, administrators are asked to create and enforce the security policies for their companies. Often, the assignment is implied in a simple question like "Hey, are our files secure?" But administrators are rarely in a position to create and enforce corporate security policies. For example, do you consider yourself an expert on intellectual property law? What about trade secret law? Do you know what damage a competitor could do if they obtained information from your company's files? Can you quantify the risk of such damage in financial terms? Do you know exactly what information each and every person in your company needs to do her job? Most likely, the answer to one or more of these questions is "no." That's why security needs to be much more than a technical concern; it needs to be a political concern first. Throughout most of this book, I'll show you how to use Windows technologies to implement security, but the political powers at your company?management and executive?need to define the need for security and tell you what needs to be implemented or protected.
For security to be effective, you need to have a clear, written policy. That policy needs to be written?or at least approved?by the people in your company with the power to make it stick. Generally, that group should include the president of your company or perhaps a chief operating officer or a group of managers. Without full management support, a security policy may not be implemented correctly and will almost certainly be circumvented or discarded in the future.
Think of security policy as a form of law and you and your fellow administrators as police officers. Your company's management represents Congress or some other legislative body. Your job as a police officer is to enforce the law. You don't get to decide what's legal and what isn't; that's Congress' role. Without clearly written laws from Congress, you won't be able to enforce anything. As a police officer, you know that all laws you enforce have passed through Congress, and you can be reasonably sure that these laws represent the best interest of the people they govern. You cannot distinguish between good and bad laws; you enforce them all evenhandedly.
Sometimes a good police officer sees a law that should be struck down or modified. As a security administrator, you will periodically see security policies or procedures that are flawed. This does not entitle you to deviate from the job; the policy in question may be crucial for another element of the business that's outside your scope of awareness. However, as a good employee and administrator, you should be alert for such flaws and bring them to the attention of the policy makers. In this way, your expertise flows back into the policy-making process, and the system is improved.
So what constitutes a good security policy? Policies will differ widely from company to company and may differ widely even between departments within the same company. But all good security policies will have a number of common characteristics. Every good security policy:
Written security policies can be easily communicated without loss or distortion of information.
In other words, the policy shouldn't worry about how the policy is enforced, it should just state what will be enforced. For example, "Documents pertaining to company projects must never be accessible to nonemployees" is a good policy statement. "Documents must be protected by NTFS security" is a poor policy statement, because it focuses on the implementation of the policy.
A policy that says "Information pertaining to company projects must never be accessible to nonemployees" works because it can apply both to physical paper documents as well as electronic documents. This broader coverage ensures that the security policy is comprehensive. Simply requiring password protection for electronic documents, for example, won't protect those documents once they are printed and left lying on someone's desk.
One role might be "document owner," applied to the person or group of people responsible for the security and contents of a particular group of documents. Another role might be "document reviewer," applied to anyone who needs to read documents but doesn't need to modify them and isn't responsible for the documents' security. These roles can be used to determine what people can do with documents. For example, your policy might state that "Document reviewers may access only electronic documents and may not create hardcopies of the documents they review." This type of policy gives you, the policy enforcer, clear directions on how to configure your computer systems to comply with the policy.
The person who submits a document for classification, for example, should not be the same person that assigns the classification. This could lead to a single person owning the entire security process, thus negating the benefit of having multiple people involved in a security audit trail of the secured information. A general rule is that, within reason, the more individually implemented roles that are required to implement a security process, the less likely it is that a single compromised or untrustworthy employee can compromise the data. This practice is often called role separation and is discussed throughout the rest of this book.
Perhaps a quarterly audit of the security mechanisms is appropriate in your company, allowing an independent person to verify that you've implemented measures to enforce and comply with the written policy. Other companies might need more frequent or less frequent audits, depending upon their needs.
As you can see, security policies can be quite detailed. They don't have to start that way; simply starting with a basic written policy is better than having no policy at all. As your company grows more comfortable with the policy and begins to better identify potential security risks, the policy can be revised and expanded accordingly. For more information on security policies, see Chapter 15.