Internet DRAFT - draft-murillo-mile-cps
draft-murillo-mile-cps
INTERNET-DRAFT
Internet Engineering Task Force (IETF) M. Murillo
Request for Comments: 6684 IEEE
Category: Informational January 2014
ISSN: 2070-1721
Expires: July 11, 2014
IODEF extension for Reporting Cyber-Physical System Incidents
draft-murillo-mile-cps-00.txt
Abstract
This draft document will extend the Incident Object Description
Exchange Format (IODEF) defined in [RFC5070] to support the reporting
of incidents dealing with attacks to physical infrastructure through
the utilization of IT means as a vehicle or as a tool. These systems
might also be referred as Cyber-Physical Systems (CPS), Operational
Technology Systems, Industrial Control Systems, Automatic Control
Systems, or simply Control Systems. These names are used
interchangeably in this document. In this context, an incident is
generally the result of a cybersecurity issue whose main goal is to
affect the operation of a CPS. It is considered that any
unauthorized alteration of the operation is always malign. This
extension will provide the capability of embedding structured
information, such as identifier- and XML-based information. In its
current state, this document provides important considerations for
further work in implementing Cyber-Physical System incident reports,
either by utilizing any already existing industry formats (XML-
encoded) and/or by utilizing atomic data.
In addition, this document should provide appropriate material for
helping making due considerations in making an appropriate decision
on how a CPS reporting is done: 1) through a data format extension to
the Incident Object Description Exchange Format [RFC5070], 2) forming
part of an already existing IODEF-extension for structured
cybersecurity information (currently draft
draft-ietf-mile-sci-11.txt), or others. While the format and
contents of the present document fit more the earlier option, these
can also be incorporated to the later.
Citations and references
Some of the text in this document has been taken from other MILE
documents, most notably draft-ietf-mile-sci-11.txt and RFC-5901. In
addition, some of the text has been taken from the references at the
end of the document. We have tried to adequately reference. Once
this document turns into an "official draft", these issues will be
taken care of and additional references added. For the sake of
circulating the document so as to get feedback on its focus, we leave
Murillo Informational [Page 1]
RFC 6684 IODEF Extension December 2013
this task for the immediate future.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF).
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Note that other groups may also distribute working documents as
Internet-Drafts. The list of current Internet-Drafts can be
accessed at http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6684.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. What are Cyber-Physical Systems? . . . . . . . . . . . . . 5
1.2. Components of a Cyber-Physical System . . . . . . . . . . 6
1.3. Incidents in Cyber-Physical Systems . . . . . . . . . . . 7
1.3.1. Mainstream IT computer security incident . . . . . . . 8
1.3.2. Cyber-physical system incident . . . . . . . . . . . . 8
1.4. Why the appropriate reporting of a control system is
needed . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Examples of physical system attacks/incidents
(Eventual case studies for validation of the incident
report) . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. What types of incidents to report? . . . . . . . . . . . . 10
1.7. Why a special extension is needed . . . . . . . . . . . . 11
Murillo Informational [Page 2]
RFC 6684 IODEF Extension December 2013
1.8. Relation to the IODEF Data Model . . . . . . . . . . . . . 11
2. Terminology Used in This Document . . . . . . . . . . . . . . 12
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 12
3. The Elements of a physical system attack . . . . . . . . . . . 12
3.1. Cyber-Physical System Extensions to the IODEF-Document . . 14
4. Cyber-physical Reporting via IODEF-Documents . . . . . . . . . 14
4.1. Report Types . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. CyberPhysicalReport Report XML (possible/alternative)
Representations . . . . . . . . . . . . . . . . . . . . . 15
4.3. Syntactical Correctness of Cyber-Physical Reports . . . . 17
5. SCyberPhysicalReport Element Definitions . . . . . . . . . . . 17
5.1. CyberPhysicalReport Structure . . . . . . . . . . . . . . 17
5.2. Reuse of IODEF-Defined Elements . . . . . . . . . . . . . 18
5.3. Element and Attribute Specification Format . . . . . . . . 18
5.4. Version Attribute . . . . . . . . . . . . . . . . . . . . 19
5.5. IncdntType Attribute . . . . . . . . . . . . . . . . . . . 19
5.6. The IncidentTitle element . . . . . . . . . . . . . . . . 19
5.7. The ReportingParty element . . . . . . . . . . . . . . . . 19
5.8. The ReportReliability element . . . . . . . . . . . . . . 19
5.9. The IncidentType element . . . . . . . . . . . . . . . . . 19
5.10. The Industry element . . . . . . . . . . . . . . . . . . . 19
5.11. The TargetSystems element . . . . . . . . . . . . . . . . 19
5.12. The CyberPhysicalDepth element . . . . . . . . . . . . . . 19
5.13. The TransportMedium element . . . . . . . . . . . . . . . 20
5.14. The Exploit element . . . . . . . . . . . . . . . . . . . 20
5.15. The EntryPoint element . . . . . . . . . . . . . . . . . . 20
5.16. The PerpetratingParty element . . . . . . . . . . . . . . 20
5.17. The DetectionMethod element . . . . . . . . . . . . . . . 20
5.18. The CommandAndControlCenters element . . . . . . . . . . . 20
5.19. The CompromisedPhysicalInfrastrucute element . . . . . . . 20
5.20. The ConstrolSystem element . . . . . . . . . . . . . . . . 20
5.21. The OrganizationalImpact . . . . . . . . . . . . . . . . . 20
5.22. The RecurrencePreventionMeasures element . . . . . . . . . 21
5.23. The BriefDescriptionOfIncident element . . . . . . . . . . 21
5.24. The Logs element . . . . . . . . . . . . . . . . . . . . . 21
5.25. The References element . . . . . . . . . . . . . . . . . . 21
5.26. The ProtocolType element . . . . . . . . . . . . . . . . . 21
5.27. The NetworkType element . . . . . . . . . . . . . . . . . 21
6. Mandatory IODEF and CyberPhysicalReport Elements . . . . . . . 21
6.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 22
6.2. An XML Schema for the Extension . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22
7.2. Using the iodef:restriction Attribute . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Manageability Considerations . . . . . . . . . . . . . . . . . 23
10. Appendix A: XML Schema Definition for Extension . . . . . . . 23
11. Appendix B: Examples . . . . . . . . . . . . . . . . . . . . . 23
Murillo Informational [Page 3]
RFC 6684 IODEF Extension December 2013
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Murillo Informational [Page 4]
RFC 6684 IODEF Extension December 2013
1. Introduction
Cyber-Physical and related systems have taken a key role in all types
of infrastructures for decades. These are now at a higher risk to be
the target of attacks by motivated and highly-skilled attackers,
these being individuals, groups, or nation-states [ACS]. Among the
issues that catalyse this higher risk are: i) these systems are
gradually becoming more interconnected, ii) legacy systems do not
have proper cybersecurity protection, iii) the existence of highly-
skilled individuals and motivations, iv) some these systems are
generally considered critical, v) these are a natural extension of IT
cyber-attacks, vi) the emergence of the Internet of Things (IOT), and
vi) these attacks can be carried out remotely and quite
inexpensively.
While over 90% of critical control system infrastructure is currently
owned by private enterprises, these can have direct repercussions on
national security [SFC]. Indeed, various of these systems are key
parts of nuclear reactor facilities, missile systems, transportation
systems, electric power distribution, oil and natural gas
distribution, water and waste-water treatment, dam infrastructure,
and others. They are also at the core of health-care devices and
transportation management. The disruption of these control systems
could have a significant impact on public health, safety, and lead to
large economic losses.
Sections Section 2 and Section 3 of this document provide an overview
of the terminology, architecture, and process of a cyber-physical
event. Section Section 4 introduces the high-level report format and
how to use it. Sections Section 5 and Section 6 will describe the
data elements of the cyber-physical extensions. The appendices will
include an XML schema for the extensions and a few examples Cyber-
Physical Systems reports.
1.1. What are Cyber-Physical Systems?
Cyber-Physical Systems are computer- or microprocessor- or
microcontroller-based systems that monitor and control physical
processes [ACS]. A basic example of a control system is the heating
system of a room. The system is composed of a regulation knob,
regulating box, heating device, thermostat, and appropriate cabling
that links these devices. A human sets the desired temperature and
the control system continuously regulates the heating device in order
to maintain the desired temperature throughout the day. The current
temperature of the room, which naturally will be much influenced by
outside conditions, is continuously read by the controller through
one or many sensors. Such reading is fed back to the regulating box,
which holds a control system algorithm that provides the rules on how
Murillo Informational [Page 5]
RFC 6684 IODEF Extension December 2013
this regulation will take place. More complex control systems are
the core of industries such as oil, gas, water, nuclear, electric
grid, and others. For example, the electricity industry utilizes
industry control systems to control the nuclear processes for the
delivery of electricity. In this case, the operators will be located
in control rooms that continuously display the health of the systems
and request asynchronous input from the operators.
"Industrial control system" is a general term that include
supervisory control and data acquisition (SCADA) systems, distributed
control systems (DCS), and others. One of the primary differences
between the two is that DCS are usually located within a more
confined factory or plant-centric area, when compared to
geographically dispersed SCADA field sites [RKAL].
1.2. Components of a Cyber-Physical System
Figure 1 illustrates a general composition of an industrial control
system [ACS], [SFC]. Devices located at the Corporation Workspace
(a), network (b), and operation workstation (c) could be considered
mainstream IT infrastructure; these workstations run special programs
that display the status of processes and are connected to a Local
Area Network, a Wide Area Network, and possibly the Internet.
From the control network (d) downwards, the infrastructure differs,
with specialized protocols for control networks, specialized devices
(PLCs and RTUs) that house automation algorithms (e), sensors and
actuators that operate and measure physical variables (g), and
specialized networking infrastructure and protocols (f). The
Operator Workstation (b) provides supervisory commands which are
generally given by humans. Partly as a result of the advent of the
Internet and new powerful devices, control system infrastructure is
increasingly inheriting some infrastructure from IT systems [SFC].
Sensors (g) are devices that can measure temperature, pressure, water
level, nuclear centrifuge rotor speed, and others. Actuators (g)
enable/disable/regulate heating elements, motor speed, water pumps,
reservoir locks, and others. Programmable Logic Controllers (PLCs)
(e) house special control system algorithms that read sensors and
command the actuators based on these readings and a multitude of
control schemes; such task is done automatically in real-time. PLCs
are generally utilized to coordinate work in closed environments,
while Remote Terminal Units (RTUs) are generally utilized to
coordinate remote operations, task generally coordinated by control
servers (c).
An important fact about ICS is that Control networks are often more
complex than plain IT systems and require a different level of
Murillo Informational [Page 6]
RFC 6684 IODEF Extension December 2013
expertise: control networks are typically managed by control
engineers, not IT personnel [SFC].
+-------------------------------------------+
| Corporation Workspace | (a)
+-------------------------------------------+
^ ^
------------------------|----------------------|------------------------ Corporate
| | (b) Network
v v (mainstream IT system)
+--------------------+ +--------------------+
|Operator Workstation| | Control Servers | (c)
+--------------------+ +--------------------+
^ ^
| |
v v (d)
------------------------------------------------------------------------ Control
^ ^ ^ Network
| | | (wired/wireless)
v v v
+-----------------+ +-----------------+ +-----------------+
| | RTU/PLC | | | | RTU/PLC | | | | RTU/PLC | | (e)
| +---------+ | | +---------+ | | +---------+ |
| ^ | | | ^ | | | ^ | | (f)
----|----|-----|------|----|----|-----|----------------|-----|---------- Field
| | v | | | v | | | v | Area
|------+ +--------| |------+ +--------| |------+ +--------| Network
|Sensor| |Actuator| |Sensor| |Actuator| |Sensor| |Actuator| (g)
+----------------------------------------------------------------------+
| |
| P H Y S I C A L I N F R A S T R U C T U R E | (h)
| |
+----------------------------------------------------------------------+
Figure 1: A general Cyber-Physical System infrastructure
1.3. Incidents in Cyber-Physical Systems
In the context of cyber-physical systems (i.e. industrial control
systems), an incident can be a mainstream IT incident itself (a, b,
c) or the misbehaviour of a cyber-physical system (d, e, f, g, h) as
a result of an IT incident. See Figure 1. The IT incident might
intentionally seek to infiltrate the very PLCs and RTUs with aim to
monitor and, in extreme scenarios, alter the operation of these
devices and thus influence the operation of physical infrastructure.
Incidents are known to be originated because numerous reasons,
Murillo Informational [Page 7]
RFC 6684 IODEF Extension December 2013
including adversarial sources such as hostile governments, terrorist
groups, industrial spies, disgruntled employees, malicious intruders,
and natural sources such as system complexities, human errors and
accidents, equipment failures, and natural disasters [SFC].
1.3.1. Mainstream IT computer security incident
As per IODEFs, an incident can be a:
a. Benign configuration issue
b. computer/network incident
c. infraction to a service level agreement (SLA)
d. system compromise
e. socially engineered phishing attack
f. denial-of-service (DoS) attack
g. others
1.3.2. Cyber-physical system incident
A Cyber-physical incident can imply the presence of all the above IT
computer security incidents. However, given the extra tasks carried
out at lower layers (i.e. d - h) and the presence of dynamic physical
infrastructure, the following issues are added to the incident list:
a. Control room alarm as a result of a 1) IT system misbehaviour
(i.e one or more of the above), or 2) as a result of a physical
system misbehaviour due to and IT system compromise, which might
or might not have been detected
b. Misbehaviour of a physical system as noticed at the physical
infrastructure level: explosion, flooding, pressure loss, and
others
c. Misconfiguration or degradation of control system performance, as
noticed by an operator. Extremely sophisticated attacks carried
out by control system experts might carry out these types of
attacks (i.e. compromising/missconfiguring control system schemes
such as feedback control, robust control, optimal control, fault
detection and estimation, others)
d. The disruption of control systems operation due to the blocking
of the flow of information through corporate or control networks
Murillo Informational [Page 8]
RFC 6684 IODEF Extension December 2013
(d, f), thus causing information transfer bottlenecks or denial
of service by IT-resident services (such as DNS) [SFC]
e. Illegal or unauthorized changes made to programmed instructions
or variables in PLCs, RTUs, DCS, or SCADA controllers (alarm
thresholds changed, unauthorized commands issued to control
equipment). This change can be benign or malign, with goals of
damaging or disabling equipment (if tolerances are exceeded),
premature shutdown of processes (i.e. electricity or gas
transmission lines), and physical damage (explosion, flooding,
and others).
f. False information sent to control system operators or to
corporate HQ either to disguise unauthorized changes or to
initiate inappropriate actions by system operators or other
stakeholders SFC [SFC]
g. The modification of control system software or configuration
settings, producing unpredictable results
h. Malicious software (e.g., virus, worm, Trojan horse) introduced
into the system
i. Recipes (i.e., the materials and directions for creating a
product) or work instructions modified in order to bring about
damage to products, equipment, or personnel
It is important to note that, regardless on how the attack in
originated (Internet, portable storage, insider job), there will
generally always be, at least, IT components involved. Whether
critical infrastructure is connected to the Internet is not a
determinant on whether such will be attacked.
1.4. Why the appropriate reporting of a control system is needed
Control system incidents can cause irreparable harm to the physical
system being controlled and to individuals. The reporting of a
control system incident could save lives. A main goal of a well
designed CPS attack will generally be to be unperceived and bypass
basic (or mainstream) IT security defences in order to affect the
physical world. In these situations, a possible incident will be
abnormal operation of a physical system, generally represented by a
control room alarm, perceived odd behaviour, or, in extreme
scenarios, explosions, flooding, or other forms of physical
infrastructure misbehaviour.
In this context, holding to report a physical incident until an IT
incident surfaces (in case of a zero-day-worm attack, for example)
Murillo Informational [Page 9]
RFC 6684 IODEF Extension December 2013
can be a matter of life and death, more when other similar facilities
are operated in other points, or when these operate in conjunction
with the others (i.e. electric grid, gas pipelines). This is the
case of the STUXNET worm, whose first observed symptom were the
misbehaviour of nuclear centrifuges, with no control room alarms. It
was months until researchers were able to detect the IT worm. The
reporting of control system incidents from different locations could
have possibly lead to its earlier detection.
Thus, the reporting of a cyber-physical incident is extremely
important. By using a common format, it becomes easier for
organizations to engage in coordination as well as correlation of
information from multiple data sources or products into a cohesive
view. As the number of data sources increases, a common format
becomes even more important, since otherwise multiple tools would be
needed to interpret the different sources of data. An important
advantage of a common format is the ability to automate many of the
analysis tasks and significantly speed up the response activities.
1.5. Examples of physical system attacks/incidents (Eventual case
studies for validation of the incident report)
a. Australia
b. US
c. Iran
d. Others
1.6. What types of incidents to report?
a. Physical system incident, as observed by a stakeholder outside
the control room (i.e. flooding, explosion, etc)
b. All incidents of Section Section 1.3.2
c. Mainstream cybersecurity incident in a control system
infrastructure context, as observed by mainstream IT tools and
reported by IODEF and its structured cybersecurity extension
d. Incidents related of the Internet of Things, especially in the
context of the automation of buildings, vehicles, and other
infrastructure
e. A combination of the above
Murillo Informational [Page 10]
RFC 6684 IODEF Extension December 2013
1.7. Why a special extension is needed
IODEF provides a means to describe a cyber-physical incident
information, but it would need to include various non-structured
types of incident-related data tailored to physical systems in order
to convey more specific details about what is occurring. Similarly,
the IODEF-extension for structured cybersecurity information,
currently a draft (draft-ietf-mile-sci-11.txt), would increase the
machine readability of CPS incidents; however it would still need to
be considerably modified in order to provide appropriate contextual
machine readability.
Further structure within IODEF through any means increases the
machine-readability of the document thus providing a means for better
automating certain cybersecurity operations. Furthermore, because
Cyber-Physical Systems are real-time and are for the most part
automated, machine friendly data is paramount for effective incident
response and coordination. This is even more relevant when very
frequent reports are needed in these real-time systems that can have
complex dynamics. Naturally this is also applicable, at a degree, to
information in control room and even in corporate headquarters.
For instance, a worm might use zero-day attack and a PLC rootkit to
attack a nuclear reactor. Special anomaly detection technology and
backup sensors might detect unusual centrifuge control system input
and output patterns. The institution might have similar facilities
in different points in the nation. Then, enriched IODEF incident
reports would be sent to other plants and to a central database.
Such exchange of information would increase the chances to know
quicker the source of the problem and to provide remediation. In the
context of several independent systems, incident reports would help
control equipment vendors quickly pinpoint weaknesses or exploits
that were taken advantage of and make adequate fixes. In the case
that a physical system is damaged, prompt incident reporting would
avoid the same happening in other points.
This reporting is not limited to public or mainstream private
infrastructure (industry), but also to home automation systems and
various environments that form part of the Internet of Things and
could pose significant physical dangers if compromised.
1.8. Relation to the IODEF Data Model
Instead of defining a new report format, this document seeks to
define an extension to [RFC5070]. The IODEF defines a flexible and
extensible format and supports a granular level of specificity.
These cyber-physical extensions will reuse subsets of the IODEF data
model and specify new data elements. Leveraging an existing
Murillo Informational [Page 11]
RFC 6684 IODEF Extension December 2013
specification allows for more rapid adoption and reuse of existing
tools in organizations. For clarity, and in order to eliminate
duplication, only the additional structures necessary for describing
the exchange of cyber-physical activity will be provided; however the
context of the location (i.e. different levels) will be considered in
making appropriate decisions.
2. Terminology Used in This Document
Since many people use different but similar terms to mean the same
thing, we underline the use of the following terminology in this
document.
a. Cyber-Physical System. Also referred in this document as
Operational Technology Systems or Industry Control System or
Automatic Control Systems. Portions of a cyber-physical system
can be considered a subset of Information Technology.
b. Cyber-physical event. The compromise of the Control Network,
Field Area Network, Physical Infrastructure, or the compromise of
any resource that influences the operation of the those entities
c. Physical infrastructure. Any physical infrastructure and
premises that is part of a Cyber-physical system. Among many
others, this categorization includes: nuclear reactors, oil and
gas pipelines, water and electricity distribution systems,
electricity generation systems, chemical plants, oil refineries,
weapons systems, railway systems, traffic control systems,
health-related systems, and critical infrastructure that form
part of the Internet of Things.
d. Control room. Part of a control system infrastructure where
humans monitor the overall status of the processes and make
appropriate changes. These changes can be: set-points for
processes (i.e. the power/level at which nuclear centrifuges will
function), shutting down processes under a failure, and others..
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Elements of a physical system attack
A cyber-physical attacks are normally comprised of the following
components. Data related to these elements or actors is key to
capture in order make the event analysis and correlation with other
Murillo Informational [Page 12]
RFC 6684 IODEF Extension December 2013
events more useful:
a. The main attacker or party perpetrating the sabotaging activity.
Most times this party is not readily identifiable.
b. The command and control centre. Generally compromised servers
are at different locations. These can be used for sending
instructions and for acquiring data, among others.
c. The ultimately targeted physical infrastructure (nuclear
centrifuges, boilers, pressure chambers, pipelines, liquid
control systems, dams, room heating, traffic lights, railway
systems etc). Note that IT cybersecurity events might not have
as a goal to target physical infrastructure, however might cause
adverse consequences to these, as a result of a DoS attack, for
example.
d. The devices that control the physical infrastructure: Control
Network node(s), Field Area Network devices, Control Severs, and
the wired and wireless networks and special protocols that
connect them
e. Sensors and/or actuators that measure and manipulate physical
infrastructure
f. The wired and/or wireless control network or field area network
g. The special control system algorithms that reside in PLCs,
Control Servers, or sensor networks. These algorithms are based
on control theory that determines the type of control to use
(basic feedback control, robust control, optimal control, and
others) and its gain parameters (proportional, integral,
derivative, etc) [SFC]
h. Special supervisory and fault detection and estimation agents
that monitor processes.[MMJS]
i. Sensor networks, generally locally distributed sets of wireless
devices that measure and actuate physical devices. These are
gradually being part of critical infrastructure.
j. The Internet or a removable device through which the malware
infects the cyber-physical system
k. A human being, whom, willingly or unwillingly transports (and in
some cases, injects) malware
Murillo Informational [Page 13]
RFC 6684 IODEF Extension December 2013
l. A control room operator (or operators) that regulate set-points,
react to alarms, and carry out supervisory duties
m. Detection information and Analysis output
n. Input/Output logs.
3.1. Cyber-Physical System Extensions to the IODEF-Document
Cyber-Physical System events are reported in a Cyber-physical
activity report, which is an instance of an XML IODEF-Document
Incident element with added EventData and AdditionalData elements.
The additional fields in the EventData specific to cyber-physical
incidents are enclosed in a CyberPhysicalReport XML element.
As a Cyber-Physical System attack may generate multiple reports to an
incident team, multiple CyberPhysicalReports may be combined into one
EventData structure, and multiple EventData structures may be
combined into one incident report. One IODEF incident report may
record one or more individual Cyber-physical events and may include
multiple EventData elements.
This document will define new extension elements for the EventData
IODEF XML elements and identifies those required in a
CyberPhysicalReport. The appendices will contain sample activity
reports and a complete schema. This Cyber-physical extension reuses
subsets of the IODEF data model and, where appropriate, utilizes
other extensions or specifies new data elements.
The IODEF Extensions defined in this document comply with Section 4,
"Extending the IODEF Format" in [RFC5070].
4. Cyber-physical Reporting via IODEF-Documents
4.1. Report Types
As described in the following subsections, reporting cyber-physical
events has three primary components: choosing a report type, a format
for the data, and how to check the correctness of the format.
Similarly, there are three actions relating to reporting CPS events.
First, a reporter or an automated system may *create* and exchange a
new report on a new event. Secondly, a reporter may *update* a
previously exchanged report to indicate new information. Lastly, a
reporter may have realized that the report is in error or contains
significant incorrect data and that the prudent reaction is to
*delete* the report.
Murillo Informational [Page 14]
RFC 6684 IODEF Extension December 2013
The three types of reports are denoted through the use of the ext-
purpose attribute of an Incident element. A new report contains an
empty or a "create" ext-purpose value; an updated report contains an
ext-value value of "update"; a request for deletion contains a
"delete" ext-purpose value. Note that this is actually an advisory
for the report originator or recipients; operations might decide to
file a new report with updated information. The nature of industry
control systems will generally favour the later one, with exception
of erroneously human-generated serious incidents.
Furthermore, administrators might decide to utilize this reporting in
order to coordinate operations among different facilities, including
SCADA networks. The machine friendliness of the report favour such,
especially when automated reports are needed and when new
infrastructure arises. Utilized in an automated way, it can be a
tool to determine the health of most of the CPS infrastructure and
conveniently inform various stakeholders in an standardized and
straightforward manner. Other applications within CPS systems can
vary, including its incorporation as a mainstream communication
scheme.
4.2. CyberPhysicalReport Report XML (possible/alternative)
Representations
The IODEF Incident element ([RFC5070], Section 3.2) is summarized
below. It and the rest of the data model presented in Section
Section 5 is expressed in Unified Modeling Language (UML) syntax as
used in the IODEF specification. The UML representation is for
illustrative purposes only; elements are specified in XML as defined
in Appendix A.
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
Murillo Informational [Page 15]
RFC 6684 IODEF Extension December 2013
| | |<>--[ CyberPhysicalReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+--------------------+
(i) No re-utilization of other extensions
+---------------+
| Incident |
+---------------+
| ENUM purpose |<>---------[IncidentID]
| STRING |<>--{0..1}-[AlternativeID]
| ext-purpose |<>--{0..1}-[RelatedActivity]
| ENUM lang |<>--{0..1}-[DetectTime]
| ENUM |<>--{0..1}-[StartTime]
| restriction |<>--{0..1}-[EndTime]
| |<>---------[ReportTime]
| |<>--{0..*}-[Description]
| |<>--{1..*}-[Assessment]
| |<>--{0..*}-[Method]
| | |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[AttackPattern]
| | |<>--{0..*}-[Vulnerability]
| | |<>--{0..*}-[Weakness]
| |<>--{1..*}-[Contact]
| |<>--{0..*}-[EventData]
| | |<>--{0..*}-[ AdditionalData ]
| | | |<>--[ CyberPhysicalReport ]
| | |<>--{0..*}-[Flow]
| | | |<>--{1..*}-[System]
| | | |<>--{0..*}-[AdditionalData]
| | | |<>--{0..*}-[Platform]
| | |<>--{0..*}-[Expectation]
| | |<>--{0..1}-[Record]
| | |<>--{1..*}-[RecordData]
| | |<>--{1..*}-[RecordItem]
| | |<>--{0..*}-[EventReport]
| |<>--{0..1}-[History]
| |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[Verification]
| | |<>--{0..*}-[Remediation]
+---------------+
(ii) Utilization of IODEF-extension for structured cybersecurity information
Figure 2: The IODEF XML Incident Element - Options
A cyber-physical report is composed of one iodef:Incident element
that contains one or more related CyberPhysicalReport elements
Murillo Informational [Page 16]
RFC 6684 IODEF Extension December 2013
embedded in the iodef:AdditionalData element of iodef:EventData. The
CyberPhysicalReport element is added to the IODEF using its defined
extension procedure documented in Section 5 of [RFC5070].
One IODEF-Document may contain information on multiple incidents with
information for each incident contained within an iodef:Incident
element ([RFC5070], Section 3.12).
4.3. Syntactical Correctness of Cyber-Physical Reports
The cyber-physical report MUST pass XML validation using the schema
defined in [RFC5070] and the extensions that will be defined in
Appendix A of this document.
5. SCyberPhysicalReport Element Definitions
A CyberPhysicalReport consists of an extension to the
Incident.EventData.AdditionalData element with a dtype of "xml". The
elements of the CyberPhysicalReport will specify information about
the components of activity identified in Section Section 5.
Additional forensic information and commentary can be added by the
reporter as necessary to show relation to other events, to show the
output of an investigation, or for archival purposes. The inclusion
of already existing reporting standards is possible through an
appropriate element.
5.1. CyberPhysicalReport Structure
A CyberPhysicalReport element is structured as follows. The
components of a CyberPhysicalReport are introduced in functional
grouping, as some parameters are related and some elements may not
make sense individually.
Murillo Informational [Page 17]
RFC 6684 IODEF Extension December 2013
+------------------+
|CyberPhysicalRepor|
+------------------+
| STRING Version |<>--{0..1}--[IncidentTitle]
| ENUM IncdntType |<>--{0..1}--[ReportingParty]
| STRING ext-value |<>--{0..1}--[ReportReliability]
| |<>--{0..1}--[IncidentType]
| |<>--{0..1}--[Industry]
| |<>--{0..1}--[TargetSystems]
| |<>--{0..1}--[CyberPhysicalDepth]
| |<>--{0..1}--[TransportMedium]
| |<>--{0..1}--[Exploit]
| |<>--{0..1}--[EntryPoint]
| |<>--{1..*}--[PerpetratingParty]
| |<>--{0..*}--[DetectionMethod]
| |<>--{0..*}--[CommandAndControlCenters]
| |<>--{0..*}--[CompromisedPhysicalInfrastrucute]
| |<>--{0..*}--[ConstrolSystem]
| |<>--{0..1}--[OrganizationalImpact]
| |<>--{0..1}--[RecurrencePreventionMeasures]
| |<>--{0..1}--[BriefDescriptionOfIncident]
| |<>--{0..1}--[ProtocolType]
| |<>--{0..1}--[NetworkType]
| |<>--{0..1}--[Logs]
| |<>--{0..1}--[References]
+------------------+
Figure 3: The CyberPhysicalReport Element
5.2. Reuse of IODEF-Defined Elements
Elements, attributes, and parameters defined in the base IODEF
specification are to be used whenever possible in the definition of
the CyberPhysicalReport XML element.
5.3. Element and Attribute Specification Format
1. A terse XML-type identifier for the element or attribute.
2. An indication of whether the element or attribute is REQUIRED or
optional. Mandatory items are noted as REQUIRED. If not
specified, elements are optional. Note that when optional
elements are included, they may REQUIRE specific sub-elements.
3. A description of the element or attribute and its intended use.
Elements that contain sub-elements or enumerated values are further
Murillo Informational [Page 18]
RFC 6684 IODEF Extension December 2013
sub-sectioned. Note that there is no "trickle-up" effect in
elements. That is, the required elements of a sub-element are only
populated if the sub-element is used.
5.4. Version Attribute
REQUIRED. STRING. The version shall be the value ___, to be
compliant with this document.
5.5. IncdntType Attribute
REQUIRED. One ENUM. The IncdntType attribute describes the type of
incident activity described in this CyberPhysicalReport. The
IncidentType element indicates whether the incident is accidental, on
purpose, or the result of other actions.
5.6. The IncidentTitle element
Briefly states the nature of the incident. This is mostly to convey
understanding to humans.
5.7. The ReportingParty element
Describes the stakeholder that files the report
5.8. The ReportReliability element
Determines the degree of confidence of that the report information is
accurate
5.9. The IncidentType element
Indicates whether the incident is accidental, on purpose, or the
result of other actions
5.10. The Industry element
Determines the type of industry where the incident took/is taking
place (petroleum, automotive, etc)
5.11. The TargetSystems element
Describes the main target: network, IT systems, control systems, etc.
5.12. The CyberPhysicalDepth element
Identifies the depth and all of the levels involved in the attack:
control network, field area network, etc. See Diagram 1.
Murillo Informational [Page 19]
RFC 6684 IODEF Extension December 2013
5.13. The TransportMedium element
Identifies how the worm or other tool penetrated the facilities:
Internet, removable media, wireless, or others.
5.14. The Exploit element
Describes the characteristics of the exploit that was used for making
the attack.
5.15. The EntryPoint element
Describes the device (router, PC, etc.) through which a worm or other
threat entered the system. Note that the exploit does not necessary
reside at the EntryPoint.
5.16. The PerpetratingParty element
Identifies the originator of the attack, this being a human being,
nation state or others.
5.17. The DetectionMethod element
Describes how the detection was carried out, including the use of
tools and the existence of irregularities in any device
5.18. The CommandAndControlCenters element
Describes the remote or local systems that are in control of the
attack
5.19. The CompromisedPhysicalInfrastrucute element
Describes the elements of a physical infrastructure that was
compromised
5.20. The ConstrolSystem element
Describes the parameters that were altered in the control system
algorithm (proportional, integral, derivative, etc)
5.21. The OrganizationalImpact
Describes the economic and other aspect impact that the incident had
on the institution
Murillo Informational [Page 20]
RFC 6684 IODEF Extension December 2013
5.22. The RecurrencePreventionMeasures element
Describes the measures that must be taken for the incident not to
repeat.
5.23. The BriefDescriptionOfIncident element
Describes a human friendly description of the incident. While the
previousreporting elements should be enough to characterize an
incident, this might provide additional information.
5.24. The Logs element
Takes the raw control system input/output, supervisory and other
logs.
5.25. The References element
Provides with any resources that were used in the detection and
amelioration of the incident.
5.26. The ProtocolType element
Describes the (field) protocol type. Allen Bradley; DF1,DH and DH+;
GE Fanuc; Siemens Sinaut; Mitsubishi; Modbus RTU / ASCII; Omron;
Toshiba; Westinghouse; Other Vendor Protocols
5.27. The NetworkType element
Provides with more idea of the network. Wide area networks: Analog
point to point and multi-point modem networks, frame relay/Cell relay
type point to point and multi-point networks, wireless Radio/
Satellite networks, fibre optic based networks
6. Mandatory IODEF and CyberPhysicalReport Elements
A report Cyber-Physical System report requires certain identifying
information that is contained within the standard IODEF Incident data
structure and the CyberPhysicalReport extensions. The required
attributes are a combination of those required by the base IODEF
element and those eventually required by this document. Attributes
identified as required SHALL be populated in conforming Cyber-
Physical System reports.
In case this draft extension will eventually embed structured
cybersecurity information defined by other specifications, the
implementation of this draft MUST be capable of sending and receiving
the XML conforming to the specification listed in an initial IANA
Murillo Informational [Page 21]
RFC 6684 IODEF Extension December 2013
table without error. The receiver MUST be capable of validating
received XML documents that are embedded inside that against their
schemata. Note that the receiver can look up the namespace in an
IANA table to understand what specifications the embedded XML
documents follows.
6.1. An Example XML
To be populated
6.2. An XML Schema for the Extension
To be populated
7. Security Considerations
This document specifies a format for encoding a particular class of
security incidents appropriate for exchange across organizations. As
merely a data representation, it does not directly introduce security
issues. However, given the comprehensiveness a report might have and
the frequency of reports, third parties might be able to generate
infrastructure characteristics, dynamics, and other parameters that,
in extreme scenarios, might constitute industrial espionage. For
this reason, the underlying message format and transport protocol
used MUST ensure the appropriate degree of confidentiality,
integrity, and authenticity for the specific environment.
Organizations that exchange data using this document are URGED to
develop operating procedures that document the following areas of
concern.
7.1. Transport-Specific Concerns
The critical security concerns are that cyber-physical incident
reports may be falsified or the CyberPhysicalReport may become
corrupt during transit. In areas where transmission security or
secrecy is questionable, the application of a digital signature
and/or message encryption on each report will counteract both of
these concerns. We expect that each exchanging organization will
determine the need, and mechanism, for transport protection.
7.2. Using the iodef:restriction Attribute
In some instances, data values in particular elements may contain
data deemed sensitive by the reporter. Although there are no
general-purpose rules on when to mark certain values as "private" or
"need-to-know" via the iodef:restriction attribute, the reporter is
cautioned not to apply element-level sensitivity markings unless they
believe the receiving party (i.e., the party they are exchanging the
Murillo Informational [Page 22]
RFC 6684 IODEF Extension December 2013
event report data with) has a mechanism to adequately safeguard and
process the data as marked. Information that is considered sensitive
can be marked as such using the restriction parameter of each data
element.
8. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemata
[XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism
described in [RFC3688].
It is still to be determined whether this memo will create a registry
for IANA to manage.
9. Manageability Considerations
If any of the operational and/or management considerations listed in
Appendix A of [RFC5706] apply to this extension, they will be
addressed in this section. If no such considerations apply, this
section can be omitted.
10. Appendix A: XML Schema Definition for Extension
The XML Schema describing the elements defined in the Extension
Definition section will be given here. Each of the examples in
Section 11 will be verified to validate against this schema by
automated tools.
11. Appendix B: Examples
This section will contain example IODEF Documents illustrating the
extension. If example situations are outlined in the applicability
section, documents for those examples should be provided in the same
order as in the applicability section. Example documents will be
tested to validate against the schema given in the appendix.
12. References
12.1. Normative References
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
December 2007.
12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Murillo Informational [Page 23]
RFC 6684 IODEF Extension December 2013
[RFC3067] Arvidsson, J., Cormack, A., Demchenko, Y., and J. Meijer,
"TERENA'S Incident Object Description and Exchange Format
Requirements", RFC 3067, February 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, April 2012.
[ACS] Amin, S., Cardenas, A., and S. Sastry, "Safe and secure
networked control systems under denial-of-service
attacks", 2009.
[SFC] Stouffer, K., Falco, J., and K. Scarfonw, "Guide to
Industrial Control Systems (ICS) Security",
Organization US National Institute of Standards and
Technology, June 2011.
[RKAL] Kalapatapu, R., "SCADA protocols and communication
trends", Organization ISA, 2004.
[MMJS] Murillo, M. and J. Slipp, "Application of WINTeR
Industrial Testbed to the Analysis of Closed-Loop Control
Systems in Wireless Sensor Networks", Organization The 8th
ACM/IEEE International Conference on Information
Processing in Sensor Networks, 2009.
Author's Address
Martin Murillo
Institute of Electrical and Electronics Engineers
1400 East Angela Blvd.
South Bend, Indiana
United States
Phone: +1 613 366 6003
EMail: murillo@ieee.org
Murillo Expires: July 11, 2014 [Page 24]
