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
|