Why Patch Management is a Moving Target

Whether you use a centralized patch management system for your organization or rely on less sophisticated measures such as manual patching, you will often find that patch management is a constantly moving target. Patch management is a fundamental security task, but yet it seems to be one of the hardest in which to achieve a consistently high security “score.” And patching is only part of the issue. Reporting metrics that allow you to see tangible results are not always easy to obtain.

The data required for many measures of Cyber-security health or “scorecards” is often more readily pulled from a centralized system, and often organizations wish to report how many nodes have 100% of their security patches installed. This includes possibly a very large number of devices, depending on the size of your organization, including servers, desktops, routers, and switches. It also makes sense to focus efforts only on patches that are 30 days old and older, and that have not been superseded or replaced. The reason for this is because you are still testing the newest patches, and if you are in a very large organization have not yet had time to fully deploy all the new patches. Additionally, the older the patch, the greater the risk if that hole is still not closed. Plus, it doesn’t make sense to include patches that have been superseded by newer patches, as your scoring metrics would give erroneous results if those patches were included.

The purpose of this article is to address an example of an organizational patch status improvement effort and illustrate findings of an experiment to improve these patch statuses. This project was specifically aimed at the Microsoft specific security patches for the Windows XP Professional operating system, and all references to patches in this article will be geared toward those patches. This report will discuss the findings of that project, and describe ways that other programs can use to improve their own patching statuses. The results and recommendations are geared toward a fairly large organization. Your mileage may vary.

The Project:

I and my team recently performed an analysis of patching statuses to determine how to improve patch statuses for our entire organization. We belong to a fairly large organization with many business units, each business unit having their own IT staffs that manage their computers. One of the goals of this project was to look at ways to improve patching statuses and to document specifics concerning any anomalies that were found. By pushing out specific types of patches, and analyzing the results of those patch deployments, I was able to put together some strategies to help others with their own patching efforts. The analysis of patching efforts was performed as follows:

1) Concentrate on the "low hanging fruit" by focusing on the Microsoft critical security patches that are greater than 30 days old, and with the highest incidences of "Not Patched" statuses. This was done in phases:

Phase 1: Push out the outstanding Microsoft Office Service Packs plus Windows Defender signature files. These were chosen because they represented the largest number of un-patched vulnerabilities in the environment, as seen in the image below:

Phase 2: Push out the new Office patches offered as a result of Phase 1 completion above. This is important because applying a service pack will usually result in the computer needing additional patches that apply only to the new service pack level on the machine.

Phase 3: Push out the top 5 "not patched" patches resulting from phases 1 and 2 above.

Phase 4: Push out any remaining patches as appropriate.

2) Identify patches that are deploying successfully, but are not showing as "Patched" in our patch management system. This will include verifying that the patch is applied by using Microsoft Security Baseline Analyzer (MBSA) and Windows/Microsoft Updates.

3) Compile a list of patches that are having deployment detection signature problems and submit to the patch management system engineering for assistance with detection signatures.

4) Identify computers on the patch management system that are not checking in to get their patches. This will include looking at deployment reports to see which computers have not checked in no more than 24 hours after the deployment has been sent.

Findings:

As shown in the image below, patching statuses tend to fluctuate dramatically from day to day. This can be caused by machines falling in and out of patch status due to new patches being released to replace older versions of the same patch. For example, the Windows Defender DAT files are released approximately every three days. Rather than releasing a new patch each time, our patch management system simply replaces the existing patch with a new revision of the same patch. As the new revision is released, the computers fall out of patch status because they have the older DAT files. As the IT staffs push out the DAT files, the patching statuses go back up.

Some more specific examples of patching issues include:

Patches That Change Frequently:

The Microsoft Windows Defender DAT Files: These definition files are released by Microsoft approximately every three days. Since they are categorized as Critical-01 patches, they cause the patch statuses to fluctuate significantly every time they are released, and then again when they are subsequently deployed. This patch was the single largest reason why patch statuses greatly fluctuated from day to day.

