Security Policies

Good security implementations are based on good security policies. Security begins not with encryption algorithms, firewalls, or advanced authentication techniques; it begins with a clear and well-defined security policy. The policies define the rules by which everyone should abide. They provide the guidance necessary for effective implementations. Put another way, how can you know if someone is breaking the rules if no one has clearly defined what the rules are?

Tip 

Security begins with a clear and comprehensive security policy.

Most people will argue that the Information Technology (IT) security policies are self-evident: users shouldn’t do what they’re not supposed to do. This isn’t good enough. Without a clearly defined policy, there is nothing to implement, nothing to enforce, and no way of knowing if you are secure because there is no reference for comparison.

There must be specific policies about authentication, access control, and auditing. Confidentiality and privacy concerns have to be addressed as well. However, there is no “one-size-fits-all” security policy. Determining how to protect is based on what you are trying to protect.

An important part to ensuring the policies are effective is by making sure they are supported by the senior management within an organization. Security is a shared responsibility. It is not just your responsibility; it’s also your CEO’s. However, the CEO may or may not realize this. The senior management should support the security culture through means such as funding, the creation and support of dedicated security personnel, and above all, endorsements that stress the importance of adhering to the company policy.

Tip 

Security is a shared responsibility between IT and the organization’s CEO..

Different Policies for Different Needs

There is a direct correlation between the security policies, the security implementations, and the data. Security policies range from general and generic to extremely specific. From an IT perspective, they initially apply to all applications throughout an enterprise. For example, a policy might dictate that auditing will be conducted for user accountability. The general policy may not specify how, when, or to what level of detail the auditing needs to take place. As applications are developed and fielded, the security policies associated with the applications can become more specific to the applications.

An application that handles company financial data may further augment the auditing requirement by specifying that auditing will occur within the database and operating systems and will capture all user actions for all transactions of a specific type. The policy might also specify how and for how long the audit records will be managed. A separate application, in contrast, may only audit users as they log on and log off, with no audit retention period specified.

As discussed, the policies can vary in level of detail and level of enforcement. These variations are based on the data sensitivity and the application’s intended use. For sensitive data, such as proprietary data, the policies are strict and may cover everything from the physical protection to availability and recoverability to the personnel operating the system. For applications that deal with less sensitive data, such as an intraoffice equipment checkout application, the policies are generally less comprehensive and less strict.

Policies for Compliance

Establishing sound security policies is a good idea without exception. However, sometimes security policies are motivated by external influences. Some policies are created for compliance purposes. Regulations are often written to ensure that companies are properly and responsibly handling data. This is generally based on an analysis of the type and use of the data within an industry, agency, or community. Companies respond by creating a policy that ensures compliance with the statutory regulation(s).

Many times, the challenging part to policy creation is interpreting the loosely defined regulation to which the policy is directed. For example, privacy is an ever-growing concern in many industries and thus for many organizations. There have been many laws passed regarding the handling of privacy data. In essence, the laws say to protect privacy information and disclose it only to appropriate parties. It is left to the organizations affected by the regulations to interpret what this means and then to define a policy that meets and maintains compliance with their interpretation of the regulation.

For example, a company policy may dictate the use of encryption as a guard against the inadvertent disclosure of privacy-related data. The genesis of the policy was compliance with an applicable statutory regulation.

Effective security for meeting and maintaining compliance issues is based on the ability to accurately interpret and understand the intent of the regulation. Does encrypting the data meet compliance? Perhaps it does not. To find the answer, the relevant questions to ask are who is an appropriate party, and how could inadvertent disclosure occur? Compliance may be better met through something other than encryption (for example, controlled physical access to the data coupled with strong authentication). For this reason, it’s important that the parties involved in implementing the security are aware of why the security is there and what it is guarding against. Otherwise, it is possible that the wrong tool will be used to solve the problem, a false sense of security will be created, and compliance will not be met.

Understanding Security Requirements

Security is in many ways a defensive art. You have to understand your attackers, what their motivations are, what they are targeting, and how they will try to achieve their goal. For the bank robbery scenario, the motivations and target are obvious. Making a bank secure involves an understanding of who the potential robbers are (employees or nonemployees) and how they will try to steal the money.

If you don’t understand why you are protecting something and what you are protecting it from, you might apply a security solution to a problem that either doesn’t exist or can’t be solved with the tactic you are considering. Many of the techniques used to prevent bank employees from stealing money are different than those used to prevent nonemployees from stealing money.

