Disclaimer: The information I provide is that of my own and does not reflect on the organizations I work for. The information I share should not be the only thing you rely upon for compliance and is provided as-is.
One of the areas of great concern for individuals involved with NERC CIP is CIP standard 007. It is the standard under which most of the work for compliance is done to secure assets. CIP 007 is also the most violated standard. A big offender is standard R2, Ports and Services. It is also a difficult one to comply with since there a large amount of services and ports per asset.
This topic will be broken into multiple posts due to the amount of information that can be shared. Ports and services will also be broken into different posts. I will begin by discussing some areas of overlap.
CIP 007 R2 states, "An entity will disable all unused ports and services not required for normal or emergency operation." The requirement for this standard is interesting. Let's discuss what this means in relation to ports first.
This relates to logical network ports like TCPport 25, which is most often used by SMTP. Ports, as related to compliance and security, considers only listening devices. For those new to network ports this means the network ports that are open and waiting for a connection from other devices or potentially from another process on that computer. NERC CIP does not currently have standards for physical ports on an asset. This does not mean physical ports should not be tracked. As part of its overall security standpoint a company should track and control the physical ports on their devices. Additionally this approach may serve the side benefit of ensuring information is collected when these ports do fall under a compliance standard of one type or another. A person or entity may decide that they want to define what a port and listening port is. As of the time I wrote this post, there was not yet a definition by NERC of either of these, but be sure to check that as new information surfaces daily.
There are multiple ways to collect information about a devices ports. Many devices are capable of listing the ports via their management face through a program or internal function. On a windows and linux based box, a person can run the netstat via the command line. Below is just a small sample of the output that may be seen from running "netstat -abno" windows based box.
This method is going to usually be the most accurate way to collect ports from a device that supports it.
Another way to collect ports from a device is to use a port scanning tool such as NMAP, Angry IP Scanner, etc. This software works by manually checking ports on the device to see if they are open. Usually the tool is run from a remote device. Remember to verify the full TCP and UDP port ranges 0-65535. Scanning only TCP is not sufficient.
Port scanners are usually the only method to collect ports from devices that do not have an internal method to collect ports information. An example of such a device may be a PLC. The output of an NMAP scan using the Zenmap GUI is shown below:
The benefits of using a port scanning tool is that a person can enumerate ports from devices that are incapable of enumerating ports natively. Additionally, all data is usually stored in one location. Some device vendors, like Allen Bradley, will provide software to scan their devices for open ports. In most cases a person or entity should use what their vendor requires.
There are some negatives to using a Port scanning tool.
- Port Scanning isn't always consistent, so a port may be missed. Try multiple scans to catch all listening ports on a device.
- If there are devices such as a firewall, in between the device conducting the scans and the device being scanned, reliable port data may not be retrieved.
- Some devices do not handle being scanned well. They may lock up, slow down, or function in methods that are not acceptable.
- This may mean that a person or entity would want to have an identical device in a non production network that can be re-configured in an identical manner. This device than can be scanned to collect port information.
- Possibly scanning the devices while not in production also may be necessary.
With all of that in mind I would recommend that when companies purchase new devices they ensure that they are capable of natively enumerating port data. There are many network switches, firewalls, control devices that can do this.
There will always be devices that cannot do this so make sure that the person or entity can reliably enumerate the ports of these devices via a Port Scan. Additionally some malicious software can hide listening ports from native commands such as netstat, so an occasional port scan may be useful for comparison purposes.
In the next NERC CIP related post I will share additional port enumeration information as well as methods to "disable" the ports and start to cover services.