Patches That Cause Other Patches to be Applicable:

Service Packs: Once installed, these patches tend to make the computer detect as needing additional patches. Some patches may only apply to a newer service pack level, and were thus not applicable to the machine until the latest service pack was installed.

Patches With Deployment Issues:

Microsoft Office Patches: These patches in particular were found to have a number of difficulties when deployed. In some cases, the patch is deployed, and completes successfully according to the patch management server’s deployment status. Even though the patch deployed successfully, the patch did not apply because it produced an error message that it could not find the Office installation files. In other cases the patch fails, for the same reason as stated above. Ensuring that the installation files have not been removed manually, or through the Disk Cleanup procedure typically resolves this issue. In some cases, it was necessary to uninstall and reinstall Microsoft Office, again ensuring that the Office Installation files are not removed.

Microsoft .NET Framework 1.1 SP1: This specific patch typically fails when being deployed. The reason for failure was found to have been on computers that also have the .NET Framework 1.1 Hotfix (kb928366) installed. The resolution is to go to Add/Remove Programs and remove this hotfix, deploy the .NET Framework 1.1 SP1 patch. The computer will then likely show up as needing the MS07-040 patch. Deploy MS07-040 if needed.

Patches With Detection Issues:

MS08-018 for Microsoft Project: This patch is not supposed to apply to versions of Project 2003 that have service pack 3 applied, but our patch management system incorrectly identifies the computers with Office 2003, SP3 as needing it. This is still an open issue with engineering and will hopefully be resolved soon.

Patch Management System Housekeeping Issues:

If you are using a centralized patch management system, and you are using the various reporting features to obtain your patch statuses, then it is important to take a look at housekeeping. One important thing I found in my testing was that simply deleting stale accounts out of the patch management system increased patch statuses.
The below image is an example of how much difference in patching status can be achieved just by doing housekeeping and nothing else. The patch status for the month of April was taken at the end of the month, and the patch status being shown for May was taken at the beginning of the month after clearing out all the dead computer accounts:

The result was that patching statuses for every business unit (BU) except one improved, with an overall improvement going from 42% to 58% just by clearing out dead computer accounts.

Recommendations for Improving Patch Statuses:

If you are a large organization, use a centralized patch management system. The ability to gather data on the whole organization is vital to enabling you to keep track of gaps in patching efforts.

Make sure that your centralized patch management system is being properly maintained, in terms of housekeeping. Get those stale computer accounts out of there.
Start small. Break your patching efforts into pieces, and go for the “low hanging fruit’ first. Look for the patches where the most computers need them, and start there. If you have a lot of these in your environment, break them up into groups and deploy them over several deployments if needed.

Test, test, test! If you are trying to bring an entire organization up from a dismal patching status, don’t try to push them all at once, and be sure to perform testing to make sure to discover if any patches break anything.

When pushing out service packs or roll-ups, be aware that installation of a patch of this type will often result in additional patches being applicable that were not applicable previously because of the new configuration.

Monitor patch deployments and subsequent detection results. In cases where patches deploy successfully but detect as still not patched, check to see what error messages are occurring during the deployment. In the case of Microsoft Office patches erring out, for example, ensure that the Office installation files have not been inadvertently removed from the computer.
Develop a patching routine and communicate this with your end users. Get them used to the fact that you will usually be pushing out patches the same night of the month (if they are in your central offices) and to leave their computers on that night. For remote users that receive their patches through your centralized patching system, make sure they are aware that patches will be coming to them on a certain day and give them instructions for how to properly receive the patch:

Example:

When coming in through the corporate VPN to replicate email or other databases, ensure they leave the computer on long enough to receive patches on the day you deploy them.

Other Follow-up Action:

Remember: Patch management is not something that you do once to get caught up then forget about. You have to treat patching as a constantly moving target, and always follow-up on patching efforts. Get into the habit of always keeping an eye on patch statuses and results of patch deployments.

