Summary
Solutions Fast Track
Introduction
Chapter 2 focused on protecting the perimeter of your network, which typically means the Internet link, but it could include any link to the outside world, including connections to business partners and affiliates.This chapter focuses on how to secure the network-connected resources, such as servers and workstations. Many times an organization looks only at securing its perimeter, while leaving its interior network wide open and unprotected.This hard-exterior-soft-squishy-interior approach is surely better than no security, but it is not the best approach.The best approach is through defense in depth, which is the practice of applying security measures at all levels of the network. A solid defense- in-depth approach includes defenses at the outer perimeter—typically, firewalls and an intrusion detection system. It also includes defenses within the interior of the network, such as internal fire- walls, network segmentation, and port-level access controls. Finally, at the core of the security onion are the actual network resources.You can protect these resources in a variety of ways, including via personal firewalls, antivirus software, antispyware software, data encryption, and automated security policy enforcement.
Performing Basic Hardening
All general-purpose operating systems will, by their very nature, come with weaker security settings than you might like.This characteristic is unavoidable, largely because the devices are general-pur- pose.To accommodate the wide variety of uses the system might fulfill, some sacrifices must be made when it comes to securing the system.This isn’t necessarily true when it comes to special-purpose systems, which often come with highly secured and specially tailored configurations so that the system can be used only for its intended purpose.You, on the other hand, know exactly what you want systems to do, so you can customize the general-purpose installation to be more secure in your environment. Securing a system is also referred to as hardeningthe system, which means to make it harder for an attacker to compromise the system.
Regardless of what purpose the system serves, there are some common hardening steps that you should apply to all systems.There are high-level tasks, and as such, the specific implementation details are going to vary from system to system.These high-level hardening tasks have been outlined here. Any plan you develop to harden any network resource should address all of these issues in some fashion.
Defining Policy
You cannot possibly harden a system, at least not from an auditing perspective, if you do not have a definition and set of criteria for what constitutes “hardened,” or secure. Because of this, any hardening process actually starts long before you ever configure anything on a device, with defining policies and standards.Your IT security team will clearly outline the objectives you are trying to meet.The related standards will provide measurable milestones to meet in pursuit of that objective.Your security stan- dards are your yardstick for success and provide an objective measure of your progress. Although the words “make the server secure” imply certain objectives, they do not clearly define measurable tasks; therefore, proving that you have “made the server secure” would be difficult at best. As such, having some well-defined security standards will be to everyone’s advantage.
The IT policies and standards your organization employs should accurately reflect your organiza- tion’s specific needs. Many organizations will sell you an IT policy to use, or one to use as a shell for filling in your own specifics.Taking this approach of using a “canned” policy has many challenges. What constitutes an appropriate policy or standard for one organization may not adequately cover the needs of another organization.The business model, type of business, and a host of other factors all contribute to making a good policy fit your organization.You always will want your security policy and security standards to address some elements, as shown in the following list. Note that you need to represent each item in both policy and standards:
■ Classifying Data. You must have some guidelines on the classification of data (public, confidential, secret, etc.) in order to define steps to secure the data.These classifications will drive subsequent standards, such as “confidential data must be secured on untrusted net- works.” Also, such policy needs to define when data needs to be classified, and explain the different levels of data classification.
■ Information Confidentiality. This policy and standard should define how to keep data
private.This will include encryption requirements and methods.You also need to define the requirements concerning authorization and authentication. Any password requirements would fall into this category.This will also include procedures for granting and revoking access to data, and who has the authority to do so.
■ Information Availability. This covers when and where redundancy mechanisms are
required.This should spell out what levels of redundancy are needed under what circum- stances, such as redundant hardware, redundant Internet circuits, RAID arrays, server clus- ters, failover hot sites, spare hardware, and UPS requirements.
■ Physical Security. These will address requirements concerning granting access, revoking
access, monitoring, and types of access.These could include when and where badge readers are required, when keys should and should not be used, office locks, access by service per- sonnel, and so on.
Generally speaking, the larger the organization, the larger the IT security documents will be. In some cases, you may get as specific as to have separate documents for “Physical Security for IT Datacenters” and “Physical Security for Retail Storefronts.” In a very small organization, the entire IT security policy may be one document, and the entire set of IT security standards another document. Your IT policies are an instance of where “size doesn’t matter,” meaning that a large 100-page policy is not necessarily a “better” policy than a short, concise one.The key is that the policy fits your orga- nization and addresses your needs.
Except in an emergency situation (where you have vulnerable devices in need of immediate hardening steps), defining the appropriate policies and standards should be the first step toward securing your network.You will not be able to create a proper IT security policy without under- standing the business first.The creation of these policies cannot be done in a vacuum. I have seen more than one policy or standard that was written without input from the appropriate groups. Although you could point to it and say, “yes, we have a policy defined,” the policy was constantly in need of revision, and there were innumerable exceptions. Remember, from an audit perspective, a high number of exceptions against a very granular policy are likely to look less favorable than very few exceptions against a more liberal policy.
Access Controls
Access to the devices will be one of the first issues to consider, regardless of what type of device it is. This will include hardening both the logical access and the physical access. When it comes to logical access, the simplest control to introduce is use of firewalls, whether separate firewalls or a built-in “personal” firewalls on the host in question. Some systems have their own mechanisms for imple- menting logical access controls in addition to simply filtering network packets. Where possible, using these additional methods helps provide defense in depth and increase security.You should address physical access as well.The universal truth is that if you have physical access to a system, you can have full access to the system.This is because if you have physical control of a system, generally the system has mechanisms that allow you to gain complete access to the system.
For example, if you have physical access to a server, you can boot it up under Linux, edit the raw data on the hard disk, and reset the administrator password.You can use encryption mechanisms to encrypt the entire hard disk, which will render this particular attack ineffective. In this scenario encryp- tion is serving as a type of access control as part of your defense-in-depth strategy.These types of requirements are exactly the ones you would need to spell out within your policy and then implement them to secure your systems and your data.Your hardening steps should address all of these concerns.
Authentication
Authentication means to prove your identity. In the most common form, you do this using pass- words. Recall that there are several different means to authenticate a user, including something they have,are,know, or any combination of the three. In the case of a password, this would mean using some- thing the user knows (the password) to prove he is who he claims to be. When you hear the term two-factor authentication, this refers to using two out of the three mechanisms for proving someone’s identity.Two-factor authentication most often takes the form of a token which randomly generates a key.This key (something you have), combined with a password or PIN (something you know), pro- vides heightened authentication. One of your key goals of your hardening efforts is to strengthen the authentication process as much as possible.Your hardening steps will need to provide authentication as much as possible.
Authorization
Authorization means to define what you have access to do. Obviously, authorization cannot occur securely without authentication happening first.You cannot possibly know what Jill should be able to access until you have positively identified that the person in question is in fact Jill. Usually you con- trol and harden authorization through tighter configuration of file-level security. It can also include access to systems—for instance, a restricted user who is not allowed to install software drivers or applications on his workstation.The objective is, of course, to provide as few privileges as possible, while still enabling the person to perform his assigned tasks.This concept is known as the principle of least privilege. It helps to determine the least amount of access a user requires in order to fulfill his assigned duties.
Auditing
Auditing is a part of the hardening process as well. A system with no audit trail is certainly less secure than one with an audit trail. While most of the security hardening you will perform to various net- work resources comprises preventive controls, an audit trail serves as a detective control.You should not only enable and configure the appropriate level of auditing but also take steps to protect the resultant audit logs. Remember to protect the logging process (by using a secured account to run it) and the logging configuration (typically using file-level access controls).You will need to safeguard the audit logs by implementing mechanisms to ensure log integrity and availability. If you cannot ensure the integrity of a log file, it may still be useful when it comes to troubleshooting a technology issue.The log file will be practically useless, however, if you need it to reconstruct the actions of a hacker or for use during legal proceedings.
Hardening Windows Systems
Windows systems have a reputation for being insecure out of the box.This reputation is certainly less justified than it once was. Microsoft has made a lot of progress toward a very difficult goal, which is to make its operating systems inherently more secure without diminishing the user’s experience. After all, a secure system that is unusable isn’t going to be of much value. Much like minimum password requirements, there is a point at which your efforts to increase security will actually backfire and will reduce your overall security level. Because of this, you should always maintain an effort to balance increased security measures with overall system usability and functionality. Again, doing this properly will require an in-depth understanding of the needs and processes of the organization.
The first thing to do in terms of hardening a system is to assess the current security posture of the device in question. Only after you know how the system is configured can you determine what you need to do next. Chapter 1 provided some good guidance on how to assess the current security pos- ture of your network.This chapter will focus on the tools that you can use to configure security set- tings in an effort to harden your network resources.
General Hardening Steps
All the possible steps that you can take to secure a Windows host could fill (and have filled) entire volumes.The contents of this chapter should start you on your way with the basic hardening steps, and hopefully will point out a few tools you might not have known you had at your disposal. Be aware that in some cases, certain policies and standards may influence or affect other areas indirectly. For example, if you use biometric scanners for logon on all workstations, a “secure password” policy becomes practically moot. Under those circumstances, the password policy would end up applying only to special-purpose devices that were not able to take advantage of the biometric scanner.The exception, of course, is a requirement to use multifactor authentication, such as biometrics and a pass- word. In this way, all of the hardening steps are interrelated and interdependent. A policy decision in one area can impact a policy in another area, and we see a similar relationship in the use of standards.
Most configurations on modern Microsoft systems are performed using the Microsoft
Management Console, or MMC.The MMC has come standard on Windows systems since Windows 2000. Because we’ll be relying on it so heavily in the following sections, let’s get familiar with using
the MMC here.You can start by opening a new MMC console. Do this by navigating to Start |
Run | mmc.exe.
Figure 3.1 shows the blank console.
Figure 3.1
Empty MMC ConsoleThe MMC is not very exciting without some additional configuration.The various interfaces are called snap-ins.The first time you open the MMC in this fashion it will have no snap-ins loaded.To load the services snap-in, you would open the console and click File | Add/Remove Snap-in. Then, in the Add/Remove Snap-in window, click the Addbutton. On the Add Standalone Snap- inwindow (shown in Figure 3.2), select the desired snap-in—in this case,Services, and click the
Addbutton. Leave the default selection of Local Computerand click Finish.You can then close
the Add Standalone Snap-inwindow by clicking Close. Click OKon the Add/Remove Snap-
inwindow. If you peruse the fields of the services snap-in you will find that they are the same as what you’d see if you had navigated to the stand-alone services snap-in via Start | Run |
Services.mscor Start | Programs | Administrative Tools | Services. For one-off configura-
tion tasks, the individual snap-ins might be easier to access, but an MMC console that includes all the snap-ins you need in one place is very efficient.
When you close the MMC you will be asked whether you want to save your settings. If you click Yes, you can choose a name and location for the .msc file. In this way, you can have access to an MMC with your preferred snap-ins for future use.These saved configuration files are also portable, so you could place the file on a pen drive or network share and use it on another system.This can be handy for support personnel to have access to when working on other systems, especially since the start menu shortcuts might not be available on all systems. Now that you understand the basic opera- tion of the MMC, let’s move on to some actual hardening steps.
Figure 3.2
Add Standalone Snap-in ScreenUsers and Groups
One of the simplest ways to define access is by configuring the user and group accounts and the rights they have.Typically you can access the users and groups configuration via the Control Panel
under User Accounts.You can also access the same information (in an easier-to-use format, at least in my opinion) within the MMC using the Local Users and Groups snap-in. If you try to use the
Local Users and Groupssnap-in on a domain controller, you will receive an error.You should instead use the Active Directory Users and Computers snap-in to manage your domain user and group accounts.There are a few common hardening steps you can perform with little effort, which are very effective from a security standpoint.
Most user and group administration will revolve around the Administrator account. On Windows, the Administrator account is a special account. Although the Administrator account is in the Administrator group, the uniqueness of the account goes far beyond that. Placing another user in the Administrator group will not give it the level of access and breadth of power that the
Administrator account enjoys. Because of the privilege this account provides (similar to the root account on Linux), the Administrator account is the number-one target for attacks upon the Microsoft operating system.The name of this account is identical on every Microsoft Windows system, so everyone knows which account to attack. But we don’t have to leave it that way.You cannot delete the Administrator account, but you can rename it to a more customized (and unknown) username.
A clever security technique is to rename the Administrator account.You can then create a new user account (with a username of administrator) with as little access as possible.This new Administrator account can have very thorough logging and auditing enabled for any actions this account performs. Using this method, all of your local technical support personnel will know about the renamed Administrator account and will not attempt to use it.Therefore, the only people attempting to use the Administrator account are likely to be up to no good, or at least such account activity would be highly suspicious. Renaming the Administrator account is as simple as right-clicking the account and selecting Rename.You might also want to remove the description for the newly named
Administrator account. In some environments, the accounts are renamed to very innocuous-looking names, such as Printing or Lockout. In other environments, I have seen random-looking account