NERC CIP Ports & Services - FoxGuard Solutions

NERC CIP Ports & Services Part 2: Complying With NERC CIP Documentation Requirements White Paper FoxGuard Solutions, Inc. November 2014

NERC CIP Ports & Services: Part 2, Complying With NERC CIP Documentation Requirements Defining Ports And Services In part 2 of our Ports and Services white paper we will discuss the NERC CIP definition of the term “ports and services”, and how to comply with NERC CIP documentation requirements. For a review of what ports and services are, refer to the NERC CIP Ports and Services White Paper Part 1: The Apartment Building Analogy. What Ports And Services Means To NERC CIP Forget what you may already know about ports and services. What we are interested in is the definition of the term as it applies to NERC CIP compliance. More specifically, how those terms are used for audit. The term “ports and services”, is subtly different in the common IT usage than in the OT environment. A clear understanding of these differences in accordance with NERC CIP The term “ports and services”, is subtly different in the common IT usage than in the OT Environment. will make the process of being complaint much easier. The Guidelines and Technical Basis from NERC CIP-007-5, clears away a lot of possible confusion. The Guideline states that “the SDT intends for the entity to know what network accessible ports and associated services are accessible on their assets”.1 This NERC CIP clarification limits the ports to listening ports and their respective services. Other ports in use can vary wildly, and while their use may have some bearing on security, their operation is better covered by an Intrusion Detection System (IDS), and is not within the spirit of this particular requirement. The Importance of Listening Ports One of the difficulties in addressing ports and services requirements, is when common and less specific IT definitions are applied which can cause confusion. These IT style definitions dilute the effectiveness, by diverting resources to documenting and managing network connections that do not have anywhere near the cost/benefit ratio of listening ports and their associated services. The term “listening” is very specific, and can be used to identify which ports the NERC CIP requirement refers to. The requirement states “the entity should know whether they are needed for that Cyber Asset’s function and disable or restrict access to all other ports”.2 1 As of the time of writing this document is available here. http://www.nerc.com/ layouts/PrintStandard.aspx?standardnumber CIP-007-5&title nt&jurisdiction null 2 See NERC CIP 007-5 under “Guidelines and Technical Basis” “Requirement R1:” (page 51) 2

NERC CIP Ports & Services: Part 2, Complying With NERC CIP Documentation Requirements While there is much debate about security versus compliance, this compliance requirement, while not all-encompassing by any means, is a relatively affordable and effective security measure. Services that cannot be executed provide little opportunity for exploit. It doesn’t address exploiting the services you actually use, and isn’t effective if the computer system is already compromised, but it can be very effective in preventing a compromise. The NERC CIP 007-5 R1.1 requirement, is about attack surface area, as stated in the Guidelines and Technical Basis section. It does not verify that the service running on a port hasn’t been modified (there is no file hash check requirement), but that is not the purpose of this requirement. It’s not about forensics of compromised computers. Other Connection Types “Established” connections are very different from listening ports. They do not play a role in initial attack surface area and should be removed when creating ports and services documentation. While documentation for established connections is not required, if producing such documentation is necessary, it already exists. This documentation should be available either on the listening port of the local computer or for the listening port on the “other end” of the connection. That is, the listening machine should have the documentation describing the reason that a listening port was available to establish the connection. This same reasoning applied for other states like “CLOSE WAIT” and “TIME WAIT”. This requirement does not apply to any “non-listening” TCP ports. Otherwise, you would have to document every possible listening port on every device in the plant associated with every ephemeral port on the current device. Even if this were possible in practice, it is not useful when discussing attack surface area. As we have seen, it is obvious the requirement isn’t about forensics of compromised computers, as there is no mention of verifying the associated services haven’t had their executables modified. Only Done Once The core security value of this NERC CIP requirement, shutting down any unnecessary ports, only needs to be done once.3 At this point, hopefully many of your devices already have this done by the vendor before they arrive at your site. Any remaining ports and associated services needed for operation must be documented. 3 NERC CIP 007-5 R1.1 3

