The CSO Perspective: What Does the Microsoft Servicing Change Mean?

October is CyberSecurity Awareness month. It’s also the month that Microsoft will implement the new servicing model to pre-Windows 10 systems. Yes, that’s correct. Windows 7, 8.1, Server 2008 R2, 2012, and 2012 R2 will all be moving to an update servicing model similar to Windows 10. Microsoft first announced this change in June and described it as follows:

  • Internet Explorer and Operating System updates will be packaged in two ways.
    • Security Bundle—All OS and IE (Security only) updates for the month will be bundled in a single update. This is not cumulative: the November Security bundle would not include the October Security updates.
    • Cumulative Update—All OS and IE updates for the month for both security and non-security are included in a cumulative rollup each month. The November rollup would include the updates from the October cumulative update.
  • .NET Framework will be a separate Cumulative Rollup. This update will be a single package no matter how many .NET versions are currently installed on a system. The installer will detect and update the installed versions. It will NOT install net new versions.
  • Adobe Flash for IE will be a separate update.
  • Office, SharePoint, Exchange, SQL, and other products will still be separate updates each month.

I’ve had questions from customers, prospects, writers, vendors, and partners about the real impact of this. I’ve posted my thoughts, but today I thought we would catch up with LANDESK CSO Phil Richards and get his.

Chris: Phil, thanks for taking the time to talk about how you see this change and the improvements and challenges we’ll face in the future.

Phil: Thanks, Chris. This is an interesting development from Microsoft that has potential security improvements, and potential issues, depending on how we, the consumers, respond.

Chris: Phil, Microsoft’s change was prefaced with a message of “You asked for it, we delivered.” They didn’t really say what we “Microsoft customers” asked for. So, based on the changes, what was it you think we asked for?

Phil: Enterprise-level patching is far more complex than patching your personal computer at home. There are three main improvements customers are looking for over today’s patching processes: simplification, quality, and security. I think a good portion of the consumers are looking for a simplified patching experience. The complexity of patching—understanding precedence requirements, identifying installed components that require patching, and anticipating future patch needs—makes the patching experience somewhat painful, error prone, and manually intensive for IT professionals. Unfortunately, this is a double-edged sword: when Microsoft bundles the patches, making the customer interface more simplistic, they increase internal complexity of the patch package. he bundled patches must respond correctly to more configuration permutations. While many customers don’t like the complexity associated with multiple patches, I believe they will be unable to support patch bundles across the entire set of systems that require patching. When an IT department has a particular server that needs special handling because of software that will not work with a specific patch, it’s faced with the very real challenge of not applying the entire patch bundle on that system. Over time, we will see many systems that are not able to take patches at all, lowering the security readiness of the enterprise.

Customers are also asking that Microsoft improve the quality of the patches. But increasing the complexity of the patch package by bundling patches raises quality of the Microsoft package at the cost of adversely impacting other sensitive applications on the system.
Finally, customers also need improved security from their patches. With this new patching delivery method, updates are more frequent and potentially more comprehensive. Unfortunately, security updates often create new security vulnerabilities as quickly as they patch old ones. They are, after all, software. While this happens much more frequently with other providers, it has occurred with Microsoft patches. Another security issue has to do with the volume of patches and the possibility of missing one or more them in your environment. By bundling the patches and providing a cumulative update, IT professionals have the ability to make sure their servers are up to date. Again, the downside is that if I am unable to patch a particular server because of one component, the server remains vulnerable to all threats in the whole patch package.

Chris: Seems like, even with Microsoft's good intentions, there could be challenges. Digging deeper into some of your points, let me throw a hypothetical situation at you and see how you’d handle it. Let’s say you have a legacy application in your environment that’s critical to your business and very sensitive to patching. You know that each month the security updates need to be tested and often result in one or two OS updates you have to mark as exceptions because they conflict with this application.

If we look at September’s updates and apply the details Microsoft described, the 14 bulletins become 4. The largest is for IE and OS updates. It rolls 10 bulletins and 31 vulnerabilities into a single bulletin. There is another for Office, one for .NET, and one for Flash Player for IE. One of those OS bulletins for September is for the Windows Graphic Components. Under the old model it’s bulletin MS16-106, which resolved 5 vulnerabilities. In this case it will be in the bulletin that includes 31 vulnerabilities, including a Zero Day that was resolved in IE. This GDI change breaks the legacy application and will cause a major disruption to the business. You have to choose to make an exception or break the application and wait for the vendor to fix it. What would you choose to do?

Phil: If I choose to run the critical business application and keep my business afloat, I have to choose not to install multiple patches, which poses a very real threat to my business. If I choose to patch, I have to stop running the application, which poses a very real threat to my business. To address this issue, I’d try to get the vendor of the application to make modifications to support the Microsoft patch. I’d also look at other technologies that will allow me to further isolate the offending application, so I can patch the operating system, or apply network configuration changes to decrease the attack surface of the server. Major technologies in this space include containerization to isolate the application or web application firewalls to decrease the attack surface. While there are workarounds to patching issues, these require heavy lifting by an already overburdened IT organization. These workarounds aren’t efficient and will increase complexity of the environment overall—which is exactly what Microsoft is trying to avoid in the first place.

Chris: Let’s take this scenario one step further. The legacy application is from a vendor that’s no longer in business, so there’s no fix forthcoming. This leaves you with a known exploit for IE exposed in your environment, which is unacceptable. What steps would you take to protect the systems that require this application?

Phil: At this point, the best that can be done is application isolation through containerization and network isolation through a combination of segmentation, firewalls, and web application firewalls. The amount of work involved in this one-off solution is significant, and it’s brittle. I believe this scenario will happen multiple times for customers that have special apps not supported by vendors that are running significant portions of the business. Once the workaround solutions are in place, there is no incentive to fix the underlying problem. It just becomes more walled off, creates higher technical debt, and because of the brittleness of the solution, remains a high risk area of the infrastructure. The problem also compounds. Since the patches need to be cumulative in nature, there is the possibility that by skipping the patch bundle for October, you might not be able to take patches in the future, which increases the network configuration pressure, increases the brittleness of your workaround, and makes it all the more difficult to extricate your business app from the vicious cycle.

Chris: Great feedback, Phil. Thanks again for your time and recommendations. It appears that we should all expect some changes in the near future and some hard questions may come up, but I think you have provided some great takeaways from this discussion.

  • Microsoft's change, while well intentioned, will impact many companies and could lead to some hard decisions.
  • Application compatibility is going to be the most significant of these changes. Most companies know what products are sensitive to updates already, so it may not be a bad idea to reach out to those vendors in advance and start asking if they understand the changes coming and potential ramifications.
  • While there may be some hard decisions in the future, with planning and other security measures the problems can be overcome.

As always the team here will be keeping a close eye on the situation. As we near October Patch Tuesday we will have more details to share. Make sure to sign up for the October Patch Tuesday Webinar; we plan to cover the new servicing model changes in detail once we see the first month of the new model in operation.