A NERC CIP compliance audit isn’t all speedboats and supermodels, even when tackling CIP 007 (which is actually focused on maintaining a hardened build standard and may leave you wanting to fire your own ejector seat).
The World is Not Enough…
A NERC CIP compliance audit isn’t all speedboats and supermodels, even when tackling CIP 007 (which is actually focused on maintaining a hardened build standard and may leave you wanting to fire your own ejector seat).
How much work is going to be needed to implement security best practices, and what will it take to then prove to an Auditor that you are doing enough?
The intent of the NERC CIP audit, as with any other compliance audit, is to show that you really do have intimate knowledge of your BES and SCADA infrastructure and that proper security best practices are being operated to maximize cyber security protection at all times. The range of threats encompasses Insider Threats through to APT Malware infections and providing 24/7 comprehensive defense is harder than ever. As such, NERC CIP rightly demands ‘technical and procedural controls.’
And also in common with other compliance standards, understanding the true intent of the requirements and measures is key since there can be a difference between complying with the letter - rather than embracing the spirit - of the requirements.
For Your Eyes Only….
Take CIP-007-03 for example.
“Standard CIP-007-3 requires Responsible Entities to define methods, processes, and procedures for securing those systems determined to be Critical Cyber Assets, as well as the other (non-critical) Cyber Assets within the Electronic Security Perimeter(s). Standard CIP-007-3 should be read as part of a group of standards numbered Standards CIP-002-3 through CIP-009-3”
The 9 Requirements R1 through R9 then describe, in very non-prescriptive terms, requirements to operate routine security best practices. Naturally, there is a great deal of emphasis on
- configuration management
- user access controls
- malware defense and detection
- system hardening
- vulnerability/patch management
- change control (to keep everything secure and help differentiate planned from unexpected changes)
- security event monitoring (breach detection, suspicious activity reporting, file integrity monitoring)
- documentation
In summary, keep all cyber assets secure through hardening and patching, control who has access, and monitor for any breach activity.
One point that seems to cause most confusion is R2 – Ports and Services. The intent is clear and makes a lot of sense from a security standpoint, but leading on ‘Ports’ seems to throw NERC CIP Professionals off balance. In fact, it would make life simpler if this requirement were more like the PCI DSS Requirement 2, in particular
“2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards”
And
- Enabling only necessary services, protocols, daemons, etc., as required for the function of the system
- Implementing additional security features for any required services, protocols or daemons that are considered to be insecure
- Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.”
A Quantum of Solace…
Open ports are a potentially significant security weakness – more open ports mean more footholds for hackers or malware to use to attack a system. This example was a double-whammy in that, not only is there an FTP service provided by the Schneider Electric ETG3000 FactoryCast HMI Gateway but the authentication is completely redundant due to being hard-coded.
Fortunately, particular vulnerability has now been addressed via a patch update, although advice is provided to at least try and provide some defense against vulnerabilities like these in R2.3. Layering security defenses is a well-acknowledged security best practice and where a known vulnerability exists that cannot be completely mitigated, compensating controls can be used. For example, if there are open ports which need to be used by applications so cannot be disabled, use an internal firewall to protect access unwanted access.
“In the case where unused ports and services cannot be disabled due to technical limitations, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure”
In other words, if the lock on the door to the house is not very strong, a bolt and padlock can be used to bolster protection (and fitting a locked gate on the driveway will only improve security further).
So should the focus be on open ports, or instead on ‘disabling services, daemons and other unnecessary functionality’?
Live and Let Die...
The fact is the two things go hand in hand – ports are opened by processes/services on a host, so if the process/service is removed or disabled, the port will also be ‘removed’ or closed.
This being the case, it could be argued that focusing on the ‘root-cause’ is a better strategy, not least because port numbers are often dynamic – they can change after a reboot or service update – while a service exists in either a stopped or started (albeit the start-up state needs to be examined – no good stopping a service only for it to be kicked into life again after a reboot).
This looks like one of the classic compliance situations where you not only need to do the right thing but then also do whatever it is that the auditor is going to want to see.
Fortunately, NNT Change Tracker Gen 7 will give you simple reports showing both.
‘Do you expect me to talk? secure my systems by removing/disabling unnecessary services?’
‘No Mr. Bond – I expect you to die to prove compliance by showing me an Open Ports report’
New Net Technologies (NNT) is now part of Netwrix