Objective 1.1: Analyzing Business Requirements for Security Design

While it might seem self-obvious, it s important to begin any security design process with one simple question: Why? Why has your organization hired or contracted with you to design their security infrastructure? What goals do they hope to achieve by implementing a security design framework? As you work through this chapter, always keep that fundamental Why? in the back of your mind, since a security design plan that does not meet an organization s requirements for securing its data and resources is hardly worth the paper it s written on.

Organizations will make an investment in network security to protect their data and resources, or assets , from anything that might damage those assets, or threats . A company s assets can include physical inventory such as server hardware and software, and intellectual property such as the source code to an application or a trade secret. Moving beyond that, most (if not all) companies would consider things such as their business reputation to be an asset as well. With so many choices in doing business today, many consumers base their business and purchases on their confidence level in a corporation, and a company s reputation being tarnished by a highly publicized security break-in can destroy that confidence and cost a company sales and customers.

It s relatively simple to assign a dollar value to a piece of equipment or real estate; any loss in this area is called a quantitative loss. Threats to things like intellectual property and reputation are far more difficult to nail down to a hard-and-fast number, so losses in this area are referred to as being qualitative . A network security design plan will use Risk Management (discussed later in this chapter) to assign priorities to different types of network threats, and use that prioritization to develop an effective and cost -effective security design for an organization. By combining an understanding of your company s current security procedures with knowledge of the types of network threats it might face, you can design a security framework that will meet your company s needs.

Objective 1.1.1: Analyzing Existing Security Policies and Procedures

Corporate security policies create a baseline for performing security- related duties in a systematic and consistent fashion based on your organization s information security requirements. In many cases, these policies will extend beyond the borders of the IT department and involve areas of Human Resources, Finance, and Legal departments attempting to address compliance and reporting issues specific to a given industry. Having well-developed security policies will also assist an organization in demonstrating its security consciousness to customers, stockholders , and the like. Security policies typically fall into one of three categories:

• Physical policies While physical security can often be overlooked by IT professionals, these policies discuss security measures that can be implemented using physical controls such as door locks, controlled room access, and procedures for adding or removing equipment from a machine room or office.

• Technical policies These are the kinds of policies that you will be most familiar with as a Windows administrator. Technical policies include security measures that protect data and resources at the operating system level, including security templates and NTFS permissions.

• Administrative policies These are typically procedural measures that control facets of information security that can t be enforced through technical measures, such as a nondisclosure agreement.

When designing a plan for securing a Windows environment, your first step should be analyzing any existing security policies and procedures with an eye to how they can be improved (or, if necessary, replaced ) to meet the security needs of your organization. You should keep in mind some common reasons why security policies either fail or are not implemented properly within an organization. If users are unaware of security policies, the odds that they will comply with them are slim indeed ”a policy that no one knows about is no better than not having any security policy at all. Security policies also run the risk of becoming outdated or too difficult for an end user to understand; try to keep the technical jargon to a minimum when explaining your users rights and responsibilities within your security design plan. While creating and analyzing documentation might seem a tedious task, the existence of viable security policies can save both time and money when tracking down and addressing any security incidents that might occur on a corporate network.

Acceptable Use Policies

A common component of many enterprise security policies is an Acceptable Use Policy, often called an AUP. This means precisely what it sounds like ”an AUP is a document that details the types of activity that are (and are not) permitted on a corporate network. Since many network security incidents arise from risks or situations created by internal employees , an AUP is crucial so that a corporation will know that a violation of network security has occurred, and what steps they should take to address the situation. (Consider the potential implications, for example, of an internal employee running a network scanner like Nmap to discover vulnerabilities on corporate machines, whether out of curiosity or maliciousness.) An AUP needs to address the rights and responsibilities of both employee and company in defining what type of network access is acceptable on a corporate network, and what steps the IT department will take to determine whether a violation of Acceptable Use has occurred.

The AUP is also an appropriate place to discuss what level of privacy an employee can expect on a corporate network. While many companies hold that reasonable personal use of resources like e-mail and Internet access are allowable , you need to specify whether things like network traffic and e-mail messages will be subject to monitoring. This is even more pertinent if your organization uses encryption to secure documents, since users need to understand what circumstances, if any, would require a member of management or IT to access their encrypted files or other personal encryption information. Consult a legal resource when creating or assessing an AUP, since privacy laws often vary from location to location. (We ll have more on privacy and its implications for network security in the next section.)

