Objective 2.3: Securing the Network Management Process

The problem of implementing security in networks lies in the fact that you are always defending against attacks and you are defending against an enemy you don t know, don t see, and can t predict. As an administrator, you need to protect every aspect of your network to prevent an attack, whereas an attacker only needs to find a single opening to gain malicious access to your resources.

On the physical network, your first priority is to restrict access to the network perimeter with a firewall or through some kind of secure communications, such as a virtual private network. Once you re within the network itself, you ll use administrative tools to create a file-and-folder permission structure that will restrict unauthorized access to your data by any internal users. You ll also secure your user accounts by creating strong password policies and auditing user access and actions through the Group Policy Editor.

But what about the actual tools that you re using to perform these tasks ? The very tools and utilities that you use to administer your network can create a huge potential for misuse, allowing malicious attackers to gain administrative access to a machine or an entire network. Imagine what could happen if an attacker gained access to the DNS Management MMC snap-in: They could create, delete, or modify host entries to redirect your clients to malicious or compromised Web hosts , and they could view your DNS registrations to obtain a complete picture of your network to use for further attack. Or think about a malicious user finding a way to use DHCP Manager to change scope information, removing or changing address assignment information and rendering your clients incapable of accessing network resources. In perhaps the worst-case scenario, consider the potential damage if an attacker obtained administrative access to the Active Directory Users and Computers utility; at this point they would have carte blanche to create and delete user and computer accounts, change group information, and otherwise entirely compromise your user account database.

Because of this potential for misuse, you should always set security guidelines and policies on how your network should be administered. Windows Server 2003 allows you to implement role-based administration and enforce many security guidelines and policies using Group Policy and Delegation of Administration, as we will see in the upcoming sections of this chapter.

Objective 2.3.1: Managing the Risks of Network Administration

When a company experiences period of growth and expansion, it often adds more IT staff in addition to infrastructure such as servers and networking equipment. There will probably be situations in which administrators are hired to do specific tasks, or they could be less experienced administrators who aren t strong in all aspects of the network management process. For this reason, you don t want to grant all your administrators the same level of administrative rights, because if an administrator or engineer is unfamiliar with a particular technology, he or she may introduce a security risk to your network by either exploring the network out of curiosity or by failing to ask for help performing a particular task. For example, if you hired a new network administrator who has never worked with DNS before, but you place no restrictions on that person s authority to administer your company s DNS server, he or she may cause as much damage to your DNS records due to a lack of knowledge as any malicious attacker. However, if you have delegated administration and management policies in place, you will be able to better control the authority held by various members of your administrative staff. Another reason that you want to implement this kind of security is to protect your network against actively malicious administrators seeking to harm a network. Having a network management policy in place will also help you secure your network against your own IT staff, if such protection becomes necessary.

As you can see, the network administration process itself can become a threat to the security of your enterprise network if you do not take steps to design a secure model for network management. If this model is weak or nonexistent, you can introduce vulnerabilities stemming from user accounts that possess excessive administrative rights (as in the scenario just mentioned), or the lack of a framework or stated policy can cause your organization to make poor decisions regarding information security, such as failing to run any kind of background or reference check on someone beginning work as a network administrator.

Network administrators can also be vulnerable to social engineering attacks because of the elevated privileges and permissions that they hold on a network. Say that an attacker obtains the telephone number to your help desk and calls pretending to be the personal assistant to the vice president of sales. The caller says that this VP is going into a meeting and needs his password reset right away, or it s going to cost the company a large account because he won t be able to give his sales presentation at the meeting with the big client. If your help desk has no policies in place to verify this caller s identity, the help desk staff may reset the password as requested , since most people really want to be helpful and don t want to get themselves in trouble with a VP. Using this kind of social engineering, the attacker has now obtained a valid password for the VP s user account, which he or she can now use to infiltrate your network. Having policies in place will not only inform administrators about what actions they should take in situations like this ”it also lets your users know what is expected of them ”in other words, no matter what their position in the company, they will be required to go to the help desk in person to have a password reset, or whatever is the appropriate policy for your organization.

Test Day Tip  

Remember that a social engineering attack is one that uses nontechnical means to obtain information about or access to your network. This can take the form of an attacker trying to impersonate someone over the phone, posing as a contractor to gain entry to a server room, or otherwise deceiving technical or nontechnical personnel into revealing information, running malicious applications, and the like.