Determine if an application is the mandated or authorized solution to be used. Sometimes you find that you are chasing patches for products that are no longer in use or maybe even not even authorized on your systems. Why patch a product that isn’t even needed? Removing it is more secure and less time consuming than patching it.

Continue to monitor patching efforts and publish lists of those patches which remain as the most likely to be causing degraded patch status.

Assist IT staffs with troubleshooting computer detection, discovery, and patch assessment issues that may exist. It could be that the patch assessments on a certain machine are out of date and not even accurate.

Monitor patch management and security discussion forums such as the patchmanagement.org listserv. If a particular patch is causing breakages or deployment issues, this is where you will find out about it the quickest.

Wrapping It All Up:

Getting a handle on patching statuses can be a real challenge for a large and geographically dispersed organization. A centralized patch management can greatly assist your efforts, particularly if you are in a large organization. Break your patching effort up into phases, and go for the “low hanging fruit” to get caught up. Be sure to continuously monitor deployments and patching statuses, and address issues where the deployments are not starting as they should, or the patch is not detecting as it should.

Investigating False Positives and Other Security Anomalies Part 2

In Part 1 of this series, I talked about investigating vulnerability scan results where the scanner alerted on something and further investigation revealed that the vulnerability was a leftover file from an upgrade. For example, the computer was upgraded from Microsoft Office XP to Office 2003. As far as Windows/Microsoft Updates and the enterprise patch management system are concerned, the computer is running Office 2003 completely patched for the installed software. An in-depth investigation was performed which involved going into the scanner session logs and finding out which file caused the scanner to alert on the vulnerability. Indeed it turns out to be a left over file from Office XP that Office 2003 doesn’t even use. Renaming or removing the file fixes the vulnerability, and Office continues to work normally, so all fixed, right? After all, it was a pretty straight forward fix – we knew that a Microsoft product was upgraded, the new Microsoft product didn’t clean up after the old version, and a vulnerability was left on the box. The entire solution of renaming an old Office file seemed logical and one thing was related to the other.

Not so fast! Let’s move on to the next type of scenario in the investigative process that is even a little more difficult to troubleshoot. The vulnerability scanner alerts on something that experience showed was easily remediated by renaming a file or removing it. The vulnerability was related to a left over file, and getting rid of it resolved the vulnerability – for the time being. Later on, the computer is scanned again and the same vulnerability has returned. Nothing had changed. Noting new was installed, and the same versions of the Office software are still on the machine. So let’s take a more in-depth look at this type of scenario and see what happened.

Scenario 3: A scan is run, and the now much discussed vulnerability related to MS Office products has appeared on several computers. The previously developed fix of renaming or removing a vulnerable left-over file proves successful. Later, these same computers are scanned again. Many of them show that the vulnerability has been successfully remediated, but on a few of them, the vulnerability has reappeared. Investigation into the scan session logs shows that the previously renamed vulnerable file is again the culprit causing this vulnerability to appear. Physical inspection of the file system on the target computers verifies that the renamed file is still in its renamed form, but now another copy of the original vulnerable file is on the box. One thing interesting is noted about these computers: They all something in common – they all a have a piece of third-party software (not Microsoft software) installed. The software title and vendor is not important here, and I don’t want to be accused (or worse) of name calling and accusing on the Internet, so I just won’t get into a name-calling session here.

Further in-depth troubleshooting reveals that again renaming the vulnerable file, and performing an immediate scan shows the vulnerability remediated. Now for the next step: verifying that all of the software works. MS Office works fine, the corporate email client works fine, as do the web browser and other normally used applications. The computer is scanned, and the machine is still clean of the vulnerability. Since all of the computers with this problem had in common another piece of software, this particular application is tested last. The application in question is started up, and produces an error. The error is that there is a corrupt or missing DLL file, and is prompting the user to install the original software CD for this application. This is done, and the software repairs itself. The application now runs normally. Another scan reveals that the vulnerability is now present. Looking at the folder on the computer where the vulnerable file resides, we see that sure enough the renamed file is still there, but the original vulnerable file has returned.

