Patching is one of those less glamorous tasks that have to be assigned to IT staff, yet it is an essential part of a thorough security strategy.
But as Rafel Los, research director at security consultant Accuvant, points out in this blog, often IT departments and vendors panic when systems have to be urgently patched after a major problem like Heartbleed is discovered.
The reason, he argues, is that patching has evolved into an IT operations responsibility rather than the security team. After all, before patches are applied systems have to be tested thoroughly before the patch is put into production. The truth is, Los says, patch should be part of configuration and asset management.
“Enterprises that don’t operationalize configuration and asset management are doomed to repeat the cycle of lost productivity, frustration and panic,” he writes. “The panic that ensues when an organization identifies a major vulnerability and then has no choice but to find (or build) a tool to scan their environment to find the vulnerable assets should not become routine. Wouldn’t it be amazing if the primary mode for identifying these vulnerable assets was an asset database that was relatively complete with accurate data so they could simply dive in and find 75 per cent of the known systems that have OpenSSL on them, for example? After they patched those systems, they then could break out the scanners and find the unknown vulnerable systems and add them into the asset and configuration management system? How crazy is that?
“The reason this is important is that we are taking about incredibly high costs to productivity when security has to drop everything and go hunting and one-off patching.”
Enterprise security teams should more on Information Technology Infrastructure Library (ITIL) fundamentals, and asset and configuration management within their organizations, Los says. That way when a major system needs to be fixed IT can patch what it knows, then look for the unknowns in a methodical manner.