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.

The First 90 Days of an Operating System

People who know me know that I often complain about Microsoft systems because of the constant vulnerabilities they seem to have. "patch Tuesday" is always an interesting time for me, as it typically provides a lot of work. But I read a recent article that outlined the vulnerabilities that occurred within the first 90 days of the life of various operating systems. It was funny to see that of all the operating systems discussed in the article that Red Hat Enterprise Linux 4 Workstation Reduced actually led the way with the most vulnerabilities in the first 90 days. Also mentioned were Ubuntu Linux, Novell SLED 10, and MAC OSX 10.4, all of which had more vulnerabilities than both Windows XP and Windows Vista combined.

It appears that 1) Windows Vista has made great strides in plugging security weaknesses, and that 2) The Linux folks need to reassess their stance on just how much more secure Linux is than Windows. A thought from someone who tests and deploys patches on Windows systems from month to month: I still see a lot of work to be done, but this article really makes us security professionals step back and realize that security vigilance is important, no matter what OS you are working with.

I guess what I am trying to say here is that there is a lot of stereotypical information about where the problems are. As I mentioned in a previous article: Microsoft is really not the problem. The problem is in that people get so wrapped around the axle on making assumptions about that which they are familiar with. For example, the Linux people will swear that Linux is flawless, and the Novell people will feel likewise. Much vigilance gets lost regarding educating users, and just keeping up on the day to day maintenance of the systems you do have. Educate your users, keep your systems patched, and at the end of the day, you Windows users will have an environment that is every bit as safe as that which the Linux folks claim to enjoy.

Article Link: http://www.csoonline.com/pdf/Vista_Vuln_Report.pdf

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

Daylight Saving Time 2007 - What Does it Mean to the IT Community?

Watch the news in the coming weeks - you are likely to see at least a few articles and reports of expressed concern over the new daylight saving time date change which takes place in 2007. In case you are not aware, daylight saving time (DST) has changed to March 11 this year instead of the first weekend in April as has been previously observed. This change was caused by the enactment of the Energy Policy Act of 2005, which President George W. Bush signed on August 8, 2005.

Initially, my inclination is to think that it is no big deal; I’ll just have to set my clock ahead a few weeks earlier is all. You would think that an event like this would simply come and go, we would set our clocks, VCRs, and computers, then life would be good. But when you think about it, you realize that with our current level of technology dependence, we rely on computers and cell phones for everything these days. Meeting schedules in our computer calendar programs, certain database events, when an online bill payment transaction is posted, even what time we can call on our cell phones to get the off-peak calling cost breaks, are all tied very closely to the time on our automated systems. Computer, network, and other system time accuracies are more critical than you might think.

There is a considerable amount of buzz about the DST issue in the patch management discussion groups on the Internet right now, so this must be a somewhat serious issue for the IT community. Today, for example, I think I received on the order of 50 or so emails on the DST patch (for computers) issue alone. Believe it or not, your computer is not the only thing that will be affected by the change. It is possible that network devices (such as routers and phone system components), PDA's, cell phones, and the like will also be affected. Some are equating this to a Y2K kind of event - on a much, much smaller scale, of course, but significant nonetheless. One article I read from Gartner suggested that companies form project teams to deal with this, and even have people on call and present to watch time changes to make sure the event goes smoothly, and that all systems are operating normally.

Although it will indeed be on a much smaller scale, here are some possible consequences of the DST change that people in the IT world (and consumers as well) are concerned about:

• Bank transaction times - people worried about payments not being credited properly.
• Cell phone time syncs - people being charged for peak minute usage when they are really in a non-peak time (i.e. after 9:00pm).
• People in organizations where their computer and/or Internet access has access time restrictions, may not be able to log in and do their work - could that be someone you have to do business with?
• eBay and other online auction ending times being affected.
• Missed deadlines for time sensitive things - those folks who like to submit things online at the last minute might end up an hour late?
• Incorrect departure and arrival times for airlines or other transportation.
• There is not a patch for Windows 2000 and Windows NT servers – if you are still on these platforms, the patching process is going to be manual.
• Networking equipment (certain routers) may experience issues when the new DST time change occurs, and again when the previously recognized DST date occurs.
  Applications that rely on Java Runtime Environment rules for time will report time incorrectly from March 11 – April 2 2007, and from October 29 – November 4, 2007.