In this case, it is clear that another piece of software (not from Microsoft) is related to, and interacting with, the Microsoft native files for an MS Office installation. Not sure what to make of this, a call to the vendor’s tech support reveals that the suspect Microsoft DLL may be used by their software, but they are not sure. This will have to be investigated further with the software developers. There are some known versions of the DLL file that are not vulnerable, so the hypothesis was that replacing the offending DLL with a non-vulnerable version will fix the problem. Replacing with a non-vulnerable version allows the software to operate normally and error free. A re-scan of the computer now shows that it is vulnerability free also.

Note: As of this writing, the software company in question has no intention of fixing this vulnerability in their software. I was in communication with them today and the tech support person I spoke with stated that the company will not be releasing a patch for this product - it is Microsoft's problem, evidently. This brings up the issue that a piece of third party software is latching onto a known application (Microsoft Office) for its functionality, and the vendors are not keeping up on the security ramifications of their software installing known vulnerabilities onto a computer.

Investigations Start with Patch and Scan Testing Process:

It is quite clear from the events discussed in the two parts of this article that a proactive strategy for patching and scanning is in order. Such a strategy will ensure that vulnerability scanning is built in to the patch testing process so that 1) patches will be verified as being applied and that they do not have adverse affects on the system, and 2) the vulnerabilities that the patch is meant to target are actually being remediated. Testing the patches as they are received will ensure that they apply properly and do not break applications. Then a follow up of deploying patches to a pilot group will give the patches more rigorous testing in a real environment, and allow IT staffs to clear up any problems quickly before deploying to the full production environment. Once this is done, a follow-up scan on those same pilot computers will verify whether or not the applied patch mitigated the vulnerability. If it does, then the desired goal was achieved. If it does not, then it is time to have an investigative process to find out if 1) the patch is not doing its job, or 2) the scanner is alerting on a false positive condition. This process will allow for the discovery of scanner alert anomalies as soon as possible, and a fix to be developed before the scanner hits the full production environment.

It is important to note that testing patches and developing vulnerability remediations can be tricky in that hidden causes will sometimes not be found right away. This was evident when scenario 4 as described above brought to light newly discovered problems for a situation that was thought to be previously resolved. For this reason, it is important to carefully choose those users who will be in the pilot group for the second phase of patch testing. They should be fairly computer savvy users who know how to properly respond to error messages, and that they also know how to carefully document any problems that they run into. This is the group of people that will know that these errors are possibly going to occur, and won’t fly off the handle when they do. They will know to calmly notify their IT support staff, and won’t panic and click through all the error messages until the IT staff has had a chance to see them and work the issues. So having said all that, let’s take a look at the chronological steps that would take place in this whole testing and investigative process.

The Steps (in chronological order):

1. The new patches are released from the vendor and the new cycle of patch and scan testing begins.
2. Non-production machines in a lab and/or virtualized environment are scanned and verified clean of all vulnerabilities before patch testing begins.
3. All discovered vulnerabilities are remediated on the designated test machines before patch testing begins. Those that cannot be remediated are documented with the reason why they cannot be resolved (ie false positive, etc.).
4. The new patches are first tested on the non-production machines in lab or virtualized environment.
5. All applications on the lab machines are tested for proper operation, and that no errors are experienced on the machines.
6. The scanner profile is verified to have the proper checks for the latest patches and other newly discovered conditions.
• Note: This often happens after the new patches are released, and it can sometime take a few days for the new scanning profiles to be configured on the scanner. However, steps 1 – 5 can be performed prior to the new scanner profiles being configured. Step 7 and beyond, however, are dependant on the scanner being configured to look for the new patches that are being tested in this phase.
7. A test scan is performed on the lab machines to verify that they are free of vulnerabilities. Any vulnerabilities found are investigated and resolved.
8. Patches are deployed to the designated pilot group of production users.
9. The designated pilot users are to use their computers for a pre-determined testing period. Three days to one week is recommended for this testing period.
10. A sample of this pilot group is selected for another verification scan, and the scanner is run against these machines to verify that the machines are clean of the vulnerabilities that the new patches were meant to mitigate.
• Note: This step can be done concurrently with the operational testing period described in step 9.
• Any vulnerability conditions that are related to the new patches that exist as a result of this scan are investigated, documented, and solutions determined.
11. The new patches are deployed to the remainder of the production machines.
12. Full scan of the production environment is run.
• Note: The full scan of the production environment to look for the new patches should take place only after allowing sufficient deployment time. This will vary depending on the size and geographical diversity on the organizations.

