One of our team’s most common quotes is “Cyber security is so much more than firewalls and anti-virus software.” All successful security solutions are part of an overall program that addresses who will manage, maintain, and upgrade the solution for its lifetime. The latest and greatest technology can’t really just be dropped in and expected to perform—you must match it with your plans and strategy. The message is: consider what the needs are, develop a program, and then determine the technical controls.
If you’ve started to delve into patch management due to regulatory requirements like NERC, or just as a good business “best practice,” you probably became quickly overwhelmed. In fact, you have probably felt like a person on a cold night with a blanket that is too small. You pull the blanket up to keep your chest warm but then your feet get cold. You pull the blanket down to get your feet warm, but then your chest gets cold. There is constantly a “hole” that you can’t plug to keep yourself warm. The same is true with patch management. Just when you think you have a good handle on Microsoft patches and have that automated, you have to deal with device firmware (PLCs, network equipment, network-connected peripherals) and the whole myriad of other software on the market. It also doesn’t help when many vendors list updates but are not forthcoming in saying which updates are security-related or not.
So, how do you deal with all this “patching uncertainty?” First, keep it simple and look at the title of what you are doing: patch management, not patching perfection. Patch management is all about prioritizing and managing risk. Before patching your environment, you need to establish a patch management program to help you evaluate, prioritize, test, and deploy patches. In some cases, you may even determine not to deploy a patch and rely on other security controls (i.e. compensating measures), such as the anti-virus software and firewall solutions you have in place to mitigate that risk.
How does this approach line up with regulatory requirements? In the case of NERC CIP, it fits in perfectly. For example, the title of NERC CIP 007 R3 Version 4 is “Security Patch Management,” which immediately tells you that your primary focus should be on “security” patches, not every patch ever created. In fact, this NERC CIP standard only requires three key things:
- Evaluate security patches within 30 days of their publication
- Document the implementation of patches (note that no timeframe is given for when you have to deploy the patch)
- Document compensating measures applied to mitigate risk when the patch is not installed
This gives power generation facilities the flexibility they need to develop a patch management program that includes adequate time to prioritize, test, and deploy patches without the patch itself becoming a threat to reliability of the electrical grid. If installing a patch threatens reliability, then a generation facility can schedule the patch at a time that minimizes that risk or decide not to deploy it.
This is just the beginning of establishing a patch management program. Other items such as scope of equipment and software for patching must be determined. The Schneider Electric Cyber Security Services consulting team has the skills and the resources to help our clients, no matter what industry. We are structured to help with an establishment of an entire cyber security program, not just patch management.
Special thanks for Charles Smith (firstname.lastname@example.org) for contributing to this article.