Electronic Security Perimeter

Over at his blog, Tom Alrich commented to me:

"objectives-based requirements are the only way not to have the situation you discussed (drawing from Lew Folkerth's recent article in RF's Newsletter)- where an entity can be doing great things for cyber security that the auditors can't even consider because they're not in their "zone of authority" (in this case, the ESP). 

Objectives-based requirements would have to be built on top of a framework of concepts that goes beyond just BCS and ESP's, to include all of the entity's computing infrastructure (including "IT" networks)."

I definitely agree that the ESP construct is inherently limiting. For one thing, it is established by arbitrarily drawing a line, identifying where the access point (with controls applied) is, and it only exists at OSI Model Layer 3: routable protocols. Lest we forget, not all security takes place at Layer 3, it's simply the easiest place to measure.

Right now, guidance from NERC and the regions tells us that we cannot use a Layer 2 switch with some ports inside the ESP and some outside. Some would argue you can't use any switch, even a Layer 3 or 4 switch this way. However, there is no requirements language that says this is the rule. It's not a clearly established and absolute security best practice. The reason there can't be any NERC CIP requirements around this is because the ESP is defined strictly at Layer 3, and it was done that way on purpose to exclude Layer 2 connections from needing ACLs (access control lists) and firewalls. Here's the relevant reasoning from CIP-005  Guidelines & Technical Basis: 

"This requirement applies only to communications for which access lists and ‘deny by default’ type requirements can be universally applied, which today are those that employ routable protocols. Direct serial, non-routable connections are not included as there is no perimeter or firewall type security that should be universally mandated across all entities and all serial communication situations. There is no firewall or perimeter capability for an RS232 cable run between two Cyber Assets. Without a clear ‘perimeter type’ security control that can be applied in practically every circumstance, such a requirement would mostly generate technical feasibility exceptions (“TFEs”) rather than increased security."

It's not easy to measure security being applied to layer 2, so we define this type of connectivity out of relevance. Good security would be to apply controls upstream to those devices which can participate, but the device-centric focus of early CIP standards language leads people away from thinking in these terms. Security doesn't have to be "perimeter" based, and generally in a modern layered approach security functions are distributed across multiple devices/systems within your network. They're not all "on the perimeter" so the current NERC CIP standards apply poorly if at all to this strategy. We need some changes to the dominant paradigm. At the same time, we don't need auditors crawling into every ancillary system in our IT department.

Some concepts that add to the discussion:

Accessing a device means the ability to view/modify it's configuration settings. This can be because the device interacts only in the data plane and doesn't have a separate management plane, i.e. a Windows Server. It could be access to a dedicated management port.

Traffic transiting a device means that the packets are forwarded via that device. It doesn't necessarily mean that the user originating the traffic has the ability to view or modify the device in question, in most cases they may not even be aware that the device exists in the traffic stream. Packets crossing a router, switch, or firewall in the data plane would be examples.

Management plane is the logical function which allows a user to interact with the configuration settings of a system. It includes any dedicated management ports, the user interface (terminal emulation of graphical users interface), and the network connectivity to these if accessing remotely (really remote access, which means from anywhere not directly connected, not NERC CIP remote access which only means from outside the ESP).

Control Plane is the logic embedded in the code base of the system. Admins can modify the control plane logic, but usually only by replacing the code base (upgrades, patching, etc.)

Data plane is just packet switching. traffic is generated by users or devices, and sent to a destination IP address. It is switched, routed, forwarded to devices inline along the way. This traffic has no access to the Control Plane or Management Plane on a properly configured network appliance (including hypervisors).