Wrapping It All Up:

Having a standardized, methodical approach to patching and scanning will help give more structure to the whole process. Using a checklist, like the one above or a locally developed checklist will help ensure that testing is performed properly. It is easy to overlook things, and very easy to be led down an incorrect path when investigating the types of situations mentioned in this series. It is important to use several different tools and analyze the similarities and differences in information that each of the tools provides.

So the lesson learned in this whole exercise is that IT staffs should be less prone to jumping on the “False Positive” bandwagon, and more inclined to using research and investigative techniques to find out what is really happening. Don’t rely on just one analysis tool or set of data to make a conclusion. Security is hard work, and often involves many steps to get it right. Overlooking even a single vulnerability by claiming that it is a false positive gets it off your to-do list, but doesn’t actually clear it up – your machines are still vulnerable. If the bits are on the box, you MUST remediate. Calling it a false positive when it is not does not constitute a valid remediation strategy.

Use some industry respected assessment tools, come up with a good (consistent) methodology, search for clues, and above all else – do some research and investigation! As a line from the movie Apollo 13 goes – “Work the problem! Don’t make it worse by guessing!” Guessing that it is a false positive is a dangerous habit to get into.

Investigating False Positives and Other Security Anomalies Part 1

Find vulnerabilities on the computers on your network; apply a patch, and all done, right? Well, maybe, and maybe not. Part of any good security program includes using a variety of tools to assess the risks in your environment. Specifically, I am talking about the periodic vulnerability assessments that are performed on the desktop and server computers in your network. Let’s assume you are an all Windows shop for the moment; On the most fundamental level, you get this risk assessment done for you every time you visit the Windows Updates site on the Internet. The Windows Update site uses a scanning engine to determine what is installed on your computer, what the most current patching levels are, and whether or not your computer has those patches. Same with your antivirus software – you are given the latest updates based on the most currently known threats and whether or not you currently have the definitions for those threats (in this case viruses).

Unfortunately, Windows Updates and your antivirus software aren’t the final and definitive answer about the status of your computer’s security level. The same is true for any other single security assessment tool. In a large enterprise environment, it is often necessary to use a variety of tools to assess whether or not you are protecting your systems. The information from one can often be used to validate or refute the information from the others. In other words, having multiple tools gives you a system of “checks and balances” in determining the total picture. Having multiple tools is also a good way to aid in investigations concerning the validity of security assessment information.

The purpose of this article is to give some definitions of a few types of vulnerability assessment tools, discuss definitions of types of vulnerability indications, and discuss situations where investigations may reveal a different story than what was originally thought to exist. It is important to understand that vulnerability scanning and other assessments aren’t necessarily straight forward or cut and dried insofar as the information they can tell you about what vulnerabilities exist. You often have to rely on your skills as an investigator to uncover the real story and figure out how to truly remediate the situation.

First some definitions: It is useful to understand the types of vulnerability situations that may be incurred at any given time. The true existence of a vulnerable item or configuration must be known in order to remediate or mitigate the vulnerability. It is also important to understand the different types of tools used to obtain vulnerability information. To get an idea what I mean by that, take a look at the following definitions:

Patch Management System: A system, usually centrally managed, that is used to assess patch statuses on end systems, determine which patches are applicable, and which patches need to be applied based on patching levels of the target system. Such a system can then be used to deploy the Patches To the end nodes, and return a follow-on assessment of whether or not the patch successfully applied. Windows/Microsoft Updates and Microsoft Baseline Security Analyzer (MBSA) are fundamental examples of this. Large enterprise environments may choose to use Microsoft WSUS or SMS, or third party tools such Shavlik, Ecora, or PatchLink. These types of systems usually look at what patches are needed based on what operating system and software are installed.

Vulnerability Scanner: These types of tools are a bit different in scope and purpose that patch management systems. Whereas patch management systems look for needed patches based on what is installed and operating on the system, a vulnerability scanner usually looks deeper for the existence of certain files and registry entries, whether or not the files and settings are actually used. Scanners can also look for other vulnerable configurations, such as too many admin users on the box, passwords that don’t expire, and similar items. Vulnerability scanners typically have scanning profiles that are based on CVE data and other vulnerability definitions. These profile definitions usually tell the scanner to look for the existence of certain file versions and date stamps that are known to be vulnerable. It doesn’t matter whether or not these files are actually in use, or are just left over files from an upgrade. If they exist, the computer is vulnerable. The saying often heard in the security community: “If the bits are on the box, you MUST remediate.”

True Positive: This means that a vulnerability item has been found, and it is correctly identified as existing on the computer. This is what is commonly referred to as a “known/known” situation.

True Negative: One or more vulnerabilities that were being tested for were not found on the target machine, and they were correctly ruled out from existing on the machine. Again – this is a situation of “known/known” data.

False Positive: Vulnerability was detected on the target, but investigation reveals that the vulnerability was incorrectly identified. The danger here is that this may be ignored in the future, even if the vulnerability detection later reveals a true positive situation. The other danger is that something is an evident false positive, but investigation reveals that another condition exists which caused the false positive to occur. Is this, then, really a false positive? More on that later.

False Negative: A vulnerability condition exists on the target machine, but the vulnerability assessment tools failed to identify it as being present. This is the most dangerous of all situations – your nodes are vulnerable, but you don’t even know it.

For the reasons alluded to in the definitions above, it is necessary to use a combination of these tools to get a true picture of an end node’s vulnerability status. Multiple tools that agree on vulnerability information can leave you with a pretty good level of confidence about whether or not vulnerabilities exist. If the tools don’t agree, however, then that should immediately cause you to launch an investigation to determine the true status. Unfortunately, the false negative situation may still exist. As mentioned before, this is truly the most dangerous situation where your vulnerability status is concerned, because you really “don’t know what you don’t know.” And your tools may simply all be in agreement that a vulnerability does not exist when it really does. Fortunately, this particular scenario in which all tools agree on a false negative is very rare.

False Positive? For an example of how a seemingly “false positive” situation exists that is worthy of further investigation, consider the following scenarios:

Scenario 1: A computer on the centralized patch management system shows that it is completely patched and up to date. Even a visit to the Windows Updates site reveals that the computer is up to date – no critical patches are offered. A later scan with a vulnerability scanner reveals that a vulnerability item exists on the computer. An in depth investigation includes using multiple tools to verify the vulnerability – the patching tools once again all say that the computer is patched, the vulnerability scanners again all say that it is vulnerable. Further investigation leads to a review of the session logs generated when the vulnerability scanner performed its scan. The logs reveal that a particular DLL file exists in the \Common Files\Office10 folder of the computer. You immediately say “Wait a minute!” because you know that the computer is now running MS Office 2003, which uses the Office11 folder for its files. The real story is that the computer was upgraded from MS Office XP to MS Office 2003, and the vulnerable DLL file is just a leftover. Here it is a seemingly false positive, but really and truly, the bits are on the box – the box is vulnerable. “If the bits are on the box, you must remediate.”