Security Policies for Administrators and IT Personnel

You ll use a network management policy to specify ways to manage your enterprise network in a secure manner. As we ve just mentioned, improper use of management tools can create just as many security vulnerabilities as the behavior of any misbehaving user or malicious attacker. Because your organization needs to trust its administrators to use their authority in a responsible fashion, you ll need some type of policy in place to regulate the people who can possess administrative rights and be able to manage network resources such as file resources and infrastructure services. A security policy will also ensure that administrators manage your network resources securely and are themselves protected against attackers when they use their administrative privileges. A properly defined network management policy includes a detailed explanation of the tools for managing a network, a list of users or user groups who can manage the network, and appropriate procedures for managing network resources.

An example of a technical means of controlling the administration process would be implementing Group Policy on an OU where user accounts reside. This Group Policy Object (GPO) might prevent certain administrators creating their own MMC consoles and force them to use only the tools to which you have given them access through a customized MMC console. To further tighten and harden this security model, you can even explicitly allow or deny access to MMC snap-ins through Group Policy so that if the administrator were able to access an MMC console in author mode, the only tools he or she would be able to add would be those that you have explicitly given them access to.

Another piece of the security policy puzzle is less amenable to technical controls and revolves instead around administrative policies for the way your network should be administered. This includes a certain amount of due diligence and care in how administrative credentials are used, creating a second everyday account and performing administrative tasks using the RunAs function. This diligence also extends to performing security functions in a timely manner, including disabling accounts of former employees and changing administrative and service account passwords on a regular basis. Finally, your administrators should be aware of the tools that are acceptable for use in managing a network, and they should be aware of the most secure way to use each of them. We ll discuss several of these utilities in upcoming sections.

Delegating Authority Securely

Because any organization needs to place as much trust in its network administrators as it does in its financial, human resources, or legal personnel, when securing your network management model it s important that you take the greatest care in selecting those individuals. This becomes even more critical for individuals who possess far-reaching administrative rights, such as those assigned to the Domain Admins or Enterprise Admins groups. At a minimum, you should perform some type of background or reference check on any new IT personnel you interview. Once they are in place, they need to be educated ”not only on the technical aspects of the tasks that they ll be performing, but in how to comply with any company or industry policies and regulations to maintain security.

When you get down to the technical aspects of delegating authority over portions of the Active Directory tree, remember that best practices suggest that you divide administrative duties among your IT staff so that they have enough permission to do the task they were hired to do, but not an excessive amount beyond that. This is another application ”the least privilege concept, which refers to granting users (in this case, administrators) the least amount of rights and permissions possible and then relaxing the permission structure only as a specific need arises. Once you begin to delegate administrative rights to other staff members, you should also create and maintain an audit policy that includes monitoring network administration activities so that you can be sure that administrative tasks are being performed correctly and appropriately.

Within Active Directory itself, you can structure your delegation strategy based on roles. For example, let s say that you have both Web and application servers in your organization, and each of these server types has its own team of administrators. You can group your Web servers into a single OU and then delegate administration of this OU to the Web servers administrators. You can then do the same for an Application Servers OU. The result would be that the Web servers and application servers administrators would be able to perform administrative tasks only within the scope of their respective OUs. You can lock this down even further using predefined MMC consoles that will restrict the tasks administrators can perform, even within the OUs over which they have authority. By implementing a model like this, you create additional layers of security for your network (sometimes referred to as defense in depth ), so if an administrative account in one OU is compromised or if an administrator were to decide to wreck havoc on the network, the scope of any damage would be isolated to the OU that the specific administrative account has been delegated to manage.

In Exercise 4.01, we ll create a new OU within a Windows Server 2003 domain, then delegate the ability to manage user accounts to a user within the OU.

Exercise 4.01: Creating an Organizational Unit and Delegating Control to a Local Administrator

1. Open Active Directory Users and Computers .

2. Right-click the domain, then select New Organizational Unit . Enter a descriptive name for the OU and click OK .

3. From the MMC console, right-click the OU that you just created. (Press F5 to refresh the console if you don t see the new OU listed.)

4. Click Delegate control to start the Delegation of Control Wizard.

5. Click Next to bypass the introduction screen.

