Patch management is just one of the necessary evils that cause us pain month after month with the onslaught of patches that come from various software vendors. If you are new to the patch management game, or have just taken on the duties of the patch administrator in your company or organization, here is a simple framework that can be used to begin or augment any company’s patch management process.
Note: The following documents by the National Institute of Standards and Technology (NIST) SP 800-30, Risk Technology Guide for Information Systems and NIST SP 800-40v2, Creating a Patch and Vulnerability Management Program provide checklists and additional documentation on establishing your own risk management and patch management frameworks.
Let’s first take a look at the framework:
— Step 1: Review your internal security policy
— Step 2: Take an inventory of your assets
— Step 3: Rank-prioritize your assets
— Step 4: Document existing controls
— Step 5: Perform a risk assessment of existing vulnerabilities that affect assets under your control
— Step 6: Patch systems
Now that we have identified a simple framework around how best to structure our patch management duties, let’s take a look at each of the steps individually and illustrate what we need to be looking for in each.
The first step is to review your internal security policy. This document or set of documents is usually a very high-level view of management’s expectations as it pertains to the security of all assets within the organization. What you are looking for, if it’s available, are the requirements in a process or procedure for the risk-management of informational assets and any timelines for patching critical systems. In my time as a patch administrator, I have rarely seen this step well-documented, but look at this as your opportunity to shine. Apply what you have learned here and provide a process and procedure around how you are going to patch and manage the risk to your systems according to the guidelines and provisions set forth in your internal security policy.
The second step is to clearly detail what assets you are responsible for, take the time to create clear documentation of the hardware, software, services and communication protocols your assets communicate over and identify which systems they are connected to both internally and externally. Clear and detailed documentation of your assets gives you a complete picture of which version(s) of firmware, software, services or communication protocols currently are in use making the known vulnerabilities easily identifiable. Anything which might be exploited by a threat (worm, exploit code, Trojan, etc.) would raise the risk-level on the assets owned or managed. There are various websites out there that have documentation on past and present vulnerabilities in various software products. I would highly advise you to sign up for their email lists, review the alerts, and take a look at your systems to see if you have vulnerabilities that you weren’t previously aware of.
The third step, and one of the most important, is to rank-prioritize your assets. This will give you a clear picture of what systems will need to be remedied and in what order they will need to be done. How you communicate this back to the business will reflect back on how your security remediation(s) allows the business to continue functioning. These actions combined with the documentation of vulnerabilities found in the systems will allow you to tailor your patching process to take care of highly-ranked systems with critical vulnerabilities first, thus ensuring the most critical business assets stay protected.
The fourth step is the documentation of the existing controls you have across your defined information assets and network as a whole. Questions you would likely ask yourself when looking at a new threat/vulnerability pair that could affect your systems are:
Control: Network firewall
— 1.) Is the firewall software version up-to-date?
— 2.) Does it have any known vulnerabilities that need remedied?
— 3.) Are partner networks, especially business to business (B2B) virtual private networks (VPNs) protected with a firewall interface, secured with their own sets of access control lists (ACLs) for inbound and outbound traffic? (Think back to SQL Slammer and how fast that spread. If you didn’t block port 1434/tcp you probably got slammed hard). This is an area of major risk for organizations because leaving B2B VPN’s wide open and trusting the other company, then you are basically accepting the risk of all the assets and the security posture on the partner network — This could raise your risk profile to an unacceptable level.
Control: Host-based intrusion prevention systems (HIPS)
— Are the HIPS functioning as required?
— Can I make sense of the logs produced?
— Can I write the rules to allow the HIPS to block malicious traffic and processed but also allow known-good processes to function accordingly?
— Are there any vulnerabilities in the HIPS software that need remedied that could be exploited?
— Can the HIPS block traffic from unwanted networks/hosts and alert on it?
Control: Antivirus
— Are the anti-virus engines, signatures up to date?
— Does my anti-virus have any additional protections that I can utilize to protect my systems, such as buffer overflow protection, built-in firewall features, port blocking, or process blocking?
Control: Host-based firewall
— Have I setup the firewall on the hosts to only allow the minimal amount of ports/processes to allow the workstation/server to do its assigned functions, and block everything else?
Control: Disabling unnecessary services, ports, processes
— Have I disabled all unnecessary services, ports and processes on my assets before they have been deployed to reduce the attack surface area? (GPO’s, HIPS, security templates can assist with this.)
— Have I identified specific port(s) that must be available, as an exception to policy, to communicate with internal/external hosts and limit the access to those ports accordingly?
— Have I identified specific ports that must be available, as an exception to policy, to communicate with internal/external hosts and limit the access to those ports accordingly?
Control: User permissions
— Have I limited the users in the local administrators group? Have I practiced theory of least-privilege when giving my users rights on there local systems? Do these actions reflect the vision of my policies, procedures and overall security policy?
The fifth step is the risk assessment on the vulnerabilities that affect your assets. This step requires the previous four steps to have been completed in a thorough manner. The task is to provide documentation via a risk-assessment of how the vulnerability/threat pairs affect your systems. I find that the qualitative risk-assessment methodology is a good method of easily determining this risk. In your documentation, I would include the following:
— A risk statement which details the vulnerability, what threats are currently known/unknown that would be able to exploit the vulnerability and the likelihood that those threats will reach your systems.
— A risk assessment matrix should show the threat(s), their likelihood ranked by impact, along with the asset’s priority-rank to provide you the impact that the threat will have if it does reach your network and bypasses your controls. (Note: Existing controls should help reduce the risk of threat(s) and thus lower or eliminate the impact and should be factored into the risk-assessment matrix.)
— The risk assessment should provide documentation to the common vulnerability engine (CVE) that details the threat and to any site(s) that have exploit code available, which would raise the risk of the threat exploiting the vulnerability in your assets.
— The controls that would reduce the risk should be documented and discussed in detail.
Make sure your immediate management receives a copy of your risk assessment and your findings, and agrees to allow you to start applying patches to your systems. This is not just a CYA step, but it is critical to keep management in the loop. If they don’t understand what you are providing them in documentation take the time to explain it, and make sure they understand the criticality of the situation in terms they identify with (downtime and lost business, productivity and revenue.)
The sixth step is the process of remediation (patching) of assets to protect from the vulnerabilities that threats to your environment can exploit. Here are some items that I recommend you have in place before you begin:
— Establish formalized and scheduled downtime for systems asset maintenance that coincides with the patch-management schedule. This needs to be agreed upon with the business and information owners in the organization, and should happen at the same each month. It is always easier to let the business work around a scheduled downtime each month than it is to have to tolerate random unknown downtime. Unscheduled downtime has a much greater impact to business operations.
— Create separate development, test and production environment(s). A good way of doing this is using virtualization software. This will offer a snapshot technology through which you can test patches and rollback any patches that cause an adverse issue on your systems. The development of a procedure(s) that augment your policies and allows for your established patching baseline to be applied across each region (development, test, and production) is a key task your patch management strategy. The procedures should take into account out-of-cycle patching and escalation of certain patches based on elevated risk to the organization and the approval process for these changes based on the risk to the organization. Now some readers may be wondering why I would be talking about patching development and test systems first, since they aren’t going to be ranked higher than any production-critical systems in the rank prioritization. If we black hat a little, what systems in an organization am I looking to exploit if I was to gain access? Likely it’s the test and development systems, which probably have looser controls and could be easily exploitable. Take the high road and hold your development and test systems to the same security standards as production.
After testing and sign-off from information system owners assuring that they have tested their systems are all looks good, deploy the patches to your assets based on the rank-priority created and make sure they are rebooted on the system maintenance schedule. Also make sure when you patch your workstations you force them to reboot at a time agreed upon with the business. Remember to have established back-out procedures if you run into trouble in production with certain patches.
Lastly, report the progress of your compliance with the latest patches applied and systems secured through the proper channels in your company or organization.
As a patch administrator, you sometimes have a thankless job, but a highly necessary job. If done properly and diligently you can have a positive effect on the security of your information assets. Your patch administration duties are part of a larger security framework, and the successful completion of your duties could mean the difference between whether your assets are properly protected from the latest threats, or ripe targets for the next hacker exploit.
When you are considering the risk assessment of the newest vulnerabilities and threats to your information assets, think globally, elicit information from other colleagues, and always keep in mind what controls you have in place and how those controls can be utilized to help reduce your risk.
The battle is ongoing and patch administrators are on the front lines. If we fail, our systems will fall and our companies will suffer.
Ed Ziots is a network administrator for a company in Providence, R.I.
