In an effort to be more transparent with customers, Microsoft is clarifying patch management policies that experts said have been generally understood, but never properly codified.
Alongside the June 2018 Patch Tuesday release, Microsoft published the Security Servicing Commitment, which it hopes will help customers understand whether a reported vulnerability will be addressed during the monthly patch cycle or in the next version of a product.
In order to make this determination, Microsoft has specified two key criteria for immediate security patching: whether the vulnerability is severe enough and whether it “violate[s] a promise made by a security boundary or a security feature that Microsoft has committed to defending.”
“If the answer to both questions is yes, then the vulnerability will be addressed through a security update that applies to all affected and supported offerings,” Microsoft wrote in the Security Servicing Commitment. “If the answer to either question is no, then by default the vulnerability will be considered for the next version or release of an offering but will not be addressed through a security update, though in some cases an exception may be made.”
The security boundaries described in the Security Servicing Commitment are the points of “logical separation between the code and data of security domains with different levels of trust,” including network boundaries, kernel boundary, virtual machine boundary and more. Security features include Windows Defender, BitLocker and Windows Resource Access Controls.
However, Microsoft makes a distinction between these features and boundaries and defense-in-depth features, which it claims “may provide protection against a threat without making a promise.” These features include address space layout randomization, data execution prevention, user account control and more.
Codifying understood policy
Experts said there wasn’t really anything new in Microsoft’s Security Servicing Commitment, although the clarification was welcomed.
Dustin Childs, communications manager for Trend Micro’s Zero Day Initiative, said the policy description was less of a change and more of a clarification.
“Some of this information was publicly available, but it wasn’t found in a consolidated source with full details,” Childs wrote via email. “It’s hard to say why they chose to publish this now. Perhaps there has been an increase in submissions that don’t meet their servicing bar and have caused confusion with researchers.”
Chris Goettl, director of product management for security for Ivanti, based in South Jordan, Utah, said it was good “to see some clarity regarding severity of vulnerabilities to better understand how updates are classified” with the Security Servicing Commitment.
“Public and private disclosure of vulnerabilities can be a messy ordeal. I think this commitment provides the ethical hackers of the world with rules of engagement for disclosing bugs with Microsoft,” Goettl wrote via email. “Overall, I think it provides transparency to those who are committing their time so they know it will be worth the effort and are not disappointed or surprised by a response where Microsoft is not committing to provide a fix or a bounty.”
Chris Goettldirector of product management and security for Ivanti
Allan Liska, threat intelligence analyst at Recorded Future, based in Somerville, Mass., said the Security Servicing Commitment was “spot on and laid out in a smart, strategic way.”
“Given Microsoft’s breadth and depth of products and constant commitment to security, this is a good approach on their part. What stood out, especially, was that they made the distinction between a potential exploitable security vulnerability versus a defense in-depth feature,” Liska wrote via email. “While there will always be people who question security moves a company as large and impactful as Microsoft makes, overall, this is good step in the direction of transparency, and I think it should be applauded.”
Childs said the Security Servicing Commitment constituted “a pretty comprehensive list” of policies, but it could be better.
“Due to the complexities of modern code, it’s unlikely any list such as this could ever be 100% complete and cover every scenario,” Childs wrote. “While this level of transparency is good to see, it would be great if they also committed to fixing bugs — especially severe bugs — faster or committed to improving patch quality or communications.”