Privacy versus Security

According to the Microsoft Security Resource Kit, privacy can be best defined as freedom from the intrusion of others in one s personal life or affairs. Privacy and security are related topics, but are not synonymous: information security is concerned with protecting sensitive information from anyone who doesn t have appropriate access to it, while privacy is more of a customer-centric concept concerned with meeting a person or organization s preferences for how information concerning them should be handled. Aside from the privacy concerns of employee information that we discussed in the last section, your company needs to be concerned about how it will handle and protect things like customer information and sales data. A common application of this is the disclaimer you ll see on many Web sites stating that lists of e-mail addresses will not be sold or distributed to other companies as marketing material, or options for consumers to opt out of receiving any directed marketing mailings . The terms under which your company will contact its customers need to be strictly defined and adhered to, if for no other reason than that it will improve your relationship with your customers. (You ll do far less business with those people who decide that any e-mail from you is SPAM, after all.)

From a legal standpoint, privacy concerns are some of the most highly visible within information security today. Laws as old as the U.S. Federal Privacy Act of 1974 limit how the government can use peoples personal data and information. More recently, industry-specific measures such as the Health Insurance Portability and Accountability Act (HIPAA) provide more stringent measures to control how your health and medical information can be processed , stored, or transmitted to prevent inadvertent or unauthorized disclosure or misuse.

Within private industry, organizations need to examine the privacy of their own information and assets, even if it s not mandated by legal regulations. Most companies, especially those that do business online, have created Privacy Statements that delineate what type of information a company will be collecting ”are you tracking IP addresses? Referring sites? Machine data? All of these things should be specified in a Privacy Statement. Moreover, the Privacy Statement should clearly define how a customer s personal information will be used, and what other organizations, if any, will have access to this information. Your company s Privacy Statement should also detail how users or consumers can opt out of having their personal information shared or even stored at all if they change their minds at a later date. Finally, you should detail the information security measures that will be used to protect customer data, and be sure that the systems you implement will be able to measure up to the standards that you ve laid out.

As a final note when considering your company s privacy policy, remember that IT and security professionals themselves can sometimes introduce risks to the privacy of information because of their nearly unlimited access to network data and resources. While we would like to think that all IT professionals have integrity, security professionals themselves should be aware of and subject to privacy measures to ensure the integrity of customer data.

Security versus Usability

Of primary concern when analyzing security policies is the need to balance security with usability ”if your security policies are so stringent that your users are not able to access their data, then you haven t really designed a functional security scheme. While we all want to design the most secure network environment possible, mandating measures like a 20-character password will, in most cases, simply lead to administrative overhead and user frustration as they continually forget their passwords or need to have them reset. (And such a measure could actually decrease security by encouraging the dreaded Password on a yellow sticky note next to the monitor phenomenon .) When surveying existing documentation (or creating your own), always keep this balance between security and usability in mind.

Objective 1.1.2: Determining Requirements for Securing Data

No matter what kind of data you are dealing with, your task as a security professional is to ensure that it remains accessible, intact, and private. When securing data, a common phrase that you should be familiar with is CIA , which stands for Confidentiality , Integrity , and Availability . Taken as a whole, these are the three most important areas to consider when attempting to secure your network s assets and resources. The CIA triad makes up all of the principles of network security design. Depending on the nature of the information you re securing, some of the principles might have varying degrees of importance to you. However, all three will come into play at some point during the design process.

The CIA Triad

Confidentiality prevents any unauthorized disclosure of your data, and ensures that information will only be available to those people authorized to access it. Confidentiality is crucial when dealing with matters of privacy and protecting personal data such as credit card information, Social Security numbers , or other unique identifiers. It s also a critical matter when attempting to secure the kinds of intellectual property that we ve already discussed: once a piece of secret information has been disclosed, there is no real way to un -disclose it. However, determining the confidentiality of data is not only a matter of determining whether a piece of information is secret. When considering confidentiality, you also need to control how data can be accessed. For example, a sales representative using a database query to generate a list of follow-up customer service calls would not be a breach of your data s confidentiality. However, that same sales representative querying the same database for a list of e-mail addresses to use in her own personal mass e-mailing would be another matter entirely. Therefore, the confidentiality of data depends not only on who can access it, but how they are doing so.

