Microsoft's Patch Tuesday preview will no longer be made public
Microsoft said the change to its patching was made because customers no longer use the previewing system the same way they did in the past.
Microsoft warns on yet another zero-day security flaw
Microsoft's Advance Notification Service (ANS) is changing – notably, the corporation will no longer be releasing a public blog post to preview what is to come on Patch Tuesday, according to a Thursday post by Chris Betz, senior director of the Microsoft Security Response Center.
Premier customers may continue to receive the ANS information through their Technical Account Manager support representatives, and ANS information will also be provided to organisations that are part of security programmes such as the Microsoft Active Protections Program, Betz wrote.
Customers who do not have a Premier support contract may get ANS information through myBulletins, which makes it possible for customers to obtain bulletin information only on applications that are running in their environment, according to Betz.
“ANS has always been optimised for large organisations,” Betz wrote. “However, customer feedback indicates that many of our large customers no longer use ANS in the same way they did in the past due to optimised testing and deployment methodologies. While some customers still rely on ANS, the vast majority wait for Update Tuesday, or take no action, allowing updates to occur automatically.”
Industry professionals seem to be against the change.
In a Friday email correspondence, Wolfgang Kandek, CTO of Qualys who regularly writes about Patch Tuesday, told SCMagazine.com that he believes the change is a business optimisation, and he went on to say that it is ultimately a bad idea.
“We should move in the direction of more information and explanation,” Kandek said, going on to add, “Organisations that have a structure already will be able to cope, but it will slow down adoption in other organisations that are just working on getting into the process of managing their vulnerabilities and the needed fast patching.”
Chris Goettl, product manager with Shavlik, told SCMagazine.com in a Friday email correspondence that he also does not like the move, and that it cuts a lot of lead time for companies who care about what is coming and want to plan in advance.
“I think the repercussions will be at the business level first,” Goettl said. “Getting the right amount of information to admins so they could submit change controls in advance, discuss with their internal security and approval boards, and prep test groups before patching started allowed many companies to be aggressive in their patch day maintenance.”
Now things will have to be pushed back, Goettl said.
“Companies that have 20-day cycles to go through QA, development, [and] production rollouts are going to find their cycles pressed even more for time,” Goettl said. “Now their fact-finding will start on patch day and, due to red tape, will have to potentially push back or condense an already tight schedule for maintaining servers.”
Ross Barrett, senior manager of security engineering at Rapid7, agreed in a Friday email correspondence with SCMagazine.com, explaining that “this makes it harder for teams to know what to patch, [and] will take longer for teams to identify vulnerable systems and patch them. It has always been a race from patch release to exploit availability and this is taking away the tiny head start that they previously had to get organised.”
Johannes Ullrich, dean of research with the SANS Technology Institute, told SCMagazine.com in a Friday email correspondence that the change could be beneficial if it helps with patch quality, but he said that several users have already expressed missing the ability to plan ahead.
“I think we need more transparency in what patches address, in order to better assess their impact on other software,” Ullrich said. “In addition, we need to clearly express the risk the vulnerabilities expose users to.”
Ullrich said, “Overall, patching needs to be more automated, and companies like Microsoft need to not only embrace related standards, but also provide reliable guidance as to the risk of the patch and the vulnerability, as well as the ability to “break up” patches to be able to expedite patching high risk vulnerabilities.”
(First published on the SC US site)