6. On the Users or Groups screen, click Add to specify the users who should have the administrative rights you specify for this OU. Click Next when you re ready to continue.

7. In the Tasks to Delegate screen shown in Figure 4.1, you can either select one or more preconfigured tasks to delegate or create a custom task. In this example, we re going to delegate the ability to Create, delete and manage user accounts . Make that selection and click Next to continue.

   
   Figure 4.1: Using the Delegation of Control Wizard

8. On the Summary screen, review the selections you ve made, and click Finish to complete the delegation process.

 

Designing & Planning
Putting It All Together: Designing the Network Management Policy

So you ve taken on the administration of a network for which the management policy is ad hoc at best, nonexistent at worst. Where do you start when you have to start from scratch? Understanding the steps in creating a network management design will be a useful tool, both for the 70-298 exam as well as in the real world.

Your first step should be to determine how your network is (or is going to be) managed. This management model could be a centralized one, where administration is performed by a small group of administrators, usually at a single location. This type of network management provides a great deal of security at the expense of a certain amount of flexibility. (Think of the groans from remote sales offices when they need to call corporate to get a password reset or set up a user ID for a temporary employee.) At the opposite end of the spectrum is a decentralized management model, in which different management tasks are performed by smaller, often geographically distant administrative groups. This provides more flexibility than a centralized model, but you need to be careful that each group s autonomy doesn t negatively impact the overall security of your network.

Another option for network management is outsourcing , whereby a third party (perhaps a management firm or an individual consultant) handles all your network administration needs. You ll see this most often in smaller companies that don t need (or can t afford) to have IT administration on site full time, but this model has also begun cropping up even in large-scale organizations that want to completely concentrate on their company s products or services and leave administrative tasks to the experts. Obviously, the model you choose is unlikely to fit neatly into one of these categories and will be a combination that best suits your needs.

 

Objective 2.3.2: Securing Common Administrative Tools

All the security in the world can t help if the tools at the administrator s disposal are not properly secured. These tools are designed to allow you to make major modifications to and troubleshoot your network; if these tools fall into the wrong hands, they can be used to damage and interrupt business productivity in your organization. Inappropriate use of network management tools (either by administrator themselves or by attackers gaining access to them) can reveal administrative credentials and other sensitive information about your network. Securing the network management process involves a delicate combination of managing people, technology, and policy; a well-designed plan takes each of these areas into account to ensure that the network remains secure.

Microsoft Management Console

The Microsoft management Console (MMC) is not an administrative tool itself, but it provides a framework for various utilities called snap-ins to manage various pieces of the Windows Server 2003 network. You can load a single snap-in into an MMC console or create custom consoles containing multiple management utilities. Some organizations allow administrators to load and use any snap-in that they want. This can create security issues, however, in that any attacker who was able to gain administrative access to the MMC would be able to launch any available utility and wreak havoc on the entire network as a result. Security best practices call for creating custom MMC consoles for administrators that contain only the utilities they need and restricting access to those utilities that they don t need. You can do this by building custom consoles and locking them down by removing the Author Mode option, which allows users to add and remove snap-ins. You can enforce these types of restrictions using Group Policy in the \User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node. The MMC-specific settings you can configure are:

• Restricted/Permitted snap-ins This container contains a list of all the snap-ins that are available to add through an MMC console. You can permit or restrict access to every snap-in based on the people for whom you are configuring this policy.

• Restrict the user form entering author mode By enabling this setting, you prevent the user from entering author mode in the MMC, which means that the user will not be able to modify the MMC console you created for them. Without this policy, an administrator would be able to get around your permission, enter author mode, and add more snap-ins you didn t intend to allow that person to use.

• Restrict users to the explicitly permitted list of snap-ins This setting is used in conjunction with the Restricted/Permitted snap-ins. If you enable this setting, all the snap-ins are disabled except those that you explicitly allowed in the Restricted/Permitted snap-ins. If you disable or do not configure this setting, all snap-ins are enabled except those that you explicitly restricted in the Restricted/Permitted snap-ins.

Terminal Server