In the case above, testing revealed that simply renaming the file removed the vulnerability. This is done, by the way, in case doing so breaks an application, and roll-back is needed to troubleshoot. If it turns out that this file is indeed needed by some other program, then a non-vulnerable version can be obtained from the vendor and the vulnerability will be resolved. Exploits often target a file of a specific name, and if the file is not found (even if it is renamed) then the exploit won’t be effective.

Scenario 2: Your patch management system says that your computers are all the way patched, good to go (hint: all the way patched for the current software installation). Your vulnerability scanner then says that the computers are vulnerable for several MS Office patches. You double check, and sure enough, the patch management system says that those patches are applied. A visit to Windows Updates offers you no critical patches. So you dig out your MBSA tool and do a few scans. MBSA even says that those particular patches are applied. But wait a minute: You look further into the MBSA scan data and it reveals that a service pack for MS Office has not been applied. You apply the service pack. You perform another vulnerability scan – the office patches are still needed. Now you go to the Windows Updates site and your centralized patch management system, and wouldn’t you know it? Those patches called out by the vulnerability scanner are now needed. You apply the patches and your are now clean.

How did this happen? Remember: I gave you the hint in the beginning of the scenario that the computers were patched for the software that was currently installed. Installing that MS Office service pack significantly changed that installation and the old patches that were installed only applied to a computer that did not have the latest service pack. There were newer versions of those same patches that applied to the latest service pack. You applied these new patches, and then all of your assessment tools show that you are now clean and fully up to date.

Wrapping it All Up:

Vulnerability assessments are a vital part of your security program, and often involve using multiple tools to be effective. One tool will act as a system of “checks and balances” against each of the others. It is easy to get lulled into a sense of false security if only relying on one tool – it is even possible that all of your tools won’t find all of the problems. Remediation is not always straight forward either. Applying the patches doesn’t fix everything, and sometimes your system is vulnerable for things that can’t be patched. In some cases, changing a configuration by simply applying a service pack drastically changes the picture.

It is often necessary to rely on investigative skills and go in directions that are seemingly irrelevant.But by relying on multiple tools, performing sound investigations, and keeping up with due diligence, it is possible to minimize risk on your network and keep the threats somewhat in check.Remember: You will never eliminate risk completely.You can only hope to minimize it.But by having valid data from a variety of sources, you can make prudent risk assessments and ensure that your environment is as secure as possible.

On to Part 2

Additional Resources:

Microsoft Baseline Security Analyzer: http://www.microsoft.com/technet/security/tools/mbsahome.mspx

Vulnerability Scanners Explained:
http://www.windowsitpro.com/Article/ArticleID/43888/43888.html

Free Vulnerability Scanning Tools:
http://netsecurity.about.com/od/vulnerabilityscanners/Free_Vulnerability_Scanning_Software.htm

Retina Single Audit Scanners:
http://www.eeye.com/html/resources/downloads/audits/NetApi.html

Foundstone Free Scanning Tools:
http://www.foundstone.com/

The Dirty Dozen: 12 Ways to Kill False Positives:
http://www.bcs.org/server.php?show=ConWebDoc.9384

Do You Have a Method For Testing Patches in the Enterprise?

In light of Microsoft’s release of over thirty patches this summer, I figured it was time to discuss security patch testing methodologies. There are at least two basic schools of thought about when, how and even why to test new patches when they are released by the vendors. It all boils down to risk analysis. You are weighing the risks of being hit with an attack that one of these patches could have prevented with the risk of potential damage that the patch itself could cause when applied. After all, the business of business is business. Either one of those risks could cause your network or individual computers to be inoperative and keep your customers from doing their work and adversely affect your business.

Read the full article

Hotfixes, Patches and Updates – Oh My!

This has been a very busy week in the world of computer patching and updates. And we can’t just blame it on Microsoft.