• Java Applications return incorrect time after using Microsoft timezone.exe tool to update Windows (IBM Article: http://www-1.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&uid=swg21250503)
• Known DST bug in Palm Treo 700w devices: http://mytreo.net/archives/2006/04/treo-700w-daylight-savings-time-change-bug.html
  

There are a lot more possible outcomes being discussed. No need to freak out though – I just wanted you to be aware that if things seem a little strange when trying to conduct business on March 12 - now you know what might be causing problems.Kind of scary in a funny sort of way (or is that funny in a scary sort of way), but one of the network administrators in the patch management group I participate in had the following to say:

-----------------------------------------------------------------------

Just had a conversation with Verizon Wireless about DST and the Treos weare using. Very funny if a little scary.

According to the Tech I spoke with and the email I got all the Treo users need to do is turn off their Treo and turn it back on after the time change.

However they both said something to the affect of "You don't need to worry about that until April" (emphasis mine)

Apparently Verizon has not yet heard of the new DST changes.

---------------------------------------------------------------------

The patch to change your computer is available now on Windows Updates, but it is an optional software patch, so you won't get it automatically (yet). You have to visit the Windows Update site, select “Custom” instead of ”Express,” and select the Optional, Software series of patches. Be sure to install any Active-X controls when prompted to do so.

(click image to see full size view)

Next, look for the KB928388 patch as shown in the image below.

(click image to see full size view)

As of this writing, I am waiting to find out if Microsoft will make this Windows patch a critical update. Keep in mind, however, that if you are running systems with Windows 2000 or prior, a patch will not be available at all – you have to manually make the change in the registry settings and elsewhere that define when DST is changed on the computers. Either that or turn off DST altogether on those systems, and make the time change manually twice a year. If they do indeed move this up to critical, then those of you who have Windows Updates set to automatic download/automatic install will get it - well - automatically. They better do it soon, though - there is only one more "Patch Tuesday" (February 13, 2007 before the DST change in March. The March “Patch Tuesday” occurs the week following the Sunday that DST changes.

All in all, it is important not to panic. Watch the news, get the patch, and pay close attention to things that you do that require time synchronization to take place. Visit your cell phone company’s web site to find out what implications the DST event will cause for you.

Some sources you might find interesting:

• About.Com Article: http://geography.about.com/cs/daylightsavings/a/dst.htm
• CNet Article: http://news.com.com/Daylight+saving+change+could+confuse+gadgets/2100-1041_3-5823792.html
• EdgeBlog Article: http://www.edgeblog.net/2007/daylight-saving-time-the-year-2007-problem/
• Microsoft: http://support.microsoft.com/kb/914387

Addendums:

This article will change as new updated information is received. Check back often.

It’s All About The Social Engineering, Baby!

I’ve said it a number of times, and at the risk of sounding like a complete cynic, I will say it again: The biggest threat to computer (and information) security is the people who use them. Or, more appropriately, people who use computers and information technologies in a significantly “unaware” state. To give you an idea what I mean, let’s take another fairly ubiquitous implement in our society, the automobile. Why are there so many accidents? It’s not the bank robbers or the murderers and rapists (in other words, “criminals”) causing them. They are caused by everyday people not paying attention to those around them, people who think that rules of the road don’t apply to them, and even, dare I say, people who just don’t give a damn about those around them. I mean, why is it that people can get into horrific accidents driving down a completely straight piece of highway, like I-25 here in Colorado? It’s because people jump in those 2,000 pound pieces of hardware and just blast off down the road as if they were the only ones on it, completely oblivious to anyone else who may be around. As long as they get where they are going, they don’t care how they got there, and as long as no one else causes them inconvenience, whatever they do is fine.

Well – our love of computers is the same way as our love of the automobile. Computers and communications devices (such as cell phones) are such a ubiquitous and necessary part of our daily lives, that to go without email or our phones for even one minute would be disastrous. And our ability to click on any Internet link we want, and forward every email joke we get had better not be impeded in any way. This idea is at the very heart of many cyber-attacks these days. The bad guys know that people can be duped into just about anything – spreading email here, clicking on a link there, giving out information over the phone. It is very easy for the bad guys to plant a very innocent looking email, spam it out to the whole world, and then sit back and watch as the ignorant masses of scurrying mice blindly follow the bread crumbs. This, in essence, is what “social engineering” is all about. Social engineering encompasses a wide variety of things, such as me pretending to be the help desk and calling you up to get you to give me your network account password. Or diving through your trash to find out what usernames and passwords you had scribbled down and unknowingly thrown away. Or, how about me the nosey passerby shoulder surfing while you arrogantly (and show-off-ishly) flaunted your laptop in a busy airport or coffee shop? You know, in all my journeys through airports, I have gathered more information from listening to people yell into their cell phones that, if I were a bad guy, could be used against them (and their companies). I sat waiting for a flight from Rochester, NY one time and listened to some guy give an entire performance review over his cell phone – he wasn’t discreet or quiet about it at all. Social engineering is what gets you to give up your social security number and birth date when you reply to some scam offering you a refund from the IRS or an online deal that you just can’t refuse.

The above are all examples of social engineering, and there are many more. The bad guys rely on egos and ignorance getting in the way of security awareness. Those that would attack you know that you are either trying to show off how important you are or that you are just plain ignorant of information security techniques. They will use a variety of very simple techniques against you to steal your data, launch code to wreck your computer, or turn your computer into a zombie to proliferate other attacks. The bad guys use clever emails and lures to malicious web sites to launch attacks more often these days than most any other types of attack. In fact as of this week, there is a new flaw in Internet Explorer, and according to this article at ZDNet, porn sites are already exploiting it. The really stupid and lazy attackers will just get you to do their work for them and simply tell you that there is a security vulnerability or virus on your computer, and tell you to delete certain files. They will then get you to email all your friends and tell them delete these same legitimate files (this is known as a virus hoax) which will then render all of your computers unusable the next time you reboot. Essentially, social engineering (in the bad sense) is all about getting people to do things that the attacker wants them to do.

If you were to look at the majority of the descriptions for most vulnerabilities that are fixed by recent patches, you would see that the patch itself fixes a vulnerability caused by a programming flaw, but that it is only exploited when the victim opens an infected email, opens an infected email attachment, or is lured to a malicious web site. In many cases, the exploit is not “WORMABLE” and simply relies on a cleverly crafted email, attachment, or image file getting onto the victim’s computer so that it can do its thing. The attackers know that they can get you to visit a web site or open an email, and that they can certainly rely on you to forward it to all your friends.

So lets talk about “good” social engineering. One of the greatest challenges facing IT security professionals is to get people to change their behavior and attitudes towards information security. To most people, the security people are just the Gestapo out to spoil their fun and keep them from doing their job. We are the source of inconvenience because it just doesn’t seem reasonable that the threats really are out there. It’s all a big myth. I’m here to tell you that the only myth is believing in the false sense of security because of the “it can’t happen to me” syndrome. When your IT support people or your friendly bloggists bombard you every day with hints and tips about locking your keyboard when you get up from your computer, telling you not to open email attachments, or not to write down your password on sticky notes – that is the form of social engineering we are trying to use to get you to change your habits a little. We aren’t trying to keep you from being productive. On the contrary, we are trying to keep you from becoming a victim.

Bottom line – the bad guys are trying to “social engineer” your behavior so that you will fall into their trap. They can then laugh at you while they point you out to all their friends (and get the news media attention they crave), telling them how they “stuck it to the man” and screwed up a bunch of computers. The IT security people are trying to “social engineer” your behavior so that you won’t make an ass of yourself, or worse yet destroy the company’s network or compromise proprietary information. If you get attacked at home because you were complacent about your own computer security, then it may take you awhile to get back your system up and running. And it might take awhile for you to get over the embarrassment that you feel because you unknowingly passed along the attack vehicle to your friends. But if you get attacked at work because you just didn't care to be bothered by computer security requirements and even spread the attack to the entire network, embarrassment will be the least of your problems. The security people have an obligation to keep you informed. You have an obligation to heed the warnings and do the right thing. In other words, you have an obligation to stop being ignorant and be as vigilant with your information technology as you should be while driving down the road in that 2,000 pound weapon of yours. Use some due diligence, as we call it, and be aware. Security is everyone’s business!

Microsoft is (Still) Not the Problem

Ahhhh - Fall is in the air and it is time to wrap up another summer! I want to start out this fine September by following up on an article I published on my main web site awhile ago. In that article, I mentioned that Microsoft was getting a lot of bad press because their products were always being attacked, and because they released so many patches. In following up and to set the stage for this article, I would just like to say that this has been a fairly interesting summer for Microsoft with the release of over thirty new patches for Windows, Internet Explorer, and Office products between June 2006 and August 2006 alone. All in all, we are up to numbered security patch MS06-051 (the 51st patch of 2006), plus several other patches that don’t fall under that numbering system. But let’s not forget that the folks at Firefox gave us at least two new releases this summer also, not to mention patches from Symantec, McAfee, and Intel (Intel/PRO Wireless Drivers). I’m not going to use today’s post as a forum to pit one browser against another or even one operating system against another. I just wanted to point out that there have been a lot of new patches all the way around, but that this high volume of new patches isn't necessarily the problem we are facing. In that previous article, I wrote that:

“Of all the people who regularly bash Microsoft for giving us an operating system with so many holes, I am probably one of the worst offenders. However, I recently had the opportunity to hear a talk by "Hacking Exposed" author Stuart McClure. He made a very interesting point - Microsoft is not the problem. There is so much talk about using the Linux operating system and alternative web browsers such as Mozilla FireFox. The point he made is that those systems also have security holes as do the Microsoft products.”

In spite of all these new patches this summer, I would like to say that I still believe that Microsoft is (still) not really the problem here. What I do see as the problem(s) are people who have too much time on their hands (the bad guys) and security unaware end users. The fact of the matter is that software code, no matter who writes it, is going to have flaws that are eventually discovered and exploited. It just so happens that Microsoft has the larger market share, so the bad guys are attacking where they know they can do the most widespread damage. So we know where the bad guys are presenting the problem – where they can do the most damage, and in doing so what will get them the most publicity.

So now let’s talk about the end user part of the equation. It’s a foregone conclusion that the software has flawed code, and always will. But let’s face it; Microsoft and other vendors find their flaws (or have the flaws reported to them), they fix the flaw and release a patch. It is now up to the end user (or the IT support structure in corporate environments) to make sure that the patches are getting applied in a timely manner. Are you setting your Automatic Updates to download and install your patches, or do you at least visit Microsoft Updates regularly to get them manually? How about your other (non-Microsoft) software – do you keep an eye on settings that will allow automatic updating for those as well? Since we’re on that subject, even if you do have your Automatic Updates set to auto/auto, when you have some down-time, why not visit the Windows Update site on your own. Check every once in awhile and make sure for yourself that you aren’t missing any critical updates. Just as you should be manually checking your antivirus and anti-malware definitions every so often to make sure your update engines are working properly and that your system is in fact getting the updates as it should be.

So what happens when a patch goes bad and breaks your computer or an application? Are you simply throwing up your hands immediately, screaming how %$#@& Microsoft is always breaking your computer? This is another example, in my opinion, where the end users are the weak links in this whole patching and updating game. Far too many people scream and curse at Microsoft when a patch goes bad on their system instead of taking a few moments to calmly find a solution to the problem. The solution, by the way, is as close as your telephone: 1-866-PCSAFETY. That is Microsoft’s hotline for solving patch related problems. If the problem is caused by a security patch, the call is free of charge. The problem may be isolated to just your particular configuration, and it may be a simple matter of uninstalling and reinstalling the patch. If enough people call with the same problem, then Microsoft knows that there is something wrong with the patch itself, and will quickly release a fix. But in order to do so, Microsoft has to know about it! They don’t read minds any better than I do – the end users that are seeing the problem have to report it so that something can be done about it.

I have been in the patching business quite awhile; I test and deploy patches that are applied to an enterprise of over 10,000 nodes, and I have yet to see consistent strings of patches that break computers. I do, however, see occasional problems come up on individual systems. I am telling you the same thing that I preach time and time again: Do some troubleshooting, find out if it is an isolated problem or a widespread problem, and call the Vendor and get the problem documented.

The other thing that I am absolutely sure has to be made clear is that the nature of the majority of the attacks in recent history rely on luring users to bad web sites or opening infected emails to expose themselves to the risk. Most of the time, you aren’t in danger of the flawed code on your computer being exploited unless you do what the attacker wants you to do to unleash the attack. The attackers have gotten too lazy to make their attacks “wormable” – and why should they? Why go to the trouble to write the type of code needed to make computers proliferate the attacks, when they can reply on security unaware users to do it for them? All those emails with attachments that you blindly pass on to all your friends, and all those emails with links that you blindly follow: did you ever once stop to think about whether or not they contain potentially harmful content? This is why, in my humble opinion that much of the blame for the proliferation of harmful code rests squarely on the shoulders of the people clicking the mouse buttons.

So to summarize – I will say it again: Given enough time, the bad guys will find and exploit flaws in anything. This problem is not limited to Microsoft. It is just that Microsoft has the largest market share and will earn the attacker the most press time. This summer, I have seen patches come out for Microsoft products, UltraVNC, Symantec antivirus, McAfee antivirus, Firefox (multiple), Intel/PRO wireless network card drivers, as well as a few other products. So don’t blame Microsoft – blame the bad guys, and blame yourself if you’re not keeping your systems patched. You can also give yourself a little of the blame if you are blindly clicking on the email “Forward” button or those links in your email when you don’t know what they are or where they came from.

Another Firefox Vulnerability - Already?!

Firefox’s latest browser, version 1.5.0.6, already has a new vulnerability.

National Vulnerability Database Article

Look to the left of this article – below my profile, and you will see that I am a big Firefox fan. I still use Internet Explorer, and Opera, and Netscape, yada yada yada, however, because I do a lot of testing. I just want to say that I am not writing this post to slam any particular browser or boost one over the other. But I have to wonder – and this is for all the little computer nerds who work in Best Buy, constantly parroting the virtues of Firefox to every customer they see – why is it that all these new vulnerabilities in Firefox practically go unnoticed while the Internet Explorer vulnerabilities get all the press?

In the last three weeks or so, Firefox has released two new versions, presumably to cover security holes and add features. The only reason I found out about the latest Firefox vulnerability is some micro-font text on a Dark Reading Weekly page – not a front page press item to be sure. I’m sure this will be published on Secunia and SANS very soon. But because the kids at Best Buy tell you matter-of-factly that Firefox is the only way to go, and just because Firefox doesn’t get the big press, doesn’t mean you are always safe and never need to pay attention to staying up to date.

Anyway, my point in all this is that people fall into a false sense of security because they hear so-called “experts” blather on about how Firefox is far superior to Internet Explorer from a security standpoint. People blindly follow this advice, thinking that they will never, ever, ever, ever have to worry about anything from now on. This notion is putting a patently false idea into your heads. Regardless of what products you use, you always need to stay vigilant for security flaws and apply updates when they are available.

The bad guys are getting bored with Microsoft – due diligence and proper risk analysis means that you are evaluating all of your software and keeping them up to date. Stay safe with all parts of your system!

URGENT: Patch for MS06-040 Immediately

Microsoft Critical Patch MS06-040 is being listed as a "Patch Now" patch by SANS Internet Storm Center.



Microsoft is listing MS06-040 as "Addresses a critical security problem."





Test and patch your systems as soon as possible. If you have to prioritize your patches (because there are so many this month), test and apply MS06-040 first, and then test and apply MS06-042. More info as I get it. You can read more about this also at:

http://www.patchmanagement.org

http://isc.sans.org/diary.php?storyid=1573

http://isc.sans.org/diary.php?storyid=1574

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.