Since its integration into Windows 2000, Terminal Services has proved to be an invaluable remote administration tool as well as a great application server platform. With Terminal Services, you can log in to your Windows Server 2003 machines and perform administrative tasks from virtually any type of device, including Pocket PC devices and Windows CE devices. The power and convenience of Terminal Services is obvious; however, this power comes with the potential to introduce security vulnerabilities into your network if the use of this technology isn t carefully managed. This risk is especially great because Terminal Services is such a well-known application that it provides a tempting target for malicious users or hackers to attempt to gain access to your network. All that any attacker needs to know is the server s IP address, DNS, or NetBIOS name and he or she can try to access the Windows logon screen and attempt to log on to the server.

Exam Warning  

Another term you might hear when people discuss the Windows logon screen is the GINA , which is short for graphical identification and authentication .

Like Windows 2000, Windows Server 2003 has two operating modes for Terminal Server, in:

• Remote Desktop for Administration We discuss this section a little later in this chapter. This is the mode you would put your Terminal Server in if you only needed the feature for administrative purposes. Two simultaneous connections are allowed when the server is in this mode. This remains unchanged from Windows 2000.

• Terminal Services (formerly Application server mode in Windows 2000) This mode enables the Terminal Server to accept multiple simultaneous client connections that can run applications on the Terminal Server. However, for the purposes of this book, we only discuss how to secure the Remote Desktop for Administration feature of Terminal Server.

So, what kinds of countermeasures can you take to protect yourself against attacks targeting your Terminal Servers? Before we answer that, it s good to note that no significant vulnerabilities or security breaches have been recorded against the Terminal Services function. Although this is certainly a good thing, it can change quickly, and you should be proactive in securing your Terminal Services installation. The following sections describe some things you can do to protect yourself and your network against attacks directed at your Terminal Servers.

Changing the Terminal Services Port

By default, Terminal Services listens for incoming connections on TCP port 3389. This means that all a hacker would require in order to launch a session, access the GINA, and start a brute-force password attack would be the Terminal Services Client, which is a free downloadable tool. By changing the TCP port the server listens on, you greatly increase the difficulty for an attacker to access the Ctrl + Alt + Del screen ”the attacker would need to know not only the IP address or DNS name of the Terminal Server but also the new port that Terminal Services is listening on. The new Terminal Services Client in Windows XP and Windows Server 2003 (also called Remote Desktop) will allow you to specify the port you want to use to connect to the Terminal Server, a feature that was previously unavailable with earlier versions of the client. To change the TCP port that the Terminal Server listens on, follow these steps:

1. Click Start Run Regedt32 .

2. Drill down to the following registry key: HKEY_LOCAL_MACHINE\_System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp.

3. Find the Sub key PortNumber (you will notice it is set to the default, 3389).

4. Change it in hex to whatever port number you decide you want the protocol to listen on.

5. Reboot the Terminal Server.

Once the port on the Terminal Server is changed, users who need to access Terminal Services will need to know the port the server is configured to listen on and need to make some configuration changes before they can access the server. In Exercise 4.02, we ll walk through the steps involved in changing the Terminal Services port from the client connection.

Exercise 4.02: Changing the Default Terminal Services Client Port

1. From your Windows XP client, launch Remote Desktop Connection , usually by clicking Start All Programs Communications Remote Desktop Connection .

2. Type in the server name or IP address in the Computer: text box, and append that with the port number (in the form servername :port number ), as shown in Figure 4.2.

   
   Figure 4.2: Creating a Remote Desktop Connection

3. From the Remote Desktop Connection window, click Options .

4. You will see a window to configure any other necessary connection settings, as shown in Figure 4.3.

   
   Figure 4.3: Configuring the Remote Desktop Connection

5. Click Save As and save the connection, making sure you preserver the .RDP extension.

   If you don t want to modify the server port for every connection you make, you could modify the Default.rdp file from the client machine you are using to connect to a Terminal Server and set the server port within the Default.rdp. Doing this ensures that every connection you create will have the new port configured in it automatically. However, be careful with this tactic, since you have just written down the server port in a well-known file location, which means that any knowledgeable attacker can check it to see if you have exposed the new port number in this manner.

 

Remote Desktop for Administration

In Windows 2000, to enable Remote Administration for administrators, you had to open Add/Remove Programs in Control Panel and actually install Terminal Services and, during that process, select this mode. With Windows Server 2003, this process has been modified. All you have to do to enable Remote Administration mode is to enable it through the Remote tab in the Control Panel s System, as follows :

1. Click Start Control Panel System .

2. Tab to Remote (see Figure 4.4).

   
   Figure 4.4: Activating Remote Assistance

