Greetings – I have been attempting to work with an outsourced managed service provider regarding maintaining and updating our computing environment.
Our managed service provider has taken a firm position that a reduction in vulnerabilities indicates successful patching. The vendor claims measuring the effectiveness of patch management and patch compliance should be evaluated using a vulnerability scanner (e.g. Qualys). Using vulnerability information as a patch management control goes against professional guidance and experience I am familiar with, where patch and vulnerability management controls are in separate domains by design.
There is also debate going on where our vendor states they are responsible for deploying the patch management tool; but are not responsible for actively managing machines failing to patch or brining such issues to our management’s attention.
Any insights from the community would be appreciated.
Regards,
Matt
Let's break down into 2 question here.
1) Without outsourcing arrangement, how do you current company measure the patching effectiveness in the first place?what is the KPI? Once you have that you might able to benchmark with the outsource vendor or decide which is a more "acceptable" apporach.
2) the vendor states they are responsible only for deploying the patch management tools, I guess this is no an brainer. Because testing the patch itself has a lot of work and coordination with the application and application testing cycle to see if patch has any adverse effect to the application running on top.
This means they are only responsible for the lifecycle and use of the patch management tools itself but not the full patching cycle (include testing and operation)
I guess you will need to have a long way for discussion and negotiation with your vendor to fill the gap which both parties are comfortable with.
@mattrjohnson wrote:
Using vulnerability information as a patch management control goes against professional guidance and experience I am familiar with, where patch and vulnerability management controls are in separate domains by design.
Not different domains. Patch Management Program fits inside of the Vulnerability Management Program. These links explain them well.
Vulnerability Management Program Basics: A Getting-Started Guide (rapid7.com)
What is Patch Management? Benefits & Best Practices | Rapid7
I agree with Tony ( @tmekelburg1 ) that patch management and vulnerability management are in the one domain but I am concerned about the statement:
There is also debate going on where our vendor states they are responsible for deploying the patch management tool; but are not responsible for actively managing machines failing to patch or brining such issues to our management’s attention.
I am concerned that they would NOT provide something to management on unpatched systems. I would think this would be a key finding and necessary to report.
At a very minimum, I would expect them to produce a listing of un-remediated machines such that someone is able to track down why they are not patched (are they out of service, etc.).
HMOO without understanding which computers are not patched, you could have a lurking bomb on the network so I would definitely stand my ground on this one.
d
@tmekelburg1 @dcontesti @Cees @csjohnng
Really appreciate everyone's responses.
I do believe there needs to be separation of duties between the parties managing patching and the parties managing vulnerabilities; maybe not separate domains, but duties should be separated.
Regarding the situation described, it is totally messed up, factors below, and fortunately my Board of Directors agrees with my concern and does not want to accept the risk.
Needless to say, with great support from our governance team, I am going to be empowered to find a solution to mitigate risk.