To prevent attackers from gaining access to you network s confidential data, you can use any number of technical, administrative, and physical countermeasures. Physical controls can include a secure safe-deposit box to house items like birth certificates or medical records. From a technical standpoint, users might only be allowed to access confidential data from a specific location, or by using a specific application. The use of cryptography and file encryption can ensure that only the owner of a file can access it, even if it is somehow transferred to a different location. In addition, end-user and administrative training can guard against an attacker using a so-called social engineering attack to obtain access to an employee s username and password. (More on social engineering in a minute.)

The next item in the CIA triad, integrity , refers to measures that preserve the accuracy and consistency of data against fraudulent or unauthorized alteration. Data integrity safeguards should ensure that only authorized persons are allowed to make changes to network data. Protecting data integrity also means making sure that authorized users cannot make unauthorized changes to corporate data ”while a bank teller should be authorized to view your checking account information, he certainly shouldn t be able to transfer monies from your account into someone else s without your approval.

Test Day Tip  

Confidentiality of data is concerned with who can see a piece of data. Integrity moves into the question of who can modify that data.

Mechanisms that are designed to ensure data integrity need to address both attacks on where data is stored, and while data is being transmitted across the network. If an attacker intercepts and changes data traveling from a server to a user s workstation, it is just as detrimental as if the attacker had altered the data on the server hard drive itself. It s important to note that not all attacks against data integrity are necessarily malicious; users can enter invalid data into an application, or an application error can cause an error in processing. (If anyone remembers the Monopoly game card that read Bank Error in Your Favor, Collect $100, you have a good idea of this type of integrity failure.) Data integrity safeguards should protect against any type of integrity attack, whether intentional or innocuous . This can include administrative safeguards such as user training about the importance of accurate data entry, or technical controls in applications to ensure that 2+2 always equals 4, or to flag any unusual transactions for manual approval in case they were the result of an error. Some of the protections that can be used to prevent more malicious integrity attacks include the use of Intrusion Detection Systems (IDSs), data encryption, and the use of access control through the NTFS file system.

The final piece of the Information Security Triad is the availability of data. Just like the old question of whether a tree falling in the forest with no one around actually makes a sound, if your users cannot access their data when they need to, then any measures that protect that data s confidentiality and availability are hardly worthwhile. The recent spate of denial-of-service (DoS) attacks on the Internet have been designed to infringe on the availability of Internet-based Web services, sometimes affecting a company s network access altogether.

Data availability can be affected by more than just network attackers and can affect system and network availability. Environmental factors such as adverse weather conditions or electrical problems, and natural disasters like fires and floods can prevent systems and networks from functioning. This is why backup and restore and disaster recovery planning should be included in any network security design plan. (We ll talk about backup and restore processes in Chapter 4, Securing the Network Management Process. )

Objective 1.1.4: Analyzing Current Security Practices

A step that is commonly overlooked in designing any network is examining where a company or network is at currently. Evaluating a company s existing security infrastructure will illustrate where any gaps or holes currently exist that need to be addressed by the new security design; it will help you determine how much actually needs to be changed or updated, rather than wholly reinventing the wheel. If the organization is already security-conscious, your security design might only require minimal updates to reflect new advances permitted by Windows Server 2003 security technologies. If there is no security infrastructure currently in place (or if the current security practices are not being enforced), however, you obviously have a whole different task ahead of you. This task includes securing the corporate network, and crafting procedures and policies that will be embraced by management and users alike.

Your evaluation of current security practices should extend not only to administrative policies issued by IT or Human Resources, but also any technical measures that are already in place or lacking. For example, do all users have administrative rights to their local workstations? This might require re-examining to better secure the workstation environment. Are there measures in place that prevent users from downloading or installing unauthorized software? Developing an awareness of the security practices of your organization will help you determine the best way to design a Windows Server 2003 infrastructure.

Using Resultant Set of Policies

If you are working with an existing Windows Server 2003 infrastructure, you might find that there are already technical policies in place that you need to analyze before designing a solution. Windows Server 2003 offers a new tool that will assist you in listing and troubleshooting any existing security settings on a network that have been applied through Group Policy Objects (GPOs). Resultant Set of Policies, or RSoP, is particularly useful in determining how existing GPOs have been applied, and determining which settings have or have not been applied to a specific user or group of users.

You ll use the RSoP Wizard to create a query that will list all GPO settings, security and otherwise , for a specific user or computer. You can access this wizard from a blank Microsoft Management Console (MMC), or from the Group Policy Management Console. When the wizard has completed, it will display its results in the MMC window. You can then save, change, or refresh the information used to generate the query. In Exercise 1.01, we ll examine the steps in running an RSoP query against a single computer.