3. Check the box next to Turn on Remote Assistance and allow invitations to be sent from this computer .

Windows Server 2003 has made several security enhancements to the Terminal Services and Remote Desktop for Administration software pieces that greatly increase your ability to secure this portion of your network management model. Some of these security improvements are as follows:

• Security Policy Editor You can assign user rights to Terminal Services user using the Security Policy Editor utility. This will give the specified users the ability to log on to a Terminal Server if they are not members of the Remote Desktop Users group (described elsewhere in this section).

  Exam Warning  

  If you have a multihomed Terminal Server and you need to set permissions to the server that are specific to each NIC, you ll need to use the Terminal Services Connection Configuration utility that was common in previous versions of TS.

• 128-bit encryption By default, all incoming Terminal Server connections will be secured using 128-bit RC4 encryption. You can specify that only 128-bit connections be allowed; however, bear in mind that older client operating systems may only be capable of encryption that s lower than 128 bit, which would render them unable to connect.

• FIPS compliance FIPS is an additional level of encryption included with Terminal Server in Windows Server 2003. This level of security refers to the Federal Information Processing Standard (FIPS) encryption algorithm. It is designed to provide compliance for organizations that require this level of encryption for server-to-client communications.

• Remote Desktop Users group Instead of adding individual users to the Terminal Services Connection Configuration (TSCC) program used in previous TS versions, with Windows 2003 you can simply make them members of the Remote Desktop Users (RDU) group. You can use this as part of a group nesting strategy whereby you add the Domain Users group to the RDU group, which would allow anyone with a valid user account on your network to gain access to the Terminal Server, or you can restrict group membership in RDU to filter who has access to Terminal Services.

• Software restriction policies Just as with a regular workstation connection, you can use software restriction policies in Windows Server 2003 to simplify the process of locking down your Terminal Servers by only allowing certain programs to be run by specified users. For Terminal Services, this feature is now built directly into the operating system, replacing the Application Security tool used by administrators to lock down earlier versions of TS.

• Single-session policy For an extremely high-security environment, you can limit your users to a single Terminal Server session, regardless of whether it is active or idle. You can even enforce this setting across multiple Terminal Servers if you are using a TS farm to support a large number of connections.

Remote Assistance

Remote Assistance is a great help-desk and troubleshooting tool offered with Windows XP and Windows Server 2003, but just like everything else, it can create a security hole if it s not properly configured. This tool essentially grants another user the ability to remotely control another computer s keyboard and mouse, allowing that person to assist in troubleshooting a particular problem. As you can imagine, allowing this capability to fall into the wrong hands can have a devastating effect on your network clients and servers. The largest risk associated with Remote Assistance is that the remote user has access to the exact same resources as the local user who has requested help. The benefit of this tool, obviously, is that the remote user can see exactly what s going on and help the user accordingly . Unfortunately, if a malicious user is able to create a Remote Assistance session, he or she will potentially have access to confidential system files and data on your network.

To limit your vulnerability to security issues caused by Remote Assistance, don t rely on your users to use their best judgment on how to control access to their machines. Rather, set up Group Policy to only allow IT support personnel to take advantage of Remote Assistance. Windows Server 2003 Group Policy has settings specially dedicated to Remote Assistance, which are located in \Computer Configuration\Administrative Templates\System\Remote Assistance. These Remote Assistance-specific settings are:

• Solicited Remote Assistance If enabled, this setting allows users to ask for assistance from other users who can help resolve an issue they are facing . You can configure this setting to allow helpers in one of two ways: Helpers can actively take control of the requester s mouse and keyboard, or they can be limited to simply viewing the requester s screen and then offering help using the telephone or a chat application. You can also configure how long a request for assistance is valid. So, for example, after one hour , the help request will be withdrawn if it has not been answered . You can further configure the method by which invitations are sent.

  Test Day Tip  

  Remember that Remote Assistance requests can be made via e-mail, by Windows Messenger, or through a file.

• Offer Remote Assistance This setting acts in conjunction with the previous one by dictating which users or groups can offer assistance, either actively or in a view-only capacity.

To configure Remote Assistance Group Policy, follow these steps:

1. Launch an MMC console by clicking Start Run and typing MMC , then pressing Enter .

2. Add the Active Directory Users and Computers Snap-in by clicking File Add/Remove Snap-in .