Similarly, trying to protect the database data from DBAs is different from trying to protect the data from a compromised application server, which in turn is different from meeting a compliance concern. In Chapter 13, you will see that database encryption can be used to help ensure privacy, but it may not be an effective tool for protecting the data from the DBAs. If someone asks, “How do I effectively do database encryption?” You should reply, “Why do you think you need database encryption? What data are you protecting, and from whom?” The answers to these questions will guide you toward the correct security solution and will help you ensure that you are using the appropriate tools and techniques.

Policy Creation

The saying “why reinvent the wheel?” is applicable to policy creation. Policies can and should be reused or based on existing policies whenever possible.

Creating policy templates is a technique practiced often within organizations. The templates represent the basic types of applications and data used within the organization. You create a template by categorizing the different types of information the organization will be working with, such as proprietary, personally identifiable information, publicly accessible, or partner sharable. Policy templates are created with varying levels of specificity, depending on the sensitivity of the information and how it will be used. The templates can then be used as a jumpstart for new data, and applications with specific exceptions or changes can be incorporated as needed.

Many organizations use the security best practices offered by independent organizations and regulating bodies as starting points for their original templates. The National Institutes of Standards and Technologies (NIST) Special Publications for Security (SP800), the International Standards Organization (ISO) 17799, and the Health Insurance Portability and Accountability Act (HIPAA) are three great references for security policies. They are high level, broad, and comprehensive. A Google search will point you to the plethora of Internet resources available describing the different aspects of these policies and regulations.

Practical Policies

Creating policies can be difficult as you can be tempted to define a robust and comprehensive policy. This by itself is not bad, but there is a potentially bad side effect. Before you embark on creating a rigorous and overzealous security policy, be aware: maintaining the correct level of detail and right level of enforcement is important, because too much security can be self-defeating. This is because security often competes with usability. A perfect example of this principle is password policies. Often, companies will create very strict password policies in an effort to increase security. The policy might indicate that the password must be at least 12 characters in length, contain mixed upper- and lowercase characters and at least one number, expire every 21 days, and not be reused for five years. It’s easy to get carried away.

The problem in this is it exceeds most people’s cognitive abilities. People generally cannot create passwords with that level of sophistication that frequently, and users resort to creative ways of solving this challenge, such as writing the password down. They then leave the documented passwords in plain view so that security overall is not increased, but diminished. In this example, the net result of employing a sophisticated password policy is a less secure environment.

Note 

Effective security has to incorporate practicality and usability issues to ensure that the overall security of the system will be increased.

The challenging part is keeping the policies practical while still meeting rational security requirements. To do this, it is advisable to have the policies written by and agreed on by not only the security team, but also employee representatives or members from the usability group. This buy-in is essential to ensuring a successful security implementation.

Balancing Security

It’s not possible to build systems that are 100 percent secure. Too often I see people trying to do precisely this. As illustrated in the password policy example, what they end up with is something that is impractical, unusable, and often not much more secure than a practical policy. Deciding how to implement effective security is difficult for several reasons.

One of the biggest challenges to employing effective security is recognizing the adequacy of the security measures. Security is sometimes difficult to evaluate because you can’t prove that your security is 100 percent effective; you can only prove that it’s not effective (or rather someone else can prove it to you).

Related to this is the fact that it is difficult to determine the level and robustness of the security simply from using the application. A lot of security and a little security can look similar. For example, I can log on to my bank over an Internet-served web application to check my account balances, pay bills, and transfer money between accounts. I often wonder how the security is being done and how robust it is. The act of authenticating to the application does not imply that effective security is being employed to guard the data. I can also log on to my Yahoo account, where the information isn’t as sensitive as in my bank, but from my perspective the security appears identical.

Effective security requires a thorough understanding of not only how security works from a technical perspective, but also how the user community may try to defeat the security in efforts to make their job easier.

The security teams within organizations tend to be unpopular because they recommend things that tighten security, which is often inconvenient to the users. Security competes with other real-world desirable objectives besides usability such as performance, cost, and administration. Typically, as security increases, usability and performance decrease, and costs and administration increase. Overall, you must keep in mind that there are going to be trade-offs (probably not what you expected to read in a book dedicated to security).

Figure 1-1 represents the competing requirements. You can mark an “X” somewhere on the pyramid to represent your goal, or perhaps the reality, of where you have balanced the competing factors.

Figure 1-1: Balancing requirements

There are times when you’ll want to be flexible in your ability to move through the triangle. Perhaps in a time of crisis you might need to move from more secure to more usable, or from more performance to more secure. Ultimately, the goal is to shrink the triangle—that is, to achieve security and usability and performance. We will explore examples of this throughout the book.