Enhanced Protection Recommendations

The following recommendations require a higher level of administrative skills to implement and maintain on home networks than the previous recommendations. These recommendations provide additional layers of security but may impact your web browsing experience or require some iteration to adjust settings to the appropriate thresholds.

1. Enhanced Wireless Router Configuration Settings

Additional protections can be applied to the wireless network to limit access. The following security mechanisms do not protect against the experienced attacker, but are very effective against a less experienced attacker. 

a. MAC address or hardware address filtering enables the wireless access point to only allow authorized systems to associate with the wireless network. The hardware address for all authorized hosts must be configured on the wireless access point.

b. Limiting the transmit power of the wireless access point will reduce the area of operation (signal strength) of the wireless network. This capability curtails the home wireless network from extending beyond the borders of a home (e.g., parking lot or adjacent building).

c. SSID cloaking is a means to hide the SSID, the name of a wireless network, from the wireless medium. This technique is often used to prevent the detection of wireless networks by war drivers. It is important to note that enabling this capability prevents client systems from finding the wireless network. Instead, the wireless settings must be manually configured on all client systems.

d. Reducing the dynamic IP address pool or configuring static IP addresses is another mechanism to limit access to the wireless network. This provides an additional layer of protection to MAC address filtering and prevents rogue systems from connecting to the wireless network.

2. Disable Scripting Within the Web Browser

If using third party web browsers such as Firefox or Chrome, use NoScript (Firefox) or NotScript (Chrome) to prevent the execution of scripts from untrusted domains. Disabling scripting can cause usability issues, but is an effective technique to reduce web bourne attacks.

3. Enable Data Execution Prevention (DEP)

for all Programs By default, DEP is only enabled for essential Windows programs and services. Some third

party or legacy applications may not be compatible with DEP, and could possibly crash when run with DEP enabled. Any program that requires DEP to execute can be manually added to the DEP exemption list, but this requires some technical expertise.

How to create a Root Security Policy

In this section we will interactively start to draft your policies, beginning with the Root Security Policy and then working through a few of the others. Each policy sets out the definitive answer to a set of key questions.

The Root Security Policy

The first document you’ll draft is the “Root Security Policy.” This is also the easiest to write, as it is the framework which points to the other policy documents.

As you draft a Root Security Policy, you will also enumerate the initial list of subordinate policies that you should produce next.

Your list will be specific to your organization, but will probably include the following subordinate policies:

Computer Acceptable Use. A general document covering all computer use by employees and contractors, including desktop, mobile, home PCs, and servers.

Password. A description of the requirements for password protecting computer systems, the rules for choosing passwords, and how the password policy is enforced.

Email. This policy covers the use of email sent from any company email address and received at any company computer system.

Web. A specification of what browsers may be used, how they should be configured, and any restrictions on which sites employees can visit.

Mobile Computing and Portable Storage. A description of who owns the mobile computing and portable storage on your network, how they are supported, and what specific devices (if any) are authorized for use on the company network.

Remote Access. A policy stating who can access what information from which locations under what circumstances.

Internet. A description of your Internet-facing gateway configuration, stating what is allowed in and out, and why.

Wireless. A specification stating how wireless access will be managed on your network; how access points will be plugged in, secured, and maintained; who is allowed to use them; and under what circumstances.

Servers. A statement of the company standards for servers, what services are enabled or disabled by default, and important distinctions between production, test, and development environments.

Incident Response Plan. No policy is complete until it also specifies what to do when defenses fail: what is considered a security incident; who gets called; who is authorized to shut things down if needed; who is responsible for enforcing applicable local laws; who speaks for the company.

The Root Security Policy will also specify numerous easy-to-describe items, such as:

• The company name. Does this policy apply to your whole company, or a distinct division, office, or locale?
• The purpose of the policy. What is it for? What do you hope to gain by creating a policy?
• The individuals or organizations responsible for the policy. Who is responsible for overall network security? The head of the IT department? The information systems security officer? Some other executive? (Tip: In the drafting phase, you are allowed to write “To Be Determined.”) Eventually, you will also want a “Site Security Committee,” a small group of managers and technical people representing various user groups in the organization, including the HR department. This committee is responsible for maintaining the policy so that it is current and relevant.
• The scope of the policies. Make sure that you state what geographies, organizations, and assets you are covering. State explicitly which geographies, organizations, and assets the policy does not cover, as well.

