Designing Strategies for Security Management
- Designing Security for Network Management
- Designing a Security Update Infrastructure
- Exam Prep Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
- Remote desktop administration
- Telnet
- Emergency Management Services
- Software Update Services (SUS)
- Systems Management Server (SMS)
- Disaster recovery plan (DRP)
Techniques you'll need to master:
- Designing security for network management
- Designing a security update infrastructure
Your network has enough enemies, including viruses, well-intentioned users, and not so well-intentioned attackers. You must ensure that you don't become your own worst enemy! You need to understand the risks associated with managing your network and mitigate those risks with whatever tools you have available. In addition, you need to keep your network up to date with the latest security patches. This process needs to be as automatic as possible in your situation.
In this chapter, we discuss the tools that you can use to manage the risk of managing the network. These include simple tools such as the Run as command as well as more complex tools used to monitor and manage servers and services. We also discuss the new tools in Windows Server 2003 that aid you in assessing the current patch level of computers in your network and in keeping computers up to date with security patches from the Microsoft Web site.
Designing Security for Network Management
You need to understand the power of the Administrator account as well as other accounts that provide rights on the network. In the right hands, these are tools you use to manage a network. In the wrong hands, they are weapons that attackers can use against you. As you manage your network, take care that these accounts do not fall into the wrong hands. In addition, you need to understand the tools and services available to enhance and monitor the security of your network. Designing security for network management includes the following components:
- Managing the risk of managing networks
- Designing the administration of servers
- Designing security for Emergency Management Services
Managing the Risk of Managing Networks
Windows Server 2003 controls access to Active Directory and the ability to manage it using security groups. Some groups are designed to give a person rights to manage an aspect of the network, solely because they are associated with that group. These groups include Administrators, Server Operators, Account Operators, Backup Operators, and many others. Administrators who are members of these groups must understand the power that the group membership gives them and use it wisely.
We now discuss the tools that Windows Server 2003 provides to assist an administrator in the safe management of the network. These tools include the following:
- The Run as command
- Restricted groups
- Security auditing
The Run as Command
Even if you are an administrator, you need to log on every morning with the same type of user account that everyone else uses. You don't need an administrative account to check your email and browse the Web. You should only use an administrative account if you are doing something on the network that requires the use of an administrative account. This practice protects the network because the less you use an administrative logon, the less chance there is for a Trojan horse virus or some type of worm to pick it up and send it to an attacker. Also, if you walk away from a computer that you are logged on to with an administrative account, another person could use the computer and "play Administrator" for a while!
Although your users should only have one account, you and your other administrators need to have at least two accounts. You should use a normal user account until it is necessary to use the administrative account and, at that time, you can use the Run as command to perform a secondary logon.
You can use the Run as command either through the GUI or at the command line. To use the Run as command with a GUI tool, simply right-click the tool, click Run as, and then log on with the account that you want to use to run that tool. You might need to hold down the Shift key while you right-click, depending on the tool that you choose. Figure 3.1 shows the Run as command on the Start menu. Figure 3.2 shows the secondary logon screen for the Run as command. When the tool is closed, the system reverts back to the primary logon account.
)
Figure
3.1 You can right-click the tool to use the Run as command.
)
Figure
3.2 The Run as command provides a secondary logon for that tool only.
To use the Run as command from a command prompt, type the following syntax:
Runas /user:domain\account name mmc %windir%\system32\tool.msc
where domain is the name of your domain, account name is the name of the account with which you want to run the tool, and tool is the name of the tool that you want to run.
For example, Runas /user:bfe.vtc.com\administrator "mmc%windir%\system32\dsa.msc" will run Active Directory Users and Computers in the bfe.com domain by the account name of Administrator.
After you enter this syntax correctly, you are then asked the password of the account with which you want to run the program. Figure 3.3 shows the command line with the entered command and the system's response. After you enter the correct password, the system opens the tool. When the tool is closed, the system reverts back to your primary logon account.
){kind=small}
Figure
3.3 You can use the Run as command from a command-line interface.
TIP
You can check the %windir%\system32 folder on your servers for files with .msc extensions. All files with .msc extensions can be used with the Run as menu option. You can even create shortcuts on the desktop or in your administrative tools using the same command.
CAUTION
We are only using the default name "Administrator" for the administrative account for this training example. You should always change the default names of administrative accounts.
Restricted Groups
Membership in a security group can give someone permissions and rights that she would not have if she was not in that security group, especially if that group is a member of another group that has more rights. This is the way the system is supposed to work. But, what if someone is a member of a group that gives her administrative access and you are not aware that she is a member? In this case, your own system is working against you.
You might be thinking, "But I can just check all of the groups and make certain that I know who the members are." Well, that's true, but there might be more groups to keep track of than you think. You have to consider that every workstation and member server has its own local groups as well! Wouldn't it be nice to just lock those groups down with some type of template? Well, now you can!
Restricted Groups is a computer security policy that should be used primarily with workstations and member servers. In other words, it is rarely used on domain controllers. It allows you to define who can be a member in a particular security group on a computer and what other groups that group can be a member of as well. After you define who can be a member of that group, anybody else who currently is a member is removed from membership as soon as the security policy is refreshed. This way, it's impossible for you to miss anybody. You can also copy the template that you create and use it on subsequent workstations and member servers.
You can create the template and apply the settings for Restricted Groups on a member server running Windows 2000 Server or Windows Server 2003 in two ways. You can either create the template in the local security settings for each of the computers that you choose or you can create a Group Policy and roll it out to all of the computers in an organizational unit (OU) or hierarchy of OUs. For Windows 2000 Professional and Windows XP Professional clients, you can use Group Policy to enforce Restricted Groups.
As we mentioned previously, you should refrain from using Restricted Groups at the domain level; however, it is possible to use this tool to provide a "reality check" if you suspect that someone has obtained fraudulent access to administrative rights through membership in a security group.
To configure Restricted Groups on one member server, perform the following steps:
- Open the Local Security Policy through Administrative Tools.
- Expand the Security Settings option.
- Right-click Restricted Groups.
- Click Add Group.
- Type the name of the group that you need to manage.
- Add the members that you want to be in the group and the groups of which that group can be a member.
- Click OK or Apply.
When you click OK or Apply, only the members that you have designated are still members of the groups for which you have set Restricted Groups. Any other members are removed from group membership. This takes effect the next time they log on to the server locally.
To configure Restricted Groups with Group Policy, perform the following steps:
- Open the Group Policy Management Console and Group Policy Object Editor tools to create and configure a new Group Policy or edit an existing one.
- Expand Computer Configuration.
- Right-click Restricted Groups.
- Click Add Group.
- Type the name of the group that you need to manage.
- Add the members that you want to be in the group and the groups of which that group can be a member.
- Click OK or Apply.
When the Group Policy is linked to a container, the Restricted Groups settings become effective for all computers in that container. You can force the policy to apply as soon as you link it, using the gpupdate command, or you can simply wait until the policy is refreshed automatically by the system.
TIP
When a Group Policy is linked to a container, you must ensure that no other policies that could change the results of the Group Policy are linked to the same container. Remember, the last one to "flip those switches" wins!
Security Auditing
A wise person once said "You don't get what you expect, you get what you inspect." You need to have a system in place that aids you in monitoring the security of your network. This includes an audit policy that determines what is to be audited and a person or persons responsible for regularly checking the security log to look for anything that doesn't seem to fit.
Windows Server 2003 provides the tools for auditing logons, resource access, account management, and more. Your audit policy determines what is written to the security log. The security log can then be read, archived, and printed with Event Viewer. Figure 3.4 shows the settings for Audit Policy in the Microsoft Management Console (MMC) named Default Domain Security Settings. Table 3.1 defines each of the settings that you could use in your audit policy. You can audit each of these settings for success, failure, or success and failure. Figure 3.5 shows an example of a security log in Event Viewer.
)
Figure
3.4 The settings in your audit policy determine what is written to the security
log.
Table 3.1 Audit Policy Settings
Policy |
Definition |
Audit Account Logon Events |
Is set on a domain controller. Audits domain controller's authentication of a logon from another computer. |
Audit Account Management |
Audits activity that is generally associated with administrators, such as creating or renaming users or groups, or changing passwords. |
Audit Directory Service Access |
Audits objects in Active Directory that have their system access control list (SACL) set for auditing. |
Audit Logon Events |
Audits the local logon to a computer regardless of the role of the computer. |
Audit Object Access |
Audits the access of resource objects, such as a file, folder, printer, Registry key, and so on that have the system access control list (SACL) set for auditing. |
Audit Policy Change |
Audits changes to user rights assignment policies, audit policies, or trust policies. |
Audit Privilege Use |
Audits each instance of a user exercising a user right. |
Audit Process Tracking |
Audits events usually associated with applications, rather than users, such as program activation and handle duplication. |
Audit System Events |
Audits a user's restarting or shutting down of the system or any event that affects system security or the security log. |
)
Figure
3.5 You can view the results of a security audit in Event Viewer.
Designing the Administration of Servers
Managing an enterprise can be a cumbersome task, but Windows Server 2003 provides many tools to assist you in the efficient and safe management of your network, no matter how large it is. The tools with which you need to be familiar are as follows:
- Microsoft Management Consoles (MMCs)
- Remote Desktop Administration
- Telnet
- Remote Assistance
Microsoft Management Consoles
Using Microsoft Management Consoles (MMCs), you can create your own custom "toolboxes" that keep the tools you use most frequently all in one place. You can then share these toolboxes with other administrators whom you trust, or you can create another toolbox that has only the tools that they need. You can simply share the completed MMC in a folder to which the other administrator has access, and he can then use the MMC as well. Share it with Read permission so that the administrator who receives the MMC cannot change the file without also changing the name and the ownership of the file. To use the MMC tools, you must register the proper dynamic link libraries (DLLs). You can easily register most DLLs by entering adminpak.msi at a command prompt and following the Windows Server 2003 Administrative Tools Installation Wizard.
An MMC itself has no administration capability; it's only a toolbox that contains the real tools called snap-ins. These snap-ins are produced by Microsoft and many other vendors. They include most of the tools that you need to configure, manage, and monitor your network. Many of these tools can be used on the local computer or on a remote computer connected to the management console. Figure 3.6 shows an MMC that has been customized to hold tools for two different computers.
)
Figure
3.6 You can build MMCs that hold tools for multiple computers.
Remote Desktop Administration
Remote Desktop Connection replaces the Remote Administration Mode for Terminal Services used in Windows 2000 Server. It provides a new interface that allows you to safely manage any computer that is configured to allow users to connect remotely. You can access Remote Desktop Connection by clicking Start, All Programs, Accessories, Communications, Remote Desktop Connection. You can then connect to the computer by entering the computer name and the password for that computer.
TIP
You must also be a member of the Remote Desktop Users security group to use Remote Desktop Connection. The administrator is a member of this group by default and can add other members.
You can control the resolution and other aspects of the "user experience" on the Remote Desktop Connection settings. Figure 3.7 shows the Remote Desktop Connection dialog box. These options allow you to configure your remote session based on the allowed bandwidth and other restrictions. Figure 3.8 shows the custom settings that you can configure on the Experience tab. You should use Remote Desktop Connection when you are making a connection to only one other computer or server.
)
Figure
3.7 You can configure options for Remote Desktop Connection.
To make multiple simultaneous connections, use the Remote Desktops snap-in. This tool enables you to manage many servers as if you were sitting in front of each one of them. You can control each of the connections and encrypt the connection over the Remote Desktop Protocol (RDP). You can quickly switch between several remote desktops. Figure 3.9 shows an MMC with the Remote Desktops snap-in installed.
)
Figure
3.8 You can configure custom settings on the Experience tab.
)
Figure
3.9 You can control multiple remote connections from one interface
with the Remote Desktops snap-in.
Telnet
In general, you use Remote Desktop Connection or the Remote Desktops snap-in to connect with any computers that are running Microsoft operating systems. This provides the most secure method of remote administration.
For other servers and network devices on your network, you can use Telnet. The Telnet application is part of the TCP/IP suite, and any network that is using TCP/IP can use it. The Telnet client is built in to Windows Server 2003 and provides a command-line interface to another server and limited functionality to configure the server (see Figure 3.10). Telnet does not provide security—all passwords and data are transmitted in clear text. If you use Telnet, you need to ensure that no sensitive information is being transmitted.
)
Figure
3.10 You can configure servers and network devices on a command-line
interface with Telnet.
CAUTION
Telnet is not recommended for remote administration of Microsoft computers because all data and commands are transmitted in clear text.
To access a computer or network device with Telnet, perform the following steps:
- Click Start.
- Click Run.
- Type telnet.
- Type open.
- Type the name of the host with which you want a connection.
- Type ? for help with further commands.
The list of commands that are available are based on the type of host to which you have connected. All commands are alphanumeric. In other words, you can't use your mouse or any type of GUI with Telnet. Table 3.2 lists some Telnet commands and the actions that they perform.
Table 3.2 Telnet Commands
Telnet Command |
Action Performed |
Open hostname |
Establishes session with host |
Close |
Closes connection |
Display |
Shows current settings for client |
Send |
Gives additional commands as defined by the type of host |
Set |
Allows you to configure options when used with additional arguments, depending on the client |
Unset |
Turns off options that were previously set |
Status |
Determines connection status |
? |
Shows Help menu based on host |
Quit |
Closes Telnet client |
Remote Assistance
Clients can request your assistance using the Remote Assistance tools, provided by Windows XP Professional, and you can respond to their requests and assist them through your Window Server 2003 network. After you are connected, you can view the client's computer and chat online. You can even take control of their mouse and keyboard with their permission. You can also upload files to them or download their files to your computer or central server. Remote Assistance communication can be based on Windows Messenger or Microsoft Outlook. Figure 3.11 shows the Remote Assistance console on a Windows XP Professional client.
)
Figure
3.11 Clients can request your assistance using the Remote Assistance
console.
Designing Security for Emergency Management Services
At this level, it almost goes without saying that you need to maintain redundant drives, power supplies, and server components. You also need to create backups of all data and configurations and keep copies offsite. This type of management activity is the day-to-day operations that help to keep the network operating smoothly, but what if something goes wrong?
Unfortunately, disasters, such as fires, floods, hurricanes, tornados, and earthquakes, do happen from time to time. Your Emergency Management Services design needs to include a disaster recovery plan (DRP) that takes these into account. Your DRP should focus on the disasters that are most common for your area. For example, you probably won't be concerned about earthquakes if you are located in Florida, and you wouldn't worry much about hurricanes in South Dakota.
In the event of a disaster of this magnitude, the main goal is to get the computers back up to the point that your company can do business before you go out of business permanently! Your DRP should address a plan to rebuild the network to a functioning state as quickly as possible, even if your whole building is destroyed. The details of this plan will, of course, vary, depending on the size and complexity of the company, but the main thing you need is a place to work. The types of alternative sites that you should consider in your DRP are as follows:
- Hot site
- Warm site
- Cold site
Hot Sites
A hot site is a location that is up and running 24/7 with everything that you need to function. Its main advantage is that, in the event of a disaster, you can move into the hot site and resume normal business operations in a matter of hours. Another advantage is that it is possible to do a "dry run" and test the hot site.
The hot site should be close enough to be practical for employees, yet far enough away so as not to be taken down by the same disaster that took down your main site. You can maintain the hot site, or you can pay another company to provide the service. The main disadvantage of a hot site is the large cost associated with it. Typically, the potential loss of money is not enough to justify the cost of a hot site, so they are only used in organizations in which people's lives are at stake, such as highly sensitive governmental institutions or hospital networks.
Warm Sites
A warm site is a location that provides the space, electrical outlets, and communications lines that will be needed in the event of a disaster. It is not customized for one organization and might be used by many organizations in the event of a natural disaster. Typically, no computers are in place because it is assumed that the company will provide the computers when, and if, the time comes to use the site. The main advantage of this type of site is that it costs considerably less to maintain than a hot site. The main disadvantage of this type of site is that it is much more difficult to test your DRP from time to time.
Cold Sites
A cold site is a location that basically has four walls, a ceiling, and a bathroom! Typically, it's a prearranged agreement with another party to use their space if a disaster happens. There is very little planning involved in a cold site. The main advantage is that it costs very little. Two parties in different areas might even agree to let each other use a part of their building in the event of a disaster, so there is no cost to either party. The main disadvantage of a cold site is that it does not fully provide a quick transition back to normal business operations.