Fri Apr 8 06:49:41 PDT 2016

Zones: Connection controls: How should connections between devices be controlled?


Options:

Definitions:
Define AREAS: {zones / subzones / microzones / components}
Define SEPARATION ENFORCEMENT MECHANISMS: {firewalls / routers / gateways / proxies / guards / protocol changes / digital diodes / FSMs / physical airgaps}
Define CONNECTION MECHANISMS: protocols / traffic types / addressing schemes / addresses / ports / gateway addresses / network masks / interface software / operating environments / storage media / authentication methods / identity management approaches / personnel / control mechanisms / cryptographic protocols, systems, and systems
Define IDENTIFIERS: serial numbers / device codes / cryptographic keys / addresses
Define OPERATING MECHANISMS: physical/logical device / interface / protocol / service / operation
Basis:
Option A: The design basis threat.
Option B: The operating environment.
Option C: Duties to protect.
Option D: Revisit design basis threat as it changes over time.
Option E: Follow applicable elements of applicable standards and requirements.
Option F: Due diligence requirements.
Deter:
Option Q: Use proper online banners to warn against inappropriate actions.
Option R: Provide periodic (at rate) training and suitable education relating to connection control requirements.
Option S: Provide obvious presence of (or don't seek to conceal) some security measures and response processes.
Prevent:
Option 1: Logically separate AREAS by placing SEPARATION ENFORCEMENT MECHANISMS between them.
Option 2: Use different CONNECTION MECHANISMS and OPERATING MECHANISMS within and between different AREAS.
Option 3: {Associate / label / mark / limit} unique IDENTIFIERS to each OPERATING MECHANISMS and map them to their respective AREA(s).
Option 4: Map each connection {sequence} to all relevant OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS and have all such mechanisms deny {operation / connection / flows} to unmapped connections {and sequences}.
Option 5: Secure OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS using available protective mechanisms against unauthorized connections {and sequences}.
Option 6: Limit OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS so that none are unused.
Option 7: Use only end-to-end connections for operations.
Detect, react, and adapt:
Option V: Place logical {alarms / detectors} on SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS for unauthorized (unmapped) or inadequate connections and IDENTIFIERS.
Option W: Surveil and audit {operation / connection / flows / flow sequences} between and within SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS.
Option X: Perform {regular / periodic / random / continuous} {audit reviews / tests} to detect deviation from and verify proper implementation and operation of SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS with frequency based on the design basis threat.
Option Y: Implement response regimens and actions to event sequences per a systems analysis based on the design-basis threat.
Option Z: Follow incidents up with investigative and adaptation processes to identify and mitigate root causes of incidents and improve performance.

Decision:

Typical controls for different risk levels are identified here:

High consequence connection controls are suggested as follows:

Definitions:
    Precisely define all AREAS, SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, IDENTIFIERS, and OPERATING MECHANISMS and put them in the inventory system.

Basis:

    Base all specifics on the design basis threat, duties to protect, risk management decisions, and the environment.
    Precisely define and specify these elements of the protective architecture.
    Revisit these elements of the protective architecture as they change over time.
    Follow applicable elements of applicable standards and requirements.
Deter:
    Use proper online banners to warn against inappropriate actions.
    Provide periodic (4 times per year) training and suitable education relating to connection control requirements.
    Provide obvious presence of (or don't seek to conceal) some security measures and response processes.
Prevent:
    Logically separate AREAS by placing SEPARATION ENFORCEMENT MECHANISMS between them.
    Use different CONNECTION MECHANISMS and OPERATING MECHANISMS within and between different AREAS.
    {Associate / label / mark / limit} unique IDENTIFIERS to each OPERATING MECHANISMS and map them to their respective AREA(s).
    Map each connection and sequence to all relevant OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS and have all such mechanisms deny operation, connection, and flows} to unmapped connections and sequences.
    Secure OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS using available protective mechanisms against unauthorized connections and sequences.
    Limit OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS so that none are unused.
    Use only end-to-end connections for operations.
Detect, react, and adapt:
    Place logical alarms and detectors on SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS for unauthorized (unmapped) or inadequate connections and IDENTIFIERS.
    Surveil and audit operation, connection, flows, and flow sequences between and within SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS.
    Perform regular, periodic, random, and continuous audit reviews and tests to detect deviation from and verify proper implementation and operation of SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS with frequency based on the BASIS.
    Implement response regimens and actions to event sequences per a systems analysis based on the BASIS.
    Follow incidents up with investigative and adaptation processes to identify and mitigate root causes of incidents and improve performance.
High consequence connection controls

Medium consequence connection controls are suggested as follows:

Definitions:
    Define all AREAS, SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, IDENTIFIERS, and OPERATING MECHANISMS at least at the zone, subzone, and microzone granularity level, and put them in the inventory system.

Basis:

    Base all specifics on the design basis threat, duties to protect, risk management, and the environment.
    Follow applicable elements of applicable standards and requirements.
Deter:
    Use proper online banners to warn against inappropriate actions.
    Provide periodic (at least annual) training and suitable education relating to connection control requirements.
    Provide obvious presence of (or don't seek to conceal) some security measures and response processes.
Prevent:
    Logically separate AREAS by placing SEPARATION ENFORCEMENT MECHANISMS between them.
    Associate unique IDENTIFIERS to each OPERATING MECHANISMS and map them to their respective AREA(s).
    Map each connection to all relevant OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS and have all such mechanisms deny connection and flows to unmapped connections.
    Secure OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS using available protective mechanisms against unauthorized connections.
Detect, react, and adapt:
    Place logical alarms and detectors on SEPARATION ENFORCEMENT MECHANISMS for unauthorized (unmapped) or inadequate connections and IDENTIFIERS.
    Surveil and audit connections and flows between and within SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS.
    Perform quarterly audit reviews and tests to detect deviation from and verify proper implementation and operation of SEPARATION ENFORCEMENT MECHANISMS.
    Follow incidents up with investigative and adaptation processes to identify and mitigate root causes of incidents and improve performance.
Medium consequence connection controls

Low consequence connection controls are suggested as follows:

Definitions:
    Define CONNECTION MECHANISMS.
Basis:
    Base all specifics on due diligence requirements and defined duties to protect.
Deter:
    Use proper online banners to warn against inappropriate actions.
    Provide initial training and suitable education relating to connection control requirements.
Prevent:
    Secure CONNECTION MECHANISMS using available protective mechanisms against unauthorized connections.
Detect, react, and adapt:
    Place logical alarms on CONNECTION MECHANISMS for unauthorized connections.
    Audit connections.
    Perform audit reviews of CONNECTION MECHANISMS if negative consequences are identified.
    Follow incidents up with investigative and adaptation processes to identify and mitigate root causes of incidents and improve performance.
Low consequence connection controls

Basis:

Definitions:

For the purposes of this set of decisions, several terms are used that should be defined in detail by the operators of the system environment and cataloged as appropriate to the need. These terms are exemplified as follows:

  • Define AREAS: Connection control is based on the definition of "AREAS" that are separated for various reasons in a zoned architecture. These typically include zones, subzones, microzones, and as risks increase, the more generic "components", for which protection gets as specific as desired.
  • Define SEPARATION ENFORCEMENT MECHANISMS: Separation enforcement mechanisms are mechanisms whose purpose or function is the separation of areas, typically through the control of connections between the areas and the content passing through those connections. These typically include firewalls, routers, gateways, proxies logical guards, protocol changes, and {digital diodes, finite state machines, and physical air gaps}, which are often also considered physical connection controls.
  • Define CONNECTION MECHANISMS: Connection mechanisms are the means by which areas connect to each other. If no connections are required, all areas would/could be physically separated and further connection controls are then strictly for redundancy and assurance. Connections typically involve protocols (e.g., ARP, IP, TCP, Fieldbus, etc.), traffic types (e.g., file transfers, set point changes, voice, etc.), addressing schemes (e.g., MAC only, Private IPs like 10.*.*.* and 192.168.*.*, IPv6, Fieldbus addresses, USB device numbers, etc.), addresses (e.g., 204.7.229.1, 00:00:ff:f3:93:45:b2:9a, etc.), ports (UDP 53, TCP 433, etc.), gateway addresses (e.g., 10.0.0.1), network masks (e.g., 255.255.255.248, 255.0.0.0, etc.), interface software (e.g., drivers, IP stack, TCP wrappers, portmapper, ManAlMail, thttpd, sdns, etc.), operating environments (e.g., Unix, Windows, PLC 2345, OS5, etc. and their supporting hardware, component parts, and contained software in any given system), storage media (e.g., store and forward packet storage, ATM queues, interface and CPU memory, etc.), authentication methods (e.g., cryptographic checksums on traffic and/or content, something you know, have, are, or can do, etc.), identity management approaches, personnel (e.g., people who have to enable a temporary connection), control mechanisms (e.g., call-back modems, timeouts, date and time controls, rate controls, sequence controls, etc.), cryptographic protocols (e.g., Diffie-Helman key distribution, Kerberos, X.509 certificate exchanges, etc.), and so forth.
  • Define IDENTIFIERS: Identifiers are things that allow (unique) identification based on some sort of data. Examples are things like serial numbers that are digitally readable, device codes such as MAC addresses on Ethernet cards, cryptographic keys and other generated content, and network addresses.
  • Define OPERATING MECHANISMS: These are the mechanisms that carry out functions on devices, in this context, the mechanisms at the endpoints of connections that generate, store, and/or use the information exchanged through the connections. This typically includes physical or logical devices (e.g., an actuator or a PLC), interfaces (e.g., a Web sever that feeds a back-end control system), protocols (e.g., a submit commit device to verify an action is to be completed), services (e.g., a data historian service that collects and retains data in a history repository), and operations (e.g., the execution of a sequence of activities starting up a machine).
Basis:
  • The design basis threat. A design basis threat should be defined and applied in making decisions about connections within and between AREAS. While insiders should always be part of the threat considered, specific capabilities associated with specific needs of the design must also be taken into account.
  • The operating environment: The operating environment poses specific requirements for connections, such as effects on traffic management, interference in shared infrastructure, group delay characteristics of CONNECTION MECHANISMS, and so forth.
  • Duties to protect as defined by the management process may also add connection control requirements, for example, associated with contractors vs. employees or different access requirements for different companies in joint ventures.
  • Revisit design basis threat as it changes over time. As threats change, so should protective measures. However, in some systems, implementation changes are costly and operations tend to be over periods of many years. For this reason, it is usually worthwhile to design for the worst anticipated threats with the understanding that as threats change, adaptation may be required. As a general rule, connection controls should not be chasing attackers, but rather, should be preventing attempts with redundancy and detecting weaknesses in protections that are otherwise unexpected.
  • Follow applicable elements of applicable standards and requirements. For example, classified information has specific separation requirements that are very different from interference requirements associated with operational efficiency.
  • Due diligence requirements. In the absence of other guidance, due diligence requirements should always be followed. These are generally driven by industry standards or common usage and process. For example, default passwords on components should normally be changed before installation and use.
Deter:
  • Use proper online banners to warn against inappropriate actions. Warning signs associated with connections are often associated with human sessions, and automated notices are even used to define such things as which encryption protocols are allowed or required for connections. Such notices may effectively deter some accidental misuse, but have little real value against more serious intentional threats.
  • Provide periodic (at rate) training and suitable education relating to connection control requirements. Those who are supporting connections need to be trained in the specific mechanisms in place both so they can properly implement them and so they understand what is happening in debugging and operations. The rate of training for connection control should be relatively low, typically an initial training, updates when things change, and refresher courses for those who don't often have responsibilities in these areas. In day-to-day operations, no ongoing training relating to connection control is normally required.
  • Provide obvious presence of (or don't seek to conceal) some security measures and response processes. Without giving full details of underlying mechanisms, it is appropriate to train all workers who might interact with system environments on the operating rules and the consequences of violations. This is normally embedded in ongoing training as one of many things that is updated periodically to keep people aware of their responsibilities, reduce errors and omissions, and limit liability. It is also useful to make people aware of periodic audits of systems and usage and to verify usage with operators during periodic checks to keep them aware of the fact that processes are in place and do detect activities, as well as to verify that processes are working properly (e.g., Is it true that there were no manual control actions taken at all during your shift last Tuesday night? That seems unusual compared to every other shift this month...).
Prevent:
  • Logically separate AREAS by placing SEPARATION ENFORCEMENT MECHANISMS between them. Zones and subzones are separated by SEPARATION ENFORCEMENT MECHANISMS to assure that connections are only made between, from, and to authorized AREAS and OPERATING MECHANISMS under authorized conditions.
  • Use different CONNECTION MECHANISMS and OPERATING MECHANISMS within and between different AREAS. This approach uses separate and different CONNECTION MECHANISMS in different AREAS so that accidental and intentional cross-connects cannot result in communications or interference. For example, if an IP fiber network is used in a subzone associated with remote access to SCADA systems and a copper Fieldbus network is used to connect SCADA systems to PLCs, a cross connect will not physically or logically operate or interfere or interact with other operations. Similarly, separate and different OPERATING MECHANISMS in different AREAS (e.g., HMI uses Windows, SCADA uses Unix, and PLCs use custom operating environments) assures limited effects and increased complexity for attackers (e.g., the same vulnerabilities that may allow access to the HMI will not allow a direct exploit of the SCADA system or PLC, and a virus that gets into the HMI may not have the capability to get into the SCADA or PLC). At a minimum, this makes the job of an attacker harder and common mode failures less likely.
  • {Associate / label / mark / limit} unique IDENTIFIERS to OPERATING MECHANISMS and map them to their respective AREA(s). The use of unique identifiers provides the means to attribute effects to causes at the level of the identified entity. In order to do this, the identifier has to be reliably linked to the OPERATING MECHANISMS and reliably applied during operation, audit, and review processes. In essence, this approach means that an inventory is done and unique inventory tags are associated with all inventory items.
  • Map each connection {sequence} to all relevant OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS and have all such mechanisms deny {operation / connection / flows} to unmapped connections {and sequences}. Mapping connections and mechanisms into the operation of the system provides the means to assure that only authorized mechanisms {and sequences} perform authorized acts per the design of the system. In essence, this links inventory to work flow in the sense that the system environment enforces that only authorized work flows are permitted per the operating plan of the system.
  • Secure OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS using available protective mechanisms against unauthorized connections {and sequences}. This implies that the mechanisms cannot receive or send connections {or connection sequences} other than those explicitly authorized. For example, services on ports (internal or external) that could receive connections that are not authorized to occur {or are not in the correct point in a sequence to occur} should be removed from the system {and/or disabled} so that even if such a connection was attempted, it would not function. For outbound connections, it is a good idea to block the connections (e.g., with an internal firewall refusing unauthorized outbound traffic and by disabling unused physical ports, etc.). For inbound connections, unauthorized connections should not be supported by an available and enabled service (other than a deception is called for), and should use a firewall to block such connections if attempted. Note that some sequences may require completion, in which case, if they fail to complete, the proper failsafe approach should be taken to authorizing (or not) subsequent elements of the legitimate (or other) sequences. Another way to think of this is that all failure sequences should also be considered in authorized connection sequencing.
  • Limit OPERATING MECHANISMS, CONNECTION MECHANISMS, and SEPARATION ENFORCEMENT MECHANISMS so that none are unused. This approach removes all mechanisms {to the finest level of granularity available) (e.g., the port level, the interface level, the driver level, etc.). By removing the underlying support mechanisms (both physical and logical), even a successful exploitation of a component will not provide otherwise unnecessary infrastructure to support exploitation of the overall system. For example, mechanisms should not have any unnecessary drivers, software, or capabilities present that might allow unauthorized connections to be created or operated. This follows the minimum necessary capabilities approach.
  • Use only end-to-end connections for operations. In essence, this means that all connections should be devised so that they only go point to point per the needs of the system, however, from a logical standpoint, since actual hard wiring may not be the path to connections, end-to-end encryption, authentication, or other methods should be used.
Detect, react, and adapt:
  • Place logical {alarms / detectors} on SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS for detecting unauthorized (unmapped) or inadequate connections and IDENTIFIERS. Detectors allow for detection of tampering (changes), access (entry, exit, use), and presence or absence (of a connection). Alarms use sensor data to inform an analysis and response process. Timeliness of alarms and response depends on the need for timely response to mitigate potentially serious negative consequences. Detectors should support and inform alarms, audit, and review processes, while alarms should be in time to mitigate potentially serious negative consequences of excess, inadequate, or inappropriate connections. For example, if the normal system sequencing involves a sequence of connections and disconnections, and one of the connections in the sequence is missing, at the time or in the condition that the connection is detectable as missed, the alarm should be triggered, and to the extent feasible, a response process should be in place to mitigate the potentially serious negative consequences of the missed connection.
  • Surveil and audit {operation / connection / flows / flow sequences} between and within SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS. This activity produces independent records of connections that can then be verified against expected behaviors and other recorded behaviors to detect inconsistencies, diagnose problems, support root cause analysis in cases of incidents, and document event sequences that have taken place. In normal system environments, these would not be recorded as part of the data historian function. To the extent feasible, these processes should be so designed as to make different situations differentiable based on the inconsistencies to the level of simultaneous faults associated with the fault model.
  • Perform {regular / periodic / random / continuous} {audit reviews / tests} to detect deviation from and verify proper implementation and operation of SEPARATION ENFORCEMENT MECHANISMS, CONNECTION MECHANISMS, and OPERATING MECHANISMS with frequency based on the design basis threat. For audits that have been undertaken, deviation from normal connection patterns, inconsistencies between different data sources, and related analysis can be done to verify proper operation of the protective system as well as the system operating environment. In addition, for testing purposes, these analyses can be used to verify that the audit and other detection and response processes are working as expected, including tests involving the intentional alteration of operations and/or records. Redundancy should be designed so that different deviations from normal operation are differentiable by differences in inconsistency to the level of simultaneous failures anticipated in fault models so that one sequence does not mask as another.
  • Implement response regimens and actions to event sequences per a systems analysis based on the design-basis threat. Response regimens typically depend on how quickly how much force has to get to what location in order to mitigate what harm and how many such responses are needed per unit of time. This calls for analysis of event sequences, typically based on the threat and their capabilities and intents, and the nature of the protective system.
  • Follow incidents up with investigative and adaptation processes to identify and mitigate root causes of incidents and improve performance. A long-term approach to protection involves not only detecting and responding to incidents, but also ongoing improvements so that the proximate and root causes of failures are identified and the architecture is changes or operations enhanced to reduce the number and severity of events over the long term.
Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved