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 TCP
port 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.
