Sorry if this has been asked before, but I couldn’t find anything about it.
What is everyone doing as far as patching timeframes/frequency go? For instance if a critical asset(s), how long does infrastructure have to get it patched (not including patches that could break it, etc.). What about non critical assets, DMZ, external, non-internet facing, desktops, remote, etc?
Here’s’ an example of what we do:
External 10 days (CVSSv3 8-10), 30 days (CVSSv3 4-7.9)
DMZ is 30 days (CVSSv3 8-10), 45 days (CVSSv3 4-7.9)
Servers 30 and 45 days (CVSSv3 4-7.9)
AS/400 and VMWare is 90 days (CVSSv3 4-10)
Networking 30 days (CVSSv3 4-10)
Desktop assets 30 days (CVSSv3 8-10) 45 days (CVSSv3 4-7.9)
Just wondering what are some common practices. Looking in NIST and not finding a specific recommendation.
Just wondering why you are using CVSS as a stearing metric instead of real risk within InsightVM? We actively advise organisation to move towards a weekly patch cycle on their entire estate. This reduces the burder of out of band patching and forces a more structured proces and procedures.
I don’t believe there are standard or guidelines yet for patching frequency but sooner is always better.
Hi Maikel. That’s a good question, and reason is that the overarching authority came in for an audit and recommended/told us to use CVSSv3. So here we are. Real risk may be something we can move towards at some point, so that is a good idea. Thank you!
If possible i would recommend to switch to real risk and lose the complexity that has been created with al the various scenario’s. For instance an external or DMZ server can properly do less damage to the organisation than a breached internal server.
I always like to look to it from an impact perspective, what could happen if this got breached. Systems in DMZ or External are often heavily secured with an layered approach while internal systems are often less well protected and placed closely together. The traditional castle approach
Start by focusing on actively targeted vulnerabilities, then move towards exploited vulnerabilities and so on and then turn towards risk based action. For instance if a machine get’s a risk score higher than 10.000 points action is necessary and lower that max allowed risk score on a yearly base until you feel that you are sufficient in control.
If you want to measure the time between vulnerability found and fixed you could create some goals within insightVM to measure this.
I personally would recommend on focusing on the outcomes needed rather than the severity of the issues which are being addressed. I have worked with a lot of organisations over the years, which have had very different ways of looking at the security risk associated with security patching. Although they may have had a risk-based approach, the desired outcome has always been the same - patch as quickly as possible without interrupting the business.
I have always found, keeping it simple gets the best results. You could look at different severity levels, different time to deploy measurements for different environments but you are likely to find you spend more time on prioritisation / discussing prioritisation than is necessary. Over time, you will see trends for the different infra types, for example user access devices will always be a high priority than servers as they are more on the network edge.
When I defined our policy, I decided on the approach of –
User Access Devices (Laptops / Desktops) – Non-Critical – 31 days
Servers / Network Devices - Non-Critical - 70 days
We then have a process which controls what we see as critical too us supported by Security Intelligence and Industry security intelligence sharing etc. For truly critical issues we would address them on the user access devices within 5 days and 10 days in our server / networking environments (using an outside in prioritisation model).
I did it this way, as we on an ops level aim to patch everything every month, so our ops teams will always meet their KPI for non-complex issues, for complex they have a little longer to do the work needed. By treating Critical issues as truly critical issues, I can go to our Ops Leadership team as for resourcing to address something when needed rather than every week when a vendor says something is critical.
By removing the discussions on prioritisation, it enabled us to focus more on delivery and more importantly on delivery issues.
We use our scan data is a confirmational exercise and to report on KPI’s which demonstrate the age of findings within our insightvm instances.
I think I see what you are saying. Right now our desired outcome is to reduce the vulnerability backlog that we have while addressing current 30 day patching requirements. Thank you!
Okay this kind of sounds similar to how we look at things minus the reboot aspect and timeframe requirements. I’ll keep this in mind to see how to implement, along with what everyone else has said/suggested, for future work. Thank you!
Consider, are you patching as fast as recommended by the vendor who produced the patch? This may result in more than one table; however, it is something you can defend during an audit.
