Direct Object Defenses

Having looked into physical, internal, and perimeter defenses, an organization should further layer its security by focusing on individual servers and devices. Since enemies come from everywhere, inside, outside, above, and below, we can never be sure where an attack will originate. This means that we cannot simply rely on the perimeter firewall or a motion alarm system; individual objects within the organization must have their own security applied, thereby layering our security efforts. These security measures may provide for a third line of defense for someone attacking from the Internet, or may even be the first line of defense for someone hacking from an internal network.

Similar to when we looked at perimeter network security, when we look at the security of servers and devices, we must maintain a higher focus. Our security audits have, no doubt, pointed out some specific vulnerabilities within many of our devices, which we must be sure to address. Patching individual vulnerabilities, however, is not the solution to overall security issues. Defending systems and devices is not simply addressing known vulnerabilities, but rather taking all of the rules and applying them to each object within the environment.

Applying the Rules Through Hardening

Vendors have been training us over the years that system security is a process of logging on each morning and having the system automatically install the most recent security fixes. This is a good practice; however, it is still somewhat reactionary since we are taking care of any vulnerability after it is already known to hackers. What if we could deal with a problem before the exploit ever came about? What if we could handle our system security in such a way that most of the next exploits will not affect us?

Dealing with the security of our systems and devices in such a way is possible by applying the concept of layering security and the Rules of Least Privilege, the Three-Fold Process, and Trust. The process of taking a new object and proactively applying these rules and concepts to it is called hardening. Every organization should have a security standard that dictates minimum security practices required for building servers, routers, and other devices. These standard hardening procedures should be applied to objects proactively, meaning before they even touch the network or handle their first transactions. An updated hardening process should be taught to all staff members responsible for installing servers, routers, firewalls, and other critical devices. Systems that have been hardened should be updated with newer hardening practices as they become available.

Rule of Least Privilege

When looking at a server or device, or any services within that server or device, we should be thinking in terms of the Rule of Least Privilege. Though it is not practical to place a firewall in front of every object, it is possible to practice the Rule of Least Privilege within objects themselves.

The problem with security in most operating systems is that they default to being "user-friendly" and, therefore, "unsecure." A Windows 2000 server, for example, will by default provide a NULL share through which other systems on the network can access basic account information. This was implemented to make life easier when applications and administrators needed to access such data. Most people, however, do not require access to this type of information and should not be able to obtain it. There are many similar instances where default features do not conform to the Rule of Least Privilege and manual intervention is required.

The Rule of Least Privilege must also be considered for the services and applications installed on a system or device. Cisco routers, for example, could be running services such as "Small TCP Services." Even though we don't really use this feature, it is simple to enable and can be found running in systems around the world. However, enabling services that have no need to be enabled is in violation of the Rule of Least Privilege. Such services can give away valuable information, or can eventually be vulnerable to a new exploit. Organizations that never enabled such services will not be exposed to their vulnerabilities. The fewer services and applications running on a system, the less vulnerable the system.

The entire hardening process should be based on the Rule of Least Privilege. If there is no need for something to be installed or running, then it should not be installed or running. Even the most simple and harmless of services should be disabled if not required. Such practices greatly reduce the security vulnerabilities and the number of weak links within an organization.

Rule of Change

Objects will undoubtedly change over time. Some organizations add, remove, and modify servers and devices on a daily basis. With each change, however, there is always the chance of reducing the hardening on a system and introducing a new vulnerability. Installing applications, enabling services, even applying patches, could potentially have a negative impact on the security of an object. It is thus important that all changes to systems and devices be fully understood and tested before being implemented. Such changes should also be documented for each system in case a history of changes is ever required.

Rule of the Weakest Link

We have already discussed the weakest link as it applies to objects within the internal network. However, the weakest link also comes into play when considering individual servers and devices. Each object has within it numerous services and applications that can potentially be vulnerable to attack. It is important when considering hardening practices to always be aware of the weakest link. Hardening a system does little good if the hardening process allows for a four-character administrator password. Likewise, disabling 10 services on a UNIX server is of little help when one vulnerable service remains enabled.

Rule of the Three-Fold Process

The hardening process should include the installation or enabling of components that allow the organization to monitor and maintain an object. Servers and routers, for example, should have logging enabled for security-related events. Such logs should be forwarded to a central logging system, where the logs of other similar objects are stored. These logs should be reviewed regularly and critical events should generate notification alerts in real-time.

Systems should also be updated regularly with security fixes to ensure that the security level remains high. There will always be flaws in operating systems, applications, and services that will need to be fixed through vendor patches. Luckily, most vendors isolate security patches from normal patches, allowing us to install them quickly and without too much concern for other changes within the patch.

Since every patch has the potential of reacting badly, creating a security hole, or causing a failure within the system, many people consider it a good idea to only use patches that relate specifically to the installation in question. For example, if a Telnet patch comes out and Telnet is disabled on a system, then maybe this patch should not be installed.

With security, however, it is a different matter. If a Telnet vulnerability was discovered and our system with Telnet disabled was not patched, we still have vulnerable code inactively sitting on the system. Six months from now, a new administrator may decide to enable Telnet, in which case, he or she will be enabling a vulnerable Telnet service. Imagine also if a hacker is able to gain just enough access to enable the flawed Telnet service so that he/she can further penetrate the system. The Telnet services may also be enabled indirectly when installing a new application or service. If and when Telnet is enabled, we want to make sure it is not a flawed version without the security fix applied. This makes it important to fix all vulnerabilities within an object, or to monitor such activities extremely closely as to not accidentally enable a vulnerable service.

Some Good Hardening Practices

Hardening should be a regular practice for any organization with servers, routers, and other critical devices. There are many good hardening processes published by different security organizations. Hardening processes must remain extremely modular and dynamic to keep up with new techniques and new types of vulnerabilities and exploits. I have included some good resources for finding specific up-to-date hardening information about specific systems and devices in Appendix A, Tips on Keeping Up-to-Date. In general, all hardening processes should include the following steps:

• Maintain an active inventory of versions, fixes/service packs, applications, services, etc.

• Download the latest security fixes an organization is comfortable applying, study them, and install them

• Disable all nonessential services and remove all nonessential applications (or if this is a new install, simply don't install them)

• Disable all unnecessary accounts, groups, and access privileges

• Change names (if possible) for commonly known accounts like "Administrator"

• Enable security controls like password filtering, lockout, and aging services

• Enable logging for various security activities and forward logs to a centralized server

• Test security via a vulnerability scanner