A correctly secured and fully patched host is immune to over 90% of vulnerabilities immediately. As with all security controls though there needs to be a trade off. The efforts of monitoring every host individually are beyond all but the smallest of sites.
Most operating systems today have the ability to update patches themselves. This ranges from each host automatically going to the vendor’s site to centralized servers which an organization can configure to pull patches and issue internally when approved. There are two types of patches;
- Security Patches
- General updates
As a security auditor, our focus will of course lie primarily with security patches. This however does not mean that we can ignore general updates; rather we should focus on the details and reasons for the update. For instance, a patch to a financial application may not in itself be a security patch but may indeed have security implications. For instance the increased ability in a software package to provide auditing and enhance the segregation of duties capabilities of the software may be considered a general update but would have clear security implications. Like many things, we need to look at the system holistically. One of the main failings of the UNIX systems audit is to treat the system and application in isolation.
The Need for Patches
This is not to say that network security replaces the need for host security, rather that both have their place. Some hosts (for example web servers in public zones) are more critical than other and more likely to be attacked. In addition, a firewall does little to protect a web based application. For these and many other reasons it is essential to maintain a strong regime of system security.
Obtaining and Installing System PatchesIt is crucial that both the UNIX administrator and auditor understand the difference between security and general patches. It is important that all patching be done in an organized manner. A risk management approach needs to be taken to patching systems. The auditor needs to remember that it is too late to patch a system after it is compromised. The only sure way to clean a compromised system is to rebuild it (from a system format).
The first thing to do is find out what patches are required. Nearly all UNIX vendors provide websites with comprehensive information concerning the nature of patches and some of the main risks associated with those patches.
1. Security Patches need to take precedence over other patches. First determine if the following conditions apply;
a) Is the patch required for an active service (i.e. a Bind patch for an Internet DNS Server)? If the service being patched is not installed on the system than it may not be necessary to patch the system,
b) Is the Service externally vulnerable? It is important to apply security patches for services that are not available externally as well, but the level of risk is lower,
c) Does the patch affect other services on the host? Has the patch been tested on a development or QA system and been found to function correctly in your organizations environment?
2. If the patch affects the system in a non-desirable manner (i.e. causes a servers to crash or otherwise suffer some performance hit) than it would be better to look at other alternatives based on the risk to the system and its value. It may be a better option to filter the service for example.
3. If the patch is determined to be required to ensure the security of the system than formal patch procedures should be followed for its implementation. Patch processes vary from vendor to vendor. It is essential to understand the methodology used and create a process to effectively implement this.
There are two main areas that a UNIX author needs to consider when auditing system patching. Firstly, does the organization have an effective patch process that is based on risk? Next, is the patch process adhered to? There are two issues here, each of which needs to be addressed. Good corporate governance requires that management implement a policy requiring effective controls. Any such policy is only effective if it leads to a strong process that can provide the desired outcome. To do this any process needs to be measurable. What a great difficulties in patch management is the allocation of metrics. It is not enough just to measure the number patches installed or not installed, but rather there needs to be a means of determining whether a patch should be applied or not.
At the least, any patch should be evaluated against existing applications to ensure that the patch will not negatively impact the system is meant to fix. This is another reason why there are clear benefits to minimizing the number of services and applications provided on any host. Additionally, many standards such as the PCI-DSS (the payment card industry security standards designed to protect credit and payment card information) require that systems are set up to host only individual services.
Although patching is to many people the greatest bugbear in IT, it is also one of the simplest means of demonstrating a base level due care. The combination of a patch management program and the proof that that program is being used together go a long way to demonstrating effective corporate governance. In the event that a system is compromised due to a software vulnerability, there are really two alternatives when an organization is facing a claim for negligence. Either the organization has patched the system and the compromise occurred due to an unknown or undisclosed attack (a zero day vulnerability) or the breach has occurred because of a control failure. In the first instance, negligence would come down to the necessity to demonstrate alternative controls but should have been in place. In this instance the onus of proof is on the party seeking to show that your company was negligent.
Alternatively, were control file you has occurred in either the system was misconfigured or unpatched proving that your organization was not negligent will come down to the controls and processes that have been implemented. In the case of patching, if the organization can demonstrate a risk-based approach and a methodology that provides valid justification for not applying the patch, it is unlikely that they will be found negligent even without applying the patch. Similarly, an effective patch process that has generally been followed but which has suffered some failure leading to the breach due to a miss-configuration also provides a good defense to either avoid or at the least minimize any action for negligence.
As with all controls, the key is to provide evidence. An ongoing audit program that is run on a regular basis over your UNIX systems will provide this evidence. Most modern operating systems, including UNIX, have a patch management system, some examples are;
Sun Solaris Patch Manager or PatchPro
http://wwws.sun.com/software/download/products/3f9d714b.html
System Reliability Manager for Sun Management Centre
http://www.sun.com/solaris/sunmanagementcenter.
Linux (red Hat) Up2date
RH tools - RHN proxy or satellite server
https://rhn.redhat.com/Validating the Patch Process
In validating the patch process, the auditor first needs to download the latest patch information from the respective UNIX vendor and test that any security patches that recommended for the system had either been installed or alternatively that there is a formal and valid justification for why they have not been installed. The auditor should also always Note that some patches may re-enable default configurations on a service. For this reason, it is important to ensure that the administrator has created a backup for a system prior to installing a patch. A good change management process would require that a back-out path has been detailed prior to the implementation of the patch. The process for patching the system should maintain details on obtaining patches and how they need to be tested and installed. Ideally, any patches that are downloaded from the Internet must be validated such as through the use of a hashing algorithm.
This is that the system administrator should were possible always verify the digital signature of any signed files. If no digital signature is supplied but a checksum (e.g. md5) is supplied, then the administrator should verify the checksum information to confirm that may have retrieved a valid copy of the patch. If only a generic sum checksum is provided, then the process should require that they use this to check the file. Be aware that the sum checksum should not be considered secure. After the patch has been applied it is important to test the system. The administrator should test that the patch has been applied correctly and is operational (i.e. check the version of the software and that it functions correctly).
All this provides evidence in support of the process. This in itself will not make a system secure. What it will do is provide evidence that the organization cares about maintaining the security of its systems and data. This evidence will go a long way to demonstrating that the organization was not negligent in the event of a breach. What is important to remember here is not if a breach occurs, but when.
There have traditionally been a number of both commercial and non-commercial tools to check systems patching and vulnerabilities on UNIX systems. Though most of these do not focus specifically on Patch controls but rather scan for vulnerabilities in general they are none the less (and more so for this fact) an essential part of implementing and installing a secure Unix (or Linux) system. Some of the non-commercial products have been detailed below.
Tiger Analytical Research Assistant (TARA) is the next stage of the TAMU 'tiger' program. Output has been rationalized to provide a more readable report file. TARA has been tested under Red Hat Version 5.x, SGI IRIX, and Solaris.
"..
tiger is a set of scripts that scan a Un*x system looking for security problems, in the same fashion as Dan Farmer's COPS. 'tiger' was originally developed to provide a check of UNIX systems on the A&M campus that want to be accessed from off campus (clearance through the packet filter). As such, we needed something that *anyone* could run if they could figure out how to get it down to their machine."
[1]COPS is a UNIX security status checker. Cops checks various files and software configurations to see if they have been compromised, and checks to see that files have the appropriate modes and permissions set to maintain the integrity of your security level. The current version makes a limited attempt to detect bugs that are posted in CERT advisories.
Additionally there are other packages to not only audit your system configuration, but also automatically change the configuration to improve security. These are generally focused towards a specific Operating System however. A couple examples are listed below;
Solaris - Titan Security Toolkit -
http://www.trouble.org/titan/Linux - Bastille Linux -
http://www.bastille-linux.org/Additionally scanning tools such as Nessus (
http://www.nessus.org/ ) are able to find a number of unpatched network services. Coupled with the native patch management tools for the system, a comprehensive evidential trail may be created to prove that your organization was not negligent.
Failures to PatchOne of the biggest cases of security incidents is a result of unpatched systems. The failure to patch vulnerable systems in a timely manner results in major risk to the organization.
The vast majority of security attacks and compromises across the Internet today are only successful because of the number of unpatched systems. This is especially the case with Self propagating attacks (e.g. Worms) which rely on a combination of unpatched systems and poor Anti-Virus control processes to take hold initially and to subsequently propagate. Many of the Worms and Virus infections within organizations are still completed by “old” Malware which has had fixes associated with it for many years.
It is essential to develop patch deployment procedures that establish well defined processes within the organization to identify, test, and deploy patches as they are released. This step makes the patch maintenance process much more cost effective.
The patching of system vulnerabilities has become one of the most expensive and time-consuming recurring administrative tasks in the enterprise. The process is also prone to failure, as viruses and worms often use unpatched vulnerabilities as the initial entry point into a protected network, and then use other techniques for propagating once inside. Thus, any of the following factors could invalidate the process:
1. When a patches is not identified and installed in time to mitigate damage.
2. Vulnerable systems that were not patched when the patch was deployed.
3. Defective patches that do not properly close the vulnerability.
4. Defective patches.
Unpatched systems can result in other costs to the organization:
1. Costs connected with cleanup after a contamination or security violation.
2. Loss of revenue from system outages and production declines.
3. Loss due to loss of status and/or customer assurance.
4. Legal liabilities from contravention of sensitive records,
5. Loss or corruption of organizational data.
6. System downtime, inability to continue the activities of the business.
7. Theft of organizational resources.
When developing a patch maintenance process always ensure that the following points have been taken into account when patching security vulnerabilities;
1. Continuously Monitor systems for vulnerabilities
2. Identify vulnerable systems and determine severity based on a risk management process
3. Implement a work-around and create a response plan until a patch is available
4. Monitor and maintain a patch database for the organizations systems
5. Test patches for defects or adverse effects on your systems
6. For substandard patches, decide on an appropriate course of action
7. Recognize patch affects, such as a need to reboot systems.
8. Install patches in accord with a plan
9. Confirm patch effectiveness
10. Confirm patch does not create adverse situations
11. Review patch deployment
[1] From the original Tiger README file.
My LinkedIN Profile