3. Click Add , select ADUC , and click Add .

4. Expand ADUC and right-click at the root of the domain. (Configuring the policy at the root of the domain ensures it is applied to all your domain computers.)

5. Click Properties . Select the Group Policy tab, then select the Default Domain Policy , and click Edit .

6. Click your way through Computer Configuration Administrative Templates System Remote Assistance .

7. Enable Solicited Remote Assistance, which in essence allows users to enlist the help of other users to troubleshoot a problem.

8. Enable Offer Remote Assistance and then select the users who can respond to users help requests by clicking the Show button and then adding the Active Directory groups that are responsible for such tasks (such as Helpdesk, IT Support, and so on).

9. Click Apply , and then OK .

Telnet

Telnet is a very powerful remote administration tool that allows an administrator (or potentially a hacker) to use command-line utilities from a text-based command-line window. Because it is infrequently used as an administrative tool and typically passes credentials using clear text, Telnet is disabled by default on all Windows Server 2003 machines. You should enable the Telnet service only if you see a real need for it, especially since the other administrative tools at your disposal offer more features and far better security. The Telnet service should remain disabled unless a need arises that requires it.

Objective 2.3.3: Designing Security for Emergency Management Services

A long-awaited (and perhaps overdue) feature in the Windows family is the ability to manage a server via an out-of- band connection such as a COM or serial port. Out-of-band management refers to the ability to connect to a server using nontraditional methods for remote server management such as a telephone line or a serial port and then having the ability to troubleshoot the server through a Terminal emulator window similar to a Telnet session. Emergency Management Services (EMS) allows you to manage or troubleshoot a server when it is not fully functional or when the operating system has not fully loaded. It also allows you to manage the server in a headless configuration, meaning without having a mouse, keyboard, or video device attached to it. You connect to EMS through Terminal Emulators connecting through a COM or a serial port. Once you ve determined that your server hardware will support it, you can enable EMS using the bootcfg.exe utility. You can use this tool to create an entry in the Boot.ini file to enable Windows console redirection.

Exam Warning  

Remember that the opposite of out-of-band management is in-band management , which is the term used to describe management of a server that is fully functional using traditional tools such as Remote Desktop for Administrators or Terminal Services.

EMS requires a server to be equipped with special firmware that will allow the server to take advantage of all its features. Furthermore, although EMS was designed to allow you to troubleshoot severs that have not booted or are not working properly, you will need to configure EMS and set it up properly while the system is up and running ”you cannot install EMS after a server is already experiencing difficulties. When the system is up and running, you can configure the hardware and install the required firmware to allow EMS to function properly when the time comes. EMS allows you to perform the following tasks:

• Start up or shut down a server

• Install the Windows operating system if the server can communicate with Remote Installation Services (RIS)

• Manage a Windows Server 2003 system when you are unable to access it the traditional way, over the network using standard tools

• View system STOP (Blue Screen of Death) errors

• Change the BIOS settings

• Select which operating system to start

• View Power On Self-Test (POST) results

EMS security measures rely in large part on your choice of terminal concentrator, since that is the device that you ll use to connect to the server. Be careful making this selection, since Telnet security features such as passwords and encryption are not standard on all terminal concentrators . If your device does not include security features, consider using a direct-dial remote access or VPN connection, or use a router to secure network traffic to the terminal concentrator. Here are some other security considerations in configuring EMS on your network:

• Secure access to the physical servers This is the first step in securing any server implementation, whether it s running EMS or not. Your servers should live in a secured area where only authorized personnel have access to them. If for whatever reason you do not have a server room at your location, you should secure the servers in some other way, using locking cabinets or racks.

• Choose service processors These are built onto the system s motherboard and provide a medium that allows EMS to run when the operating system is not functioning properly. When the server s kernel or loader is not even partially loaded, service processors can give you access to the server because they run independently from the regular processors that run the usual operating system.

• Create a separate network for administration For additional security, you can create a second network dedicated solely to network management traffic from EMS. You can use filter lists on your routers to allow only specified computers to access this second network, making sure it is not connected to the Internet in any way. This will almost completely negate the possibility of an outside attacker gaining access to your EMS-enabled devices. However, it reduces your network management flexibility, since you will not be able to use EMS from a location that doesn t have access to this second network.