Test Day Tip  

If you need to create RSoP information for a number of different users, you can use the gpresult.exe command-line utility in a batch file or logon script. The gpresult utility was previously available under Windows 2000; however, RSoP is a new feature for Windows Server 2003.

Exercise 1.01: Running an RSoP Query

1. Open a blank MMC by clicking on Start Run , typing mmc , and clicking OK .

2. Click on File Add/Remove Snap-in . Select the Standalone tab, click on Add , then browse to Resultant Set of Policy. Click on Add again and then Close .

3. Click OK to return to the MMC.

4. Right-click on the Resultant Set of Policy node and select Generate RSoP Data as shown in Figure 1.1.

   
   Figure 1.1: Generating RSoP Data

5. Click Next to bypass the initial Welcome screen.

6. On the Mode Selection page, click Logging mode , and then click Next .

7. The Computer Selection screen (shown in Figure 1.2) will give you the option to generate data about the computer where you re running the RSoP snap-in or to select another computer on the network. You can also place a check mark next to Do not display policy settings for the selected computer in the results (display user policy settings only) to restrict the output of the query. Click Next when you re ready to continue.

   
   Figure 1.2: Computer Selection in the RSoP Query Wizard

8. The next screen is the User Selection screen. Similar to the screen in the previous step, you can generate the RSoP query based on the currently logged-on user, or select another user in the Active Directory database. You can also restrict the results of the query by selecting Do not display policy settings for the selected user in the results (display computer policy settings only ).

9. The final screen will display a summary of the choices you ve made. Click Next to begin the RSoP query. Click Finish when the query has completed.

 

After you run the Resultant Set of Policy Wizard, the RSoP console will be populated with data from the results of the query. The specific results for Software Settings, Windows Settings, and Extra Registry Settings will appear in the right-hand side of the MMC window.

Security Settings information will display each specific policy, the effective setting that has been applied to a given computer, and a Source GPO column indicating which GPO applied this setting. (This is particularly helpful if you have multiple GPOs on a network and are attempting to determine how GPO inheritance is structured.) The Source GPO column indicates which Group Policy objects affect a policy setting, as illustrated in Figure 1.3.

Figure 1.3: Results of RSoP Query

Using tools like RSoP will assist you in analyzing any technical security measures that an organization has already put in place, along with its existing administrative policies. Armed with this information, you will be able to assess the organization s current security policies, with an eye toward what might need to be changed to better protect against both internal and external attackers.

Recognizing Internal Security Threats

So, why is it so important to determine how an organization handles security for its internal users? Because in many ways, internal security threats from employees, contractors, or other sources can be even more damaging than external hack attacks. This is because internal users have several factors working in their favor when they do damage against a network, whether unintentionally or maliciously. Internal users have far more opportunity to gain physical access to networking and computing equipment, even if it s just their personal workstation connected to the network LAN. Once an attacker gains physical access to a computer, most security safeguards become a simple matter to circumvent. If internal resources such as server rooms and wiring closets are not locked or secured in some way, the potential for damage increases exponentially. Additionally, if a company does not encrypt network traffic, it is a simple matter for an internal user to eavesdrop on network traffic to gain access to information that he should not actually have access to.

Moreover, internal users usually do not need to break into a network, per se , since they already have access via their username and password. This initial access to a corporate network gives any internal attackers a great advantage over their external counterparts, since the task of finding valid logon authentication to a network has already been handled for them by the network administrators. Especially if the attacker is someone with legitimate administrative privileges, it can be extremely difficult to determine if she is abusing her network credentials for illicit purposes.

Increasing Security Awareness

As a part of any security design plan, you should include measures that will provide security training for both IT and non-IT personnel within an organization. Since most people are resistant to change for its own sake, security awareness training is always helpful to bring people on-board with any new or changed security requirements or procedures. You might find that some users are not following security practices or introducing vulnerabilities because they do not know about their responsibilities in securing the corporate network. Users should be aware of security measures available to them such as file encryption, what makes a complex password better than a weak one, and the importance of physically securing resources like portable computers, PDAs, and the like. You should help your users understand when it is and is not appropriate to discuss their network logon information, and that they should under no circumstances share their password with anyone, even someone from (or claiming to be from) IT. Security Awareness Training is perhaps the only measure that will help to address nontechnical attacks like social engineering, which rely on cooperation from unsuspecting users to gain access to a network.