Well – we can credit a huge share of upcoming patches to Microsoft. Next week on “Patch Tuesday” Redmond is releasing ten security patches for Windows, two for Office products, two non-security patches, and the regular Malicious Software Removal Tool release. In case you haven't been keeping track - that's over 30 new patches this summer alone!

Summary
=======
On 8 August 2006 Microsoft is planning to release:

Security Updates
. Ten Microsoft Security Bulletins affecting Microsoft Windows.
The highest Maximum Severity rating for these is Critical. These
updates will be detectable using the Microsoft Baseline Security
Analyzer and the Enterprise Scan Tool. Some of these updates will
require a restart.
. Two Microsoft Security Bulletins affecting Microsoft Office.
The highest Maximum Severity rating for these is Critical. These
updates will be detectable using the Microsoft Baseline Security
Analyzer. These updates may require a restart.

Microsoft Windows Malicious Software Removal Tool
. Microsoft will release an updated version of the Microsoft
Windows Malicious Software Removal Tool on Windows Update, Microsoft
Update, Windows Server Update Services and the Download Center.
Note that this tool will NOT be distributed using Software Update
Services (SUS).

Non-security High Priority updates on MU, WU, WSUS and SUS
. Microsoft will not release any NON-SECURITY High-Priority
Updates for Windows on Windows Update (WU) and Software Update
Services (SUS).
. Microsoft will release two NON-SECURITY High-Priority Updates
on Microsoft Update (MU) and Windows Server Update Services (WSUS).

Although we do not anticipate any changes, the number of bulletins,
products affected, restart information and severities are subject to
change until released.


Can’t let Microsoft have all the fun. The Firefox browser people have released yet another update for their ever-growing-in-popularity browser. This makes two updates in as many weeks.

Mozilla has released version 1.5.0.6 of Firefox, approximately 1 week after releasing version 1.5.0.5. This release addresses an issue with playing windows media content in the Firefox browser. More information
here: http://www.mozilla.com/firefox/releases/1.5.0.6.html


McAfee has released an update for their security center products:

McAfee has released a patch for Security Center products including:
antispyware, internet security suite, personal firewall plus, privacy service, quickclean, spamkiller, virusscan, and wireless home network security. Description of the issue from McAfee:

"This attack requires the consumer to perform certain actions in order to be exploited. For example receiving an e-mail from an un-trusted source and clicking on a malicious URL. McAfee suggests that a consumer not click on any URLs in an email that comes from an unknown or non-trusted source. A successful exploit of the security flaw would allow an attacker to remotely execute arbitrary code on the machine running the indicated software. These arbitrary commands would be limited to the privileges of the user which the product is running as on the machine. In order to accomplish this exploit, a user would have to force internet explorer to render a malicious web page which has been generated by the attacker. The attack requires reverse engineering of the software as well as the assistance of the user."

More information in their security bulletin here:
http://ts.mcafeehelp.com/faq3.asp?docid=407052


And finally, if you have a laptop (or other computer) that uses the Intel/PRO series of wireless chipsets, your drivers are likely to be vulnerable to attack. Follow the links below to find the correct driver download for your affected products.

This is not going to be fun or easy to fix. On 8/1 Intel released information about wireless driver and proset software vulnerabilities which affect the 2100 and 2200 Intel wireless components which are in every single Dell laptop we have. The driver vulnerabilities are critical and can be used to take over full control of a machine. Details at:
http://support.intel.com/support/wireless/wlan/sb/CS-023068.htm

Anyone doubting their criticality should read:
http://www.theregister.com/2006/08/03/wifi_driver_hack/
It is recommended by Intel that users check with their manufacturer (Dell) to see if they are going to release their own version of the drivers since manufacturers have the option of making changes which could cause problems with the Intel OEM drivers. I checked Dell's website and as of today they don't have a new version so communication needs to be made with Dell to determine if and when they will be releasing new ones, and if they aren't, whether their will be any problems with the OEM drivers.

Happy patching, folks. Be sure to test these patches and patch quickly.