Analyzing Your Security Needs to Develop Appropriate Policies
| When we mention to IT managers that they need a security policy, the question we almost immediately get is where to find a template policy. The problem with answering that question is that not everyone needs the same policy, or more correctly, polic ies . Everyone has different security needs. The first step in developing an appropriate security policy is to determine what your security needs really are. Risk ManagementIn the early days of computing, computer systems were mostly used in university labs and large military establishments. Today, with almost a billion personal computers out there, they are used everywhere. The key question to ask when determining your security policy is this: What is the value of the information and services you are trying to protect ? Not all information is made equal. In the United States, if someone fraudulently uses your credit card, by law (not necessarily by the initial request from the bank, however), you are liable for only $50. Based on that, it makes little sense for you personally to spend any more than $50 to protect your credit card number. However, if someone manages to get access to the CIA databases, it may seriously compromise the ability of the federal government to wage the war on terrorism, not to mention the lives of many field operations personnel"spies" to most people. The value of that information is obviously much greater than a simple credit card, and one should be willing to spend a lot more money protecting it. Ultimately, everything can be assigned a value, even things that we usually consider to be "invaluable" or qualitative in nature. People often ask how to assign a value to these types of things, such as a company's reputation and brand equity. In introductory business school courses, we are taught how to do analyses such as "brand equity goes down by 12 percent, which will result in sales decrease of 8 percent ." None of those things are truly meaningful, however. If a company has such a serious security breach as to significantly tarnish its reputation, the value is easy to assign: it is equivalent to the line entitled " stockholders ' equity" on the balance sheet. The other factor to consider is how much it would cost to clean up the mess. Obviously, government agencies have no market reputation to lose, but are accountable to GSA and OMB, so even to them this is meaningful. More interesting in the case of public agencies is how much taxpayer money it will cost to clean up the mess. When you understand the risks, and preferably, have a way to convert risk into monetary cost, you need to evaluate the likelihood of each risk actually occurring. You do this by analyzing historical behavior, learning about the types of threat and how they were exploited in the past. Your technical personnel should be able to help you out here in terms of figuring out how likely some risk is to actually come true. It may help here to generate a threat tree, which we discuss in Chapter 9, "Network Threat Modeling," to evaluate how likely a threat is to come true, given the prerequisites for that threat. After you have a likelihood and a cost per occurrence, you can calculate the annualized loss expectancy (ALE), as follows :  The ALE is important because it tells you how much money you should be willing to spend protecting against each risk per year. Obviously, spending more than the expected cost of the event is not desirable. Some people argue here that some events are so catastrophic that they will put the company out of business if they occur. In that case, the total cost of that event occurring multiplied by the likelihood should still adequately capture the seriousness of the event. If they do not, something is wrong with either the cost or the likelihood. None of these decisions in terms of risk management are easy to make, and the issues are very complicated. For larger organizations, you may want to consider retaining a risk management consultant to perform the analysis for you. For smaller organizations, try to focus on what is important to do what you need to do, and try to assign some value to it. Put yourself in the attackers ' shoes and think about what they want with your systems, how they would use them, and what damage that would inflict on your operations. Think about what legal and regulatory problems could be caused by a security breach. For instance, in California, just losing physical control of a laptop may require you to issue a notification following SB 1386. [4]
Developing the Right PoliciesAfter you have spent some time thinking about the types of risk you are subject to, you can start thinking about what types of policies you need. Interestingly, there are some reasonably good resources to look to here. ISO Standard 17799 gives a good introduction, albeit incomplete, to creating and evaluating security policies. TIP: Other handy resources related to regulatory and policy issues include the following: HIPAA
Gramm Leach Bliley
Security Check: Reducing Risks to your Computer Systems
Financial Institutions and Customer Data: Complying with the Safeguards Rule
ISO 17799
Governmental engagements
Sarbanes-Oxley 404 (for small companies that are subsidiaries of publicly traded companies)
International privacy Issues
EUROPA - Internal Market - Data Protection - Data Protection Guide
Security policies in general
Note that all links were current at the time the book was written. They may no longer be there. Keep in mind, however, that the 17799 standard is not only incomplete, it is also focused on large corporations and corporate auditors and may not make recommendations that are directly transferable to your environment. Another good resource to consider is the SANS Institute Primer to developing security policies (http://www.sans.org/newlook/resources/policies/policies.htm). Written by Michele D. Guel, who has spent many years working on security policy issues for Cisco, it is probably more directly applicable to many commercial environments than the ISO 17799 standard. Before you can continue, you probably need to start doing some threat modeling. Although you probably have a reasonable understanding of the resources you are trying to protect, you need to understand the threats to them. Chapter 9 may help you do that, but for now, we simply assume that you have some idea what threats you are up against. If you do, you can start deciding which policies you actually need. Almost every organization needs an acceptable use policy. Acceptable Use PolicyThe acceptable use policy (AUP) is probably the most important policy at each organization. It defines what is acceptable usage of organizational information systems and what is not. It will define what you can do with the systems, and what level of usage is acceptable for key resources such as e-mail, Web access, databases, files, and, of course, the systems themselves . You may not be able to take action against an employee for inappropriate behavior, such as using company computers to surf pornography, unless the AUP explicitly prohibits such behavior. The AUP is also important because it sets the framework for many other policies. For example, the AUP will state what kinds of responsibilities users are expected to take on when it comes to the protection of organizational resources. These can then further be refined in other policies such as a specific remote access policy, an e-mail policy, or whatever seems appropriate for the organization. Password PolicyAlmost all organizations must have a password policy (PP). Actually, just about all organizations probably should have two of them, a user password policy (UPP) and an administrator password policy (APP). The UPP defines what users must do with respect to passwords. It should set out that passwords must have a particular length, consist of some particular level of entropy, be changed regularly, not used on any other systems, and so on. (See Chapter 11, "Passwords and Other Authentication MechanismsThe Last Line of Defense," for more details on passwords and password policies.) Users who have administrative accounts on any system, however, are subject to different requirements. If at all possible, attackers forgo user accounts in favor of administrative accounts. In fact, when we do penetration tests, we rarely even bother cracking user passwords. We usually take them out of the password dumps. We typically do not need them because one weak admin password is all that is necessary. Therefore, it is reasonable to put further restrictions on administrative accounts, such as longer password requirements, prohibition on using the same password on your administrative account and your ordinary e-mail accounts, and so forth. The APP may actually be part of a larger administrator policy that also sets out important aspects such as the fact that administrative accounts should never be e-mail enabled, not shared across systems with different security requirements, and a number of other things that we cover later in this book. Remote Access PolicyMost organizations today provide some form of remote access for users. The remote access policy (RAP) needs to define what access is allowed and how it is to be safeguarded. It should define who has access, what resources they have access to, and when (if applicable). More important than either, however, is defining how to protect organizational resources while connected. As we cover in Chapter 7, "Protecting Your Perimeter," systems that connect via VPN or dial-up are effectively inside the perimeter and need to be protected as suchyet they are coming from outside the perimeter, often through shared cable ISPs and public wireless hotspots. Consequently, the RAP needs to define what a properly configured system that can be used for remote access must look like, including, if necessary, a provision that the organization may put the system into such a state if necessary. A few years ago, a federal agency tried to deploy a logon warning to a large number of systems. Unfortunately, the logon warning also spilled onto the dial-in pool. The result was that when users went to log on to their home systems, they were greeted with a dialog explaining that this system was the property of the U.S. federal government, that all misuse was illegal, and so on. Needless to say, this was not exactly appreciated by people who had spent hard-earned money purchasing these systems. The RAP should delve into some technical details, and will probably have a bit of overlap with the next policy, the antivirus policy (AVP), defining what kinds of antivirus protection is necessary on remote access systems. It may also be related to the perimeter protection policy (PPP) because, as we stated earlier, dial-in systems are part of the perimeter. Keep in mind here, however, that both the AVP and the PPP needs to be modified to suit dial-in systems. The same perimeter protection that applies to the data center cannot be used for dial-in systems. Antivirus PolicyThe AVP is deceptively simple. It has only three parts :
As with so many other policies, however, the devil is in the details here. None of these statements would be acceptable as a real policy. The real trick is how to make this happen, particularly item 2. The update mechanism needs to be different for servers than for clients than for roaming clientsthe latter of which may not be able to get to the corporate update servers at all times. However, this is the policy. The actual implementation is in the procedures stage where you describe how to do what you say you do in the policy. Information Protection PolicyOne policy that just about every organization needs is an information protection policy (IPP). The IPP defines how users should protect information. Sometimes this is a part of the AUP, sometimes the AUP is simply a framework for the IPP. Regardless, the information needs to be there. The IPP needs to discuss items such as the transmission, storage, use, and destruction of information. For example, one day back when one of us worked at home almost every day, my beloved and adorable wife was also working there. All of a sudden, she asked me to help her with a particularly tricky Microsoft Access query. I went to look at it, and she was having problems filtering the data. The result she got had 12,000 records in it. I looked at it and realized the records had fields such as First Name, Last Name, Social Security Number, and so on. I asked her what it was. She stated that it was the payroll database. I scrolled over and found Spouse Name , Dependents, Salary, etc. I asked her whether it was the entire payroll database, and she responded yes. Now, you have to realize that the laptop this data was on was running Windows 95, the original release of which would volunteer the username and passwordin clear text!to anyone who just knew how to ask nicely . Obviously, this system was nowhere near capable of protecting this type of information. I asked her whether she had the right to keep this data on her laptop, and she responded that there was no policy against it. This is exactly the type of problem that an IPP needs to handle! Clearly, this information is very sensitive, and the corporate servers where it lives are probably very well protected. Any time you are dealing with personally identifiable information (PII), you need to worry about protecting it. There are many different kinds of PII, and how to protect it is very dependent on the application, the type of information, and the regulatory environment in the geographic regions where the information generated, stored, used, and so on. An IPP needs to define what protective measures all PII, as well as other sensitive information, requires, regardless of where it happens to be at the moment. Information protection often requires labeling. We are used to the military model of labeling data: unclassified, sensitive but unclassified, secret, top secret, top secret with special compartments, and so on. However, data classification is also very useful in other organizations because it helps the data owner define what protective measures to apply. If the IPP defines the general characteristics of data in a particular class, as well as the protective measures that must be afforded such data, the data owner can be charged with applying the proper classification to his or her data. He or she can then refer to the policy to define how to protect the data. One last item that must be part of the IPP is a data and equipment disposal policy. Data and equipment disposal is a huge security problem in many organizations. Stories of extremely sensitive information leaking on disposed hard drives are legendary. After a particularly public such incident, the U.S. Department of Defense now requires all hard drives to be incinerated. That may be overkill in other environments, but the IPP should at the very least specify that some kind of data wiping tool should be used on the equipment prior to disposal. NOTE: It is not sufficient to reformat or just delete sensitive data on a system that is being decommissioned. These processes only remove the index entries and leave the data intact. Even defragmenting the drive afterward, or formatting several times, is not sufficient to stop even casual snoopers. It is imperative to run a true wipe tool, such as PD Wipe or CIPHER /W, on the system before disposal. If this cannot be done, remove the drive and turn it over to a reputable data-disposal company for destruction. For information on what can happen when hard drives are not disposed of properly, see http://www.computer.org/security/garfinkel.pdf. Wireless Network Access PolicyThe advent of wireless networking has necessitated a new policy, the wireless network access policy (WNAP). This policy must spell out not only who can have wireless access, but also the system requirements to get it. It mandates what kinds of authentication mechanisms are used to get on to the wireless network, and whether a user is allowed to hook up an organization-owned system to other wireless networks such as public hotspots or home networks. It would also be appropriate to define how such networks must be configured and list some resources to make it possible for users to build those protections into their home networks. Finally, the WNAP should specify that no nonsanctioned access points are allowed and what happens to the person who installs one. (Hint: This needs to include where to pick up the last paycheck, because they should no longer be allowed inside the organization's walls after installing a rogue access point.) It is actually possible to run a protected wireless network, but the policy needs to define what is acceptable in the organization. Other Important PoliciesThe policies outlined so far are the basic set of user facing policies. A number of other policies may be of interest in most environments, but do not need to be distributed to the general user population. These policies are primarily designed for the IT personnel and system administrators. They should only be distributed to those people who need them. Perimeter Protection PolicyThe PPP defines what the perimeter protection devices should look like, what they should block, and what they should allow. The PPP also should lay out the exception policyin other words, what needs to happen to get an exception to the PPP for a particular application. Invariably, developers will eventually come and ask for a removal of some level of perimeter protection because that pesky firewall keeps getting in the way. The PPP is the document that states what exceptions may be allowed, and what needs to happen to do so. Without a PPP to lean on, you run the significant risk of your developers turning the perimeter into Swiss cheese. Also be aware of the Universal Firewall Traversal Protocol (UFTP, a.k.a. HTTP). If the perimeter gets in the way, developers and even system administrators will eventually try to shovel all traffic through one of three ports: 80 (HTTP), 443 (HTTPS), or SSH. At this point, you are no better off than you were before. In fact, you are probably worse off because instead of one well-defined port that you can control, you now have traffic flowing through an application layer designed for something else and your firewalls can no longer inspect the traffic. Frankly, you would have been more secure had you been able to control this at the ports rather than at the application layer. At a minimum, the PPP must define what ports should be open , to which type of hosts , and how to obtain a change in the perimeter settings. Not all ports need to be open indefinitely. The final part of a PPP should describe the decommissioning process that you will follow when an application no longer requires an opening in the firewall. Without this process, over time your firewall will come to resemble a piece of copper wirebut perform not nearly as fast. Direct Tap PolicyMany organizations have some form of direct tap policy (DTP). Sometimes it is part of the PPP. A direct tap is a network port that is directly on the Internet, without going through the ordinary firewalls. For some business applications, a direct tap can be very useful. It is also an obvious security hazard if it is routed illegitimately into the corporate network. The DTP defines the business justifications that must be presented to receive a direct tap, and the protection measures that must be in place once you have one. It obviously needs to only be distributed to the people who have direct tap or who want to get one. Among other requirements, the DTP typically prohibits dual-homing between direct taps and the corporate network. System Sensitivity Classification PolicyAs we discuss in Chapter 8, "Security Dependencies," and Chapter 9, "Network Threat Modeling," even in a single organization not all systems carry the same sensitivities. For example, a domain controller is much more sensitive than a laptop. It is often useful to create a system sensitivity classification policy (SSCP) to help system owners classify systems, just as we do for information. Obviously, the types of information processed on the system has a lot to do with how sensitive the system is, but there are other factors as well, such as what services the system provides, how critical those services are to the organization, the impact of a breach of a particular system on a set of other systems, etc. At the very least, you need a multilevel classification system for servers. The following represent class examples:
This policy will be very helpful in later chapters in which we do threat modeling to define the sensitivity of systems. Chapter 8 describes the need to create a matrix of these levels with the relationships between systems so that we can compartmentalize the systems. Physical Security PolicyThe physical security policy has two parts, one which all organizational stakeholders need to read, and one which applies only to certain sensitive systems. The general part should define who gets into your buildings , how they get in, what they are allowed to carry in and out, and how to handle visitors . The other part covers things such as how to protect the wiring closets, who has access to them, how to configure server rooms, what physical security devices are present, and so on. These policies are critical for many reasons. Some are relatively obvious. Later chapters discuss how all information security will fail if adequate physical security is not provided, but these policies also need to cover other, more mundane issues. One time, a system administrator (not us!) was asked to baby-sit another employee's dog while that employee ran some errands. Eventually, the system administrator had to go to lunch, and locked the dog in a closet for the duration. This was not a bad idea, had the closet in question not been the wiring closet! When the admin came back from lunch , the entire network was down. After spending about 15 minutes ascertaining that this was indeed the fact, she realized that the dog was still in the closet and went to let it out. That is when she realized that the dog was a very happy pooch, despite its current predicament, and the constant tail wagging during the brief period of incarceration had ripped every single network cable out of the punchdown panel! The admin ended up spending the rest of the day reconnecting everything. It may not be a bad idea to have a physical security policy that bans domesticated animals from being incarcerated in wiring closets! |
EAN: 2147483647
Pages: 219