The Root Security Policy should also briefly describe:

• Penalties for breaking policy. Determining this will probably require talking to upper management and the Human Resources department, but will almost always include words such as, “disciplinary action up to and including termination of employment.”
• Who enforces the policy. All managers and supervisors should be responsible for the administration and enforcement of the policy.
• Who must abide by the policy. All employees should be responsible for adhering to the policy. Will there be exceptions? Under what circumstances? Take the time to define an exceptions process, making sure that the process calls for periodic review of the exceptions.
• The other documents listed in the policy. The root policy forms the framework for the rest of the document. This entry can be as simple as a bulleted list or as detailed as a bibliography.
• How to request policy changes. There will and should be changes as the policy matures. Specify when and how changes can be made, and who can make them.
• How often your policies must be reviewed. For most SMEs, a year is too long to go without a policy review. Monthly reviews are too frequent. If you are not sure what interval to specify, start with “quarterly, or as needed.” (“As needed,” for example, might be after a request for a change, or when the requirements or the apparent threats change.)

How many pages will all this fill up? As many as it takes, but usually no more than two to five pages (initially) for the Root Security Policy, and one or two pages for each individual sub-policy. In school, you might have gotten used to padding your documents to meet some minimum page requirement. In security policies, follow the opposite route: brevity reads like wisdom.

Four Common Misconceptions done when creating a Network Policy for Business

1.

"The goal of network security is to secure the network" (or "the computers"). Securing the network is easy, but it's not your goal. Your real goal ― and a more difficult job ― is securing the business. The goal of network security is to support the network and computer business requirements, using methods that reduce risk. Security policies describe what you must secure, and the ways you secure them, to support your business or mission. Firewalls, intrusion detection systems (IDS), anti-virus (AV), backup and restore strategies, locked doors, and system administration checklists are all some of the things you might use. Security policies provide the blueprint for using them: the what, how, why, when, and by whom.

2.

"Security policies must be long and complex." In fact, just the opposite is true. We believe the well-known security axiom, “Complexity and security are inversely proportional.” Complex systems are usually less secure than simple systems. Complex policies are usually ignored; simple policies might live. A good security policy is really a set of documents, each addressing a specific need. By breaking your overall policy into smaller pieces, each managed separately, you greatly simplify the process of creating effective, consistent, relevant, and useable documents. This is not to say that the entire set of security policies will or should be just a few pages. But each individual element — each policy — should be usable by the target audience. “Usable” does not mean merely "understandable,” or even “readable” and “memorable.” It also has to take into account your corporate culture. So keep it real. Don't write academic tomes (unless that is your corporate culture). Write something your target audience can read and understand, in the amount of time their duties permit them.

3.

"Security policies have to be nearly perfect, or 100% complete." No. Good enough security now is better than perfect security never. For some reason organizations treat security as something sacred, when this is exactly the area where practicality should reign. There is not one right way to write a security policy. You are also allowed to modify it later. General George S. Patton said, “A good plan, violently executed right now, is far better than a perfect plan executed next week.” That is not to say that your goal should be to produce something shoddy or incomplete and call it “whole.” But it is perfectly fine to build security policies in parts, refining each part separately in the ongoing process of security policy development. Some parts will seem fully baked before other parts do. That's OK. That's how the process works.

4.

"Security policies only have to be written once." Until there are no more bad guys in the world and everyone agrees to mind his or her own business, the process of managing a security policy never ends. The threats your organization faces will change over time. As the threats to your business change, so too will your company’s business requirements. The vulnerabilities will change as well, and so will the risks you are willing to take to do business, and so will the tools you use to reduce or counter those risks. Because of all this, the security policy process is never really done. It only lies dormant for a time.

Data Execution Prevention (DEP)

Computer attackers commonly use buffer overflow exploits to gain access to computer systems. Many of these malicious code exploits can be prevented with Data Execution Prevention (DEP), a security feature available in modern operating systems. DEP provides protection for all memory that is not specifically marked as executable code. This guide discusses how to configure and enable DEP.

Enable Hardware Support for DEP

Most personal computers sold today include hardware support for DEP. Hardware support can be enabled or disabled by a BIOS setting. It is recommended that hardware support for DEP always be enabled. BIOS settings vary depending on the manufacturer, but the DEP option can usually be found in the Security section. When replacing older systems it is recommended to purchase systems with hardware support for DEP.

Intel® refers to its hardware support as Execute Disable Bit (XD), and AMD™ refers to it as the No-Execute Bit (NX).

Windows® DEP Settings

On Microsoft® Windows XP SP2, Windows Server 2003™ SP1, and Windows Vista™, DEP operates in one of four possible settings: AlwaysOn, OptOut, OptIn, and AlwaysOff. It is highly recommended to configure DEP to operate in either the AlwaysOn or OptOut setting.

AlwaysOn protects all applications without exception. This is the preferred setting but is not practical where DEP-incompatible applications are necessary.

OptOut is the next best option and is the default setting for servers such as Windows Server 2003 SP1. OptOut applies DEP protection to all specified in an OptOut list.

The final two settings are not recommended. OptIn is the default setting on clients such as Windows XP SP2 and Windows Vista and protects only core Windows components. AlwaysOff disables DEP.

The address space layout randomization feature in Windows Vista provides further protection and compliments DEP powerfully.

Enable DEP on Windows XP SP2 and Windows Server 2003 SP1

DEP can be enabled by modifying the system’s boot.ini file or through the Control Panel. The Control Panel cannot be used to configure the AlwaysOn or AlwaysOff setting. Both methods require Administrator privilege on the system.

To enable DEP through the boot.ini file, add one of the following flags to the end of each line in the [operating systems] section:

/noexecute=AlwaysOn

/noexecute=OptOut

Save the changes and reboot the system. These changes can also be made using the bootcfg.exe tool in Windows XP Professional.

To configure DEP using the Control Panel, launch the System Properties applet from the Control Panel. Select the Advanced tab, and then click on the Settings button in the Performance section. Click the DEP tab in the Performance Options window (See Figure 1). To select the OptOut setting, check the box labeled “Turn on DEP for all programs and services except those I select.” The system must be rebooted before DEP protection is activated.

Figure 1: DEP Configuration Window

Enable DEP on Windows Vista

Windows Vista does not use a boot.ini file. DEP can be enabled by modifying the system’s boot configuration database (BCD). To do this, execute either of the following commands from a command window with Administrator privilege, and then reboot the machine.

bcdedit /set nx AlwaysOn

bcdedit /set nx OptOut

DEP can also be enabled in the System and Maintenance section of the Control Panel. Click System 􀃆 Advanced System Settings 􀃆 Advanced tab 􀃆 click Settings in the Performance section 􀃆 DEP tab (See Figure 1). To select the OptOut setting, check the box labeled “Turn on DEP for all programs and services except those I select.” The system must be rebooted before DEP protection is activated.

Excluding Windows Applications from DEP Protection

Some legacy applications may not run on a DEP-protected system. All enterprise applications should be tested for DEP compatibility. If the vendor cannot supply an updated DEP-compatible version, the product can be excluded from DEP protection when the OptOut setting is selected.

Microsoft’s free Application Compatibility Toolkit can be used to create a Custom Compatibility Database file (*.sdb) to omit a program from DEP protection. The file can be easily deployed across an enterprise. 64-bit applications are protected by DEP by default and cannot be exempted.

Red Hat® Linux/Fedora™ Support

Red Hat Enterprise Linux™ version 3 update 3 and later, and Fedora Core 1 and later, provide DEP and address space layout randomization as part of the ExecShield feature. It is enabled by default. To verify, issue:

sysctl kernel.exec-shield

The expected output is 1. If the output is not 1, investigate /etc/sysctl.conf and startup scripts, to re-enable ExecShield. ExecShield provides hardware-enforced DEP even on older systems by using the code segment limit on all x86 processors. For further protection, install the kernel-PAE package to make use of the processor’s XD or NX feature.

Sun™ Solaris™ Support

Sun Solaris supports a non-executable stack on both SPARC® and XD/NX-capable x86 systems. To ensure this feature is enabled, add the following line to /etc/system:

set noexec_user_stack=1

Apple® Mac OS® X Support

Mac OS X on Intel processors supports DEP through the processor’s XD bit. It is enabled by default. To verify, issue:

sysctl kern.nx