NERC CIP Ports & Services: Part 2, Complying With NERC CIP Documentation Requirements So what is left to do? Monitoring devices, to make sure ports aren’t added any time a relevant change is made to the system. That is the only time it should be necessary to document additional listening ports and services. The checks and verification may happen more frequently4, but the actual documentation for the port and service reasoning is only done once at the beginning or when a service is added. “Listening” Later Services that are not current “listening” but may be “listening” at other times, must also be documented. Any service expected to run at any time on a computer must be documented. This means that using a scan of a running computer to develop documentation baseline can lead to problems and inaccurate reporting. Problems can arise using a scan instead of documentation to create the baseline. An example of this might occur if there was a port that was “listening” only on Wednesdays (say during backup), that is not included in your ports and service documentation that you built from the “listening” ports captured on a Monday. In that case, your NERC CIP ports and services audit may show this port open, but not documented, resulting in a compliance issue. The more likely reason that a new listening port may appear would be if you installed additional software on the computer in question. Installing antivirus software for instance may create additional listening ports and associated services, requiring additional ports and services documentation. Documenting RPC Ports and Services Remote Procedure Call (RPC) ports can change each time a computer is rebooted. This requires a little careful documentation and is another reason why just a scan of a running machine can be misleading. While RPC port numbers can change whenever the computer reboots, they will only appear in the RPC range. You can use the following commands, to find out which ports are in the RPC range: netsh int ipv4 show dynamicport tcp netsh int ipv4 show dynamicport udp (Be aware that for this paper we are not addressing IPV6 specifically, though the techniques are very similar.) When you document RPC ports and services, instead of documenting the actual 4 NERC CIP 010-1 R2.1 – “Monitor at least once every 35 calendar days Document and investigate detected unauthorized changes” 4

NERC CIP Ports & Services: Part 2, Complying With NERC CIP Documentation Requirements port number, document that it is an RPC service, and the range of ports where it may appear. You would collect this information from the netsh commands issued on a command line. How to be Compliant Now that we understand the NERC CIP definition of “ports and services”, it simplifies our compliance process. Begin by asking your vendors for ports and services documentation. Scanning a machine should not reveal any additional ports, but fewer ports are generally not an issue, assuming that the service is only active intermittently. You do not want to document ports that are not actually used at some point on the system. A summary of Microsoft Windows ports and services can be found on Microsoft’s website5. Your computer will likely have several other ports and services from additional vendors’ software. The goal is to document and verify listening ports, their associated services, and document their required function or disable/restrict access to them. The process must then be repeated for UDP ports. The Windows 7 Approach Let’s look at the ports that happen to be open at the moment, remembering that the final documentation must include any port that could be open at any time. netstat -oan Depending on the function of the computer, there may be between 50 to 500 line items or more, most of which are not relevant to us. Use the following command to find only TCP listening ports. netstat -oan find “LISTEN” Once you have performed the action above, let’s take a moment to interpret the column data. To save you a lot of unnecessary hardship, let’s begin by reviewing the fourth column of the netstat command output first. The fourth column is primarily used to show the address of another computer for a “non-listening” port. As we are not interested in the “non-listening” ports, remove everything that does not have “LISTENING” in this column. Anything else is not a listening TCP port. Next, divide the second column into two sections; those that beginning with 127.0.0.1 and those that begin with anything else. Throw away any port numbers that begin with 127.0.0.1. The port numbers that begin with 127.0.0.1, mean that the only connections 5 4.aspx 5

NERC CIP Ports & Services: Part 2, Complying With NERC CIP Documentation Requirements allowed to this port are from the local machine itself. The only way these ports could be used to attack the machine, is if the machine is already compromised. If you would like to be more conservative with the compliance process, keep the 127.0.0.1 ports and document them as well. There should only be a small number of these ports. Let’s assume that you are not using IPv6 on your network. If Ipconfig does not show any IPv6 address, they should be unreachable. To completely disable IPv6, follow the Microsoft Knowledge Base article. Unfortunately, some IPv6 items will still appear in the netstat reports, even after IPv6 has been disabled. Like the fourth column, the third column should also be ignored. The third column is the “Foreign Address”, and is most likely all “0.0.0.0:0”. The fifth column is where you find the Process Identification Number “PID”. These are the services of the NERC CIP ports and services requirement. Services You will also need to identify the service associated with the port for your NERC CIP documentation. To find the associated service in Windows 7, use the following command. Netstat -boan The output from this command is very similar to that of netstat -oan, except that after every listening port on lines by themselves, the service name and associated executable may be listed. Once you have completed this process, you must now go back and perform the same steps for all UDP ports as there is no concept of “listening” for UDP connections. The term UDP is specific to TCP style connections. Difficulties There are some difficulties in mapping services to ports for compliance documentation. In particular netstat –boan will return “Cannot obtain ownership information” instead of the service and process name in some instances. This commonly happens for PID 4, “SYSTEM”. Use the following command to lookup additional information about a particular PID (in this example PID 4). 6