The last three Patch Tuesdays haven't been the straightforward affairs we're used to. February's was a big deal because it was delayed and then canceled outright, with Microsoft never explaining to us why it didn't happen.
Of course, that decision might have had something to do with the unexpected contents of March's Patch Tuesday. That release fixed a bunch of previously undisclosed flaws that were then publicized by Shadow Brokers when the mysterious group published a cache of NSA exploits.
In a change announced last November, Microsoft originally intended to introduce a new system of describing its patches and their respective security fixes this February. That didn't happen in February, and it also didn't happen in March. The bumper crop of fixes referenced above instead used the company's long-standing security bulletin format. But last week's April release did, at last, make the change.
We weren't initially sure what to think of the new format. Any change to a long-established system is going to bring some wailing and gnashing of teeth as workflows have to be updated and adjusted to accommodate the things that are now different. But different doesn't mean better or worse, necessarily; it takes a bit of time to figure that out. Since the change, we've heard from readers and it seems many aren't really happy with what Microsoft has done.
Under the old security bulletin system, Microsoft produced a bunch of documents, one per patch set, broken down into broad categories. For March, for example, there are bulletins for the Windows kernel itself, Windows kernel drivers, the IIS Web server, the Hyper-V hypervisor, and so on and so forth. This grouping made it fairly easy to tell at a glance roughly what area of the products were impacted and who might need to perform testing or validation of the fixes. Because these bulletins are component-based, they span multiple Windows (or Office, Exchange, SQL Server, as appropriate) versions.
That bulletin approach made it easy to see both a high-level overview of how severe the problems were and what was impacted along with details on each individual reported vulnerability.
In the new system, that grouping is gone. Microsoft now has a searchable database (hidden behind a lengthy click-through EULA) with an entry for each individual bug. The grouping that the old bulletins offered has been substantially removed. So for example, the April updates include a fix for Flash. Under the old system, this would result in a single bulletin that encompassed Flash on Windows 8.1, Server 2012, Server 2012 R2, Windows RT, Windows 10, and Windows Server 2016. Now? Each of those operating systems is reported as a different line from a database search. This:
...has become this: 
For Windows bugs, the categorization by product area appears to be gone. No longer do we see listings for kernel, drivers, or IIS. They're all just "Windows." An organization might reasonably be more concerned about, say, critical IIS bugs than they are critical SMB bugs. The former are much more likely to be exposed to the Internet than the latter, and so might well be prioritized for testing and deployment. But there's no longer any easy way to see which bugs are which.
Similarly, seeing which CVE IDs have been fixed in a given patch cycle is more difficult. The information is there if you perform a "detailed" search, but the presentation is overwhelming: one search result per CVE per affected product, so each CVE gets repeated a whole bunch of times:
If you want to read up on what each bug is, there's no single-page consolidated view with both high-level and low-level details. Instead, you'll have to click each of those blue CVE links one by one.
Except for the information about which part of Windows is affected, it does appear that most of the information from the bulletins is still available—it has just been made much less convenient to use. As such, the negative reaction we've been hearing is very understandable, and it makes us wonder why Microsoft made this change in this particular way. A beta period during which both the old and the new style coexisted would surely have been a valuable way to get feedback without being tremendously disruptive to existing administrative processes. The new approach does have some potential advantages, as Microsoft says that the new database has (or will have, at least) properly defined APIs. This will make it easier to integrate with other tools and third-party services. But it seems a lot of admins just want sensibly consolidated information in a manner that they can read and distribute within their organizations.
Update: Apparently there was in fact a beta, though it's not clear to us how many people participated or what changed. This just makes the feature deficits even more astonishing, given the uniformity of the response we've heard from administrators.
Is there anyone out there who loves the new database approach? Or, has Microsoft taken a major step backwards and made all your lives harder?
reader comments
49