NCSC vuln management guide details why to update by default - and why not to
Business should own the risk - not the security team
The National Cyber Security Centre today issued guidance on vulnerability management and called on organizations to institute update by default policies – unless they really don’t want to.
The guidance also covers asset identification, advice on triaging and prioritising, the risks of not updating, and ongoing reviews of vuln management.
It comes hard on the heels of warnings from the government agency about active exploitation of vulnerabilities affecting Ivanti’s Connect Secure and Policy Secure.
Unsurprisingly the GCHQ offshoot advises that organizations “should put in place a policy to update by default, where you always apply software updates as soon as possible, and ideally automatically.” It reminds readers to test updates on their own systems and to consider phased rollouts.
For business as usual updates, internet-facing services and software should be updated within five days, the NCSC suggests, and operating systems and applications updates within a week.
For internal or air-gapped systems, a two week window should suffice.
But, it says, all these timelines should be shortened considerably when “exploitation is rife”.
This all assumes organizations know what needs updating of course, and the NCSC advises that asset discovery, cataloguing and managing estates is a continual process. Likewise, organizations need to know and spell out precisely who is responsible for each system, once it has been identified.
Configuration audits should be automated, to ensure configurations are consistent and secure.
Vulnerabilities assessments should be carried out at least month, with organizations also having the capability to kick off an ad hoc assessment if it becomes aware of a new vulnerability of concern. Scanning should also be part of the org’s regular hygiene. Scans can surface issues that are not to resolve automatically, meaning companies must have mechanisms to triage vulnerabilities and prioritize what to fix or remediate – assuming this is an option.
But life is complicated, and the NCSC accepts there may be situations where organizations may choose not to update. This may be because a system is about to be decommissioned and the vulnerability is hard to reach and exploit.
“With sensible controls, such as making sure that decommissioning continues, it's perfectly rational to not update,” it concedes.
The NCSC is less understanding about situations where “constraints such as staff time, or concerns with compatibility of the updated software” means updates are nixed. “It’s important to fully understand the potential impact here on your organisation.”
This must be “a senior-level risk decision, and should be considered in the wider context of organisational risk management policy and practice.”
It advises that firms should still carry out risk-based prioritization and consider the CISA Known Exploited Vulnerabilities Catalog and threat intelligence feeds. Decisions should not be based purely on one score such as CVSS.
And factors such as backups, reputational damage, and the cost of incident response and even fines should all be considered.
Ultimately, “It's important that the business owns the risk, not the security team, and that it is visible to senior leaders.”
Needless to say, all of these processes should be verified – and supplemented by pen-testing - and be regularly reviewed. That, at least, is something organizations should NOT opt to do.