Does it all come down to patch management? As a security manager, I pursue many initiatives, striving to protect the company on many fronts. But patch management is a key metric of our risk exposure, since there is a direct correlation between security incidents and patch compliance. So, in a way, it does all come down to something as basic as patch management, because if we fail there, we can't be secure.
Of course we have a patch management policy, but I've been frustrated in trying to get our various IT and engineering departments to comply with it.
I'm not even talking about the impossibility of patching the control PCs that are connected to tools running in our labs and our engineering departments. There, we need to maintain older versions of operating systems to support legacy products. We can't keep those patched, and I accept that.
Instead, I'm talking about things like the deployment of new virtual servers. When we first talked about implementing virtualization, it was agreed that we would keep on top of the security patches for the images used to deploy new virtual servers. At first that process was followed, but it's very easy to bypass the formal change-control process when deploying new servers, and as time went by, I started noticing that some virtual servers didn't have the latest patches.
A year ago, when the patch process was running smoothly (the honeymoon phase), I authorized the disabling of Windows Update so that we could use Microsoft System Center Configuration Manager to handle updates. It seemed like a reasonable response to a big problem: Some PCs didn't operate properly after the automatic downloads. Better to disable the automatic updates in favor of a testing and validation process. That way, we could push out patches only when we were sure that potential problems had been mitigated. That led to a new problem, though: It could take weeks, if not a month, to deploy patches that had to be tested and validated first; so much for timely patching. As you would expect, the delays led to an increase in security incidents.
But we could institute some compensating controls. I told the IT department to identify the IP addresses or machine names of PCs that weren't patched properly and add them to watch lists for our intrusion-detection sensors to monitor. And because we don't have full IDS coverage, I also ordered the installation of a host-based intrusion-detection agent. I'm also talking to our network team about creating a separate quarantine virtual LAN with appropriate firewall rules to protect our main corporate environment from attacks targeting vulnerable servers.
Get the NAC
But even with these new policies in place, along with our Web content filtering, firewalls and network monitoring infrastructure, we still have a big problem: We have no control over the connection of unauthorized devices to our network. Anyone at all can connect any sort of device to our network -- and then introduce malware or steal intellectual property.
My great hope is that we can implement network access control someday soon. NAC would enable us to guarantee the configuration of any device that attempted to connect to our network (preadmission NAC). It would also establish the identity of the user of that device and control which resources that device could access (postadmission NAC). NAC is on my road map, but unfortunately, there's no funding available at this time. For now, it is the Nirvana I aspire to.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.