Security in the Industrial Internet of Things

The C-SEC Approach

Jose Romero-Mariona, Roger Hallman, Megan Kline, John San Miguel, Maxine Major

and Lawrence Kerr

US Department of Defense, SPAWAR Systems Center Paciﬁc, San Diego, California, U.S.A.

Keywords:

Security as a Service, Machine-to-Machine Communications, SCADA, Industrial Internet of Things.

Abstract:

A revolutionary development in machine-to-machine communications, the “Internet of Things” (IoT) is of-

ten characterized as an evolution of Supervisory Control and Data Acquisition (SCADA) networks. SCADA

networks have been used for machine-to-machine communication and controlling automated processes since

before the widespread use of the Internet. The adoption of open internet protocols within these systems has

created unforeseen security vulnerabilities. In this paper we detail the Cyber-SCADA Evaluation Capability

(C-SEC), a US Department of Defense research effort aimed at securing SCADA networks. We also demon-

strate how the C-SEC framework could enhance the security posture of the emerging IoT paradigm.

1 INTRODUCTION

The “Internet of Things” (IoT) is revolutionizing

machine-to-machine communications. Since the

1960s, machines have been communicating over di-

verse and proprietary protocols such as those em-

ployed in Industrial Control Systems (ICS) (Ecos-

teer, 2014). Supervisory Control And Data Acqui-

sition (SCADA) networks are an important subset of

ICS used to monitor and control critical infrastructure

and automated processes, often over complex net-

works (Curtis and Wolfe, 2013). SCADA networks

are implemented across industries as diverse as elec-

trical, water, oil, and gas utilities. The US Department

of Defense (DoD) depends on SCADA networks in

unique operational environments where disruption of

service cannot be tolerated.

The IoT concept is very broad, with differing

visions for what it is, and may be seen as things-

oriented or internet-oriented. A things-oriented view

of IoT focuses on smart devices, near ﬁeld communi-

cation and RFID, whereas an internet-oriented view

of IoT is focused on IP for Smart Objects and “IP

over everything” (Atzori et al., 2010). The internet-

oriented view of IoT may then be seen as as a simpliﬁ-

cation of the current IP protocols that can be adapted

to make any object addressable and reachable from

anywhere in the world (Atzori et al., 2010). Each ap-

proach to security for the IoT presents its own set of

concerns.

This paper addresses those concerns with the

Cyber-SCADA Evaluation Capability (C-SEC), a

novel approach to cyber-physical system security

that:

• Provides a DoD-centric perspective of needs to be

evaluated.

• Facilitates an independent evaluation, veriﬁca-

tion, and validation of various IA technologies.

• Deﬁnes a process that is standardized, ﬂexible,

and scalable.

• Prescribes security metrics that are granular and

usable.

• Focuses on SCADA and ICS-speciﬁc test cases

and evaluation metrics.

• Evaluates technologies of interest in a representa-

tive SCADA and ICS laboratory test environment.

• Provides an online repository to enable the com-

parison of C-SEC results and the effective reuse

of previous C-SEC evaluations.

The rest of this paper is organized as follows. Sec-

tion 2 gives a brief overview of SCADA and IoT se-

curity concerns, as well as an introduction to a US

Navy research effort out of which the idea for C-SEC

was conceived. Section 3 describes C-SEC in consid-

erable detail, describing its evaluation process, met-

rics, framework, laboratory environment, and online

colaborative environment. Section 4 surveys other ef-

Romero-Mariona, J., Hallman, R., Kline, M., Miguel, J., Major, M. and Kerr, L.

Security in the Industrial Internet of Things - The C-SEC Approach.

DOI: 10.5220/0005877904210428

In Proceedings of the International Conference on Internet of Things and Big Data (IoTBD 2016), pages 421-428

ISBN: 978-989-758-183-0

421

forts in SCADA and IoT security, with a focus on se-

curity models and test beds. Finally, concluding re-

marks are offered.

2 SCADA AND IOT SECURITY

SCADA networks are an important subset of ICS, of-

ten used to monitor and control critical infrastructure

over complex networks, that has been in use since

the 1960s. There is currently an emphasis on Cy-

ber Security for SCADA systems that suggests that

many systems had never been connected, but this is

mistaken (Ecosteer, 2014). SCADA networks are

used for monitoring and controlling machinery over

considerable distances on a continual basis (Russell,

2012). Because of their importance to critical infras-

tructure, system availability and security have been

prized above all else (Sim

oes et al., 2015). There-

fore proprietary, rather than common protocols (e.g.

ASCII) were used (Russell, 2012), though protocol

standardization has been a signiﬁcant effort of the

IEEE (Kezunovic, 2002). SCADA networks are also

notoriously fragile, with many legacy devices which

are unable to support standard security technologies

(e.g. anti-malware, network scanners, etc.) (Wilhoit,

2013).

Many of the security concerns for a things-

oriented view of IoT are not dissimilar to recent secu-

rity concerns for SCADA networks (Yu et al., 2015):

• Devices often lack timely software updates.

• Device lifespans may continue for many years af-

ter vendor support has ceased (e.g. patching).

• Vulnerable devices are deeply embedded within

networks.

• Devices will communicate explicitly with one an-

other, behaving in dynamic ways that will change

with operating context.

• Common security solutions may require more

memory and power than devices can support.

Due to the diversity of IoT devices and their re-

source limitations (Atzori et al., 2010), the above se-

curity concerns with the things-oriented approach are

not easily managed. The security concerns for an

internet-oriented view of IoT include well-known IP

related threats, including man-in-the-middle attacks,

DDoS, and reconnaissance. Therefore an internet-

oriented security posture that takes device vulnerabil-

ities into account is advised.

2.1 Ofﬁce of Naval Research - ESTEP

Military installations resemble self-contained cities

with internally supported critical infrastructures (e.g.

electrical grids, water treatment facilities, etc). These

installations rely on SCADA networks to monitor and

control this infrastructure. As external connectivity of

these networks increases, new security threats chal-

lenge SCADA network managers. Furthermore, the

DoD is increasingly integrating smart technology into

new and existing SCADA infrastructures.

Energy Systems Test and Evaluation Program

(ESTEP) is a ﬁve-year effort, funded by the US Of-

ﬁce of Naval Research (ONR), to test and evaluate en-

ergy technologies for use on Navy and Marine Corps

installations. ESTEP focuses on energy technolo-

gies that reduce costs, improve energy security, and

increase the reach of the US Armed Forces (ONR,

2012). In this paper, we highlight the Cyber-SCADA

Evaluation Capability (C-SEC), a research effort un-

der ESTEP to improve the cyber-security posture of

energy systems, starting with decision-making sup-

port for securing critical infrastructures.

3 C-SEC

C-SEC supports Cyber Security and Information As-

surance decision-making across new technologies by

enabling a streamlined, ﬂexible, and repeatable evalu-

ation process against DoD-speciﬁc needs and require-

ments. Traditional security evaluation techniques are

expensive, as they often require time and resources

beyond what projects of smaller scales can afford. In

addition, these evaluations tend to be non-repeatable

and ultimately lack usability and applicability beyond

just that one instance, thus jeopardizing their long-

term return on investment (ROI) (Romero-Mariona,

2014).

C-SEC has three main components:

• a software evaluation tool,

• a laboratory environment,

• an online collaborative environment.

The software evaluation tool walks non-SCADA

security experts through a quick, high-level evalua-

tion process for determining the highlights of speciﬁc

technologies of interest. The laboratory environment

integrates the technology of interest into a prescribed

conﬁguration, which then provides a more detailed

evaluation. Lastly, the online collaborative environ-

ment serves as a repository of past evaluations in or-

der to facilitate reuse of results. The following sec-

tions describe each of these components in detail.

IoTBD 2016 - International Conference on Internet of Things and Big Data

422

3.1 C-SEC Evaluation Tool

The C-SEC Evaluation Tool is composed of three

main parts: a process, metrics, and a framework

(Romero-Mariona, 2014). The approach provides not

only the process necessary to determine if a certain

technology meets DoD/Navy needs, but also provides

the metrics to measure how well those needs are met,

and a framework to enable the comparison of multi-

ple technologies of interest. Figure 1 below shows all

three of component parts.

Figure 1: C-SEC Evaluation Tool Parts.

3.1.1 C-SEC Evaluation Process

The C-SEC Evaluation Process is the ﬁrst major com-

ponent of the C-SEC approach. It evaluates a speciﬁc

cybersecurity technology to determine if it meets (or

not) DoD/Navy needs. The following are the major

steps of this aspect:

1. Market survey: High-level view of current offer-

ings for the particular IA technology area of in-

terest as well as a deﬁned set of tests to determine

the compatibility of those offerings with identiﬁed

needs.

2. Analysis and drill-down: Results from the market

survey are analyzed and the top percentage (varies

based on each study, interest, and needs) of tech-

nologies will move down to the next step

3. Focused testing: This step takes the technologies

identiﬁed during the analysis, and drill-down to

test them more rigorously by means of test cases

that go beyond the high-level used during step 1.

Often times a simulated test environment is built

to test the functionality of the test subjects. In ad-

dition, documentation reviews are also used to de-

termine if needs are met.

4. Focused analysis: This step evaluates the results

for each technology tested in Step 3 and apply

metrics to determine how well each need was met.

5. Gaps and recommendations: The analyzed results

are used to determine current technology gaps and

suggest recommendations for future research.

3.1.2 C-SEC Metrics

Metrics, and speciﬁcally those which are related to

non-functional aspects, are a tough problem. Tradi-

tional approaches to measuring are not well suited for

aspects like security and usability (Romero-Mariona,

2014). As a result, researchers, industry practition-

ers, and the government, lack the necessary tools to

baseline and track speciﬁc characteristics of today’s

technologies. C-SEC provides metrics support that

is applicable for security and usability characteristics,

as well as relevant to academia, industry, and govern-

ment sectors.

C-SEC provides metrics support across three dif-

ferent areas:

1. Metrics Discovery and Application: Develops

DoD-speciﬁc security metrics and applies them to

C-SEC Process results.

2. Metrics Manipulation: Enables manipulation and

results integrity.

3. Metrics Visualization: Enables metrics traceabil-

ity and decision making support.

These three areas make the C-SEC Process results us-

able. Figure 4 shows one of C-SEC’s visualizations

for metrics.

3.1.2.1 Metrics Discovery and Application

The ﬁrst, and most basic, step is to develop metrics

and determine the best way to apply them to the C-

SEC Process results. In order to provide relevant met-

rics to a variety of IA technologies, we have selected

ten different metrics areas, referred to as Capabili-

ties. These Capabilities represent the highest level of

granularity and cover aspects across two main areas,

Computer Network Defense (CND) concepts as well

as product-level. As shown in Figure 2 below, C-SEC

prescribes ﬁve types of metrics (or Capabilities) un-

der the CND area, and ﬁve types of metrics under the

product-level category.

Figure 2: C-SEC Metric Types.

The CND-level metrics refer to the basic aspects

related to security, i.e. how well does a technol-

Security in the Industrial Internet of Things - The C-SEC Approach

423

ogy support the protection, monitoring and detection,

analysis, planning, and response to threats and/or at-

tacks. These types of metrics are more associated

with aspects in which government programs are in-

terested in.

The Product-level area metrics refer to aspects

more commonly associated to “day-to-day” opera-

tions of a technology. Product-level metrics look at

aspects that range from the cost and difﬁculty of de-

ploying a speciﬁc technology, to the complexity of

maintaining that technology once it is deployed. Each

type of metric applied to the results obtained from the

application of the C-SEC Process is assigned a nu-

merical value that reﬂects how well the speciﬁc tech-

nology under evaluation meets (or not) the objectives

deﬁned for that metric.

3.1.2.2 Metrics Manipulation

Once the C-SEC Metrics have been established and

applied, C-SEC supports the manipulation of these

metrics in order to better understand the technology

under various shades of light. C-SEC employs a gran-

ular approach to metrics manipulation; this enables

ﬂexibility as well as reusability of results. For exam-

ple, suppose that Agency 1 just completed an evalu-

ation of Technology X with an emphasis on the cost,

but now Agency 2 also wants to evaluate the same

Technology X but with a different emphasis on pro-

tection capabilities. Agency 2 could reuse the same

C-SEC results that Agency 1 produced, and manipu-

late the C-SEC Metrics to put more weight into the

protection aspects of the results (and less on the cost

aspects) in order to obtain a different measurement of

technology X’s ability to meet those needs.

C-SEC Metrics prescribe two new levels in ad-

dition to the Capability-level described in section

2.3.1, which further break down each Capability into

Sub-Capabilities, and those into Sub-Capability Ele-

ments. As an example, Figure 3 below shows how

a Capability, like Protection, is composed of two

Sub-Capabilities: Vulnerability Protection and List-

ing (which refer to two possible ways to achieve pro-

tection). These are further broken into Sub-Capability

Elements, such as Vulnerability Scanning and Vulner-

ability Reporting (which refer to two possible ways to

achieve Vulnerability Protection).

This granular approach prescribes a few rules:

• Every Capability is composed of one or more Sub-

Capabilities.

• Every Sub-Capability is composed of one or more

Sub-Capability Elements.

• Sub-Capability Elements can be duplicated across

other Sub-Capabilities.

Figure 3: C-SEC Metrics Granularity.

C-SEC computes an aggregated score from var-

ious levels of granularity (Capability→Sub-

Capability→Sub-Capability Element) as well as

provides “weights” at each element to facilitate the

ﬂexibility and reuse of the C-SEC Metrics. This

granular system is what would enable Agency 2,

in our earlier example, to take the C-SEC Process

results from Agency 1 and apply different weights to

their scores in order to emphasize different aspects of

interest.

3.1.2.3 Metrics Visualization

The last aspect supported by C-SEC Metrics is visu-

alization. C-SEC Metrics provide a visualization for

the manipulation of the various scores and weights ap-

plied to the C-SEC Process results, so that users can

see in real-time the effect that changes have on the

original results. The Metrics visualization component

is mainly driven by C-SEC’s graphical user interface

(GUI) and changes made to the original results are

stored in a database. Finally, the visualization of C-

SEC Metrics also supports decision-making by em-

ploying Bayesian-Network models in order to provide

probabilities as well as (ROI) information.

Figure 4: C-SEC Metric Types.

3.1.3 C-SEC Framework

The last piece of C-SEC is the Framework. This piece

provides the format necessary to compare and con-

IoTBD 2016 - International Conference on Internet of Things and Big Data

424

trast multiple technologies of a speciﬁc cybersecu-

rity area. Furthermore, the framework also supports

a repository of past and present evaluation results in

order to facilitate reuse.

The C-SEC Framework serves as the key compo-

nent of the online collaborative environment (to be

discussed in Sec. 3.3), through which various users

can share results and reuse information. While C-

SEC applications are individually installed by users

(clients), the Framework serves as the hub (server)

that connects them together.

3.2 C-SEC Laboratory Environment

In order to further and in more detail evaluate the var-

ious security technologies of interest, we have estab-

lished a SCADA laboratory environment. The C-SEC

Laboratory Environment consists of several SCADA

demonstration kits from various vendors, which are

easily reconﬁgurable to simulate different environ-

ments. Using this setup, the Technology Under Eval-

uation (TUE) is integrated for a much more detailed

evaluation beyond just the C-SEC software tool. Lab-

oratory assets include:

• SCADA and ICS components including, but not

limited to: programmable logic control units

(PLCs) (Zhu and Sastry, 2010), networking equip-

ment, valves, actuators, motors, and various other

components, which create a realistic industrial en-

vironment. These components are representative

of what is offered by the major SCADA and ICS

suppliers.

• A DoD-mandated vulnerability scanner.

• Vulnerability visualization tool, Combinatorial

Analysis Utilizing Logical Dependencies Resid-

ing on Networks (CAULDRON).

• A suite of internally developed, custom security

test scripts to exercise the equipment beyond nor-

mal operation parameters.

CAULDRON, developed by George Mason Univer-

sity, is a network vulnerability visualization tool that

takes vulnerability scan results in .xml format, parses

them, and outputs a weighted network diagram (Ja-

jodia et al., 2011). The nodes represent the IP ad-

dresses within the network and the edges show po-

tential for information exchange. Each edge has an

associated weight that represents the number of vul-

nerabilities between connected nodes and shows how

they propagate throughout the network. This tool was

designed to enable network modeling; a user could vi-

sualize their existing network, then model how a se-

curity product would change the state of the network

based on placement. A set of scripts was developed to

automate a number of well-known approaches to net-

work penetration. These scripts are deployed on the

SCADA network to test the effectiveness of security

products.

The C-SEC process for testing the effectiveness of

security technologies is as follows:

1. Perform a vulnerability scan to baseline SCADA

equipment.

2. Install and conﬁgure security TUE.

3. Allow equipment to run for several weeks to gen-

erate data.

4. Re-scan SCADA equipment.

5. Visualize scan results on Cauldron.

6. Compare new and baseline results to determine

effectiveness of security TUE.

7. Initiate scripted tests on network to validate scan

results.

This process can be seen in Figure 5.

3.3 C-SEC Online Collaborative

Environment

The C-SEC Online Collaborative environment con-

sists of a web application providing users with an in-

terface to create, search, and reuse standardized eval-

uations of security technologies that are speciﬁcally

marketed for SCADA networks. This online collab-

orative environment was created to standardize what

is currently a disparate process for evaluating security

technologies and apply a set of weights that is rep-

resentative of user needs. Users have the option to

perform new evaluations or choose previously com-

pleted evaluations. Allowing users to choose existing

evaluations enables them to make informed decisions

about which technology (or suite of technologies) to

implement on their networks.

The online environment is designed for easy de-

ployment to both enterprise and tactical networks. To

achieve this, C-SEC deploys virtual machines (VM)

which are lightweight and have the ability to be hosted

on almost any network.

The C-SEC web server sits on top of a 64-bit

Linux-based platform (http://linuxmint.com/).

Using a lightweight Linux distribution enables

C-SEC to have a smaller footprint. NGiNX

(https://www.nginx.com/) is the preferred web

server to host C-SEC as it is a lightweight solution and

memory-efﬁcient, which is key when being hosted on

a network with limited resources (e.g. tactical net-

works). NGiNX is able to handle modern concur-

rency issues on websites with numerous connections.

Security in the Industrial Internet of Things - The C-SEC Approach

425

Figure 5: C-SEC Laboratory Environment.

uWSGI complements NGiNX by handling dynamic

content.

The C-SEC website uses the Django framework

because it provides required functionalities of a web

framework, such as ease of use, scalability, and speed.

Websites developed on Django use Python as the

primary programming language, as well as HTML

(https://www.djangoproject.com/). Django also

allows for the incorporation of additional APIs, such

as Highcharts (http://www.highcharts.com/).

Separating the database server from the web-

server is an operational decision because run-

ning both services on a single machine is re-

source intensive. Turnkey Linux is a community

that takes many of the top open-source applica-

tions and creates an easily deployable server with

a minimum amount of components to fully oper-

ate securely (https://www.turnkeylinux.org/).

The C-SEC database server is a Turnkey distribu-

tion built speciﬁcally host a PostgreSQL database

(http://www.postgresql.org). The database for

C-SEC’s online collaborative environment has tran-

sitioned through a couple of different database itera-

tions, ﬁnally settling upon PostgreSQL. PostgreSQL

is one of the most feature-rich open source relational

databases available.

An overarching goal for C-SEC is the develop-

ment of a repository of evaluations for reuse as a cost-

saving feature. When a user wants to reuse an ex-

isting evaluation, they have two options. First, they

can take another user’s evaluation at face value; they

are satisﬁed with the answers provided by the other

user and accept the score as is. Alternatively, they can

reuse existing evaluations while overlaying a set of

weights based on individual needs using the built in

wizard to establish their preferences. Weights based

on individual prioritizations are overlayed onto the

existing evaluation data. The user also sees a visu-

alization consisting of a bar graph of existing scores

over each of the Capabilities and an overlay “wave”

of their weighted preferences.

Figure 6: C-SEC “wave” overlay comparing user priorities

with existing evaluations.

This allows users to directly compare their pri-

orities to what the technology provides according to

the existing evaluation, shown in Figure 6. (Hallman

et al., 2014)

IoTBD 2016 - International Conference on Internet of Things and Big Data

426

4 RELATED WORK

Much of the research into securing networks of

IoT devices, particularly in the domain of ICS and

SCADA, focuses on how to apply what we know

about common devices and protocols to the IoT do-

main (Jing et al., 2014).

Yu discusses vulnerabilities introduced by collab-

orative implementations of IoT devices. Due to the

vast diversity and computational simplicity of IoT de-

vices, coupled with proliﬁc unpatched vulnerabilities,

a network-based solution, rather than a host-based so-

lution, is the key to IoT security. The proposition is

that of a software-based solution which dynamically

adapts network security to a changing operational en-

vironment (Yu et al., 2015).

A simple IF-This-Then-That (IFTTT) rule com-

monly implemented in IoT tends to ignore the com-

plexity of device interactions, and thus the security

interpretation of a combination of known states. Yu,

et.al acknowledge that threat signatures need to be

collected in order to make intelligent security deci-

sions, and so policy extraction must be implemented

as a separate utility from ﬁrewalls and other IoT man-

agement protocols. The authors propose a brute force

method of establishing all devices and possible de-

vice states, then deriving the environmental context

and security posture from combinations of these states

(Yu et al., 2015).

In order to build an attack signature library,

the authors propose anonymous, incentivized crowd

sourced signature collection of individual devices. To

handle multiple device interactions, the authors pro-

pose a library built from the abstractions of classes of

devices, with a particular focus on the key behaviors

and environmental interactions (e.g. I/O) with other

devices. Device interactions within this library of ab-

stractions are ﬁngerprinted by fuzzing the behavior

space, and building a model for multi-stage attacks

through graph analysis (Yu et al., 2015).

To properly utilize Software Deﬁned Networking

(SDN) to control of a network of IoT devices, the

authors propose a hierarchical control structure with

logical partitioning of devices based on only essential

device interactions (Yu et al., 2015). In order to im-

plement Network Functionality Virtualization (NFV)

of essential devices, the authors propose a concept

called micro-middleboxes (µmboxes) implemented as

lightweight, rapidly conﬁgurable VMs running the

lightweight Click OS. These µmboxes could be de-

ployed and reconﬁgured to adapt to the changing se-

curity needs of their respective domains within the

system (Yu et al., 2015).

4.1 Security Models

Axelrod discusses the observation that even though a

number of studies cite the need to secure the IoT and

which entities need to be secured, little is mentioned

as to how to secure the IoT (Axelrod, 2015). Secu-

rity takes a back seat to other concerns due to many

cultural and economic factors, leading to the develop-

ment of a security model based on various incentives

and penalties to encourage vendors to build security

into their offerings.

NIST SP800-82 R2 (Drias et al., 2015) and

ISA/IEC 62443 (Stackowiak et al., 2015) standards

have been developed to provide guidance to securing

industrial systems, and are a ﬁrst step in applying IT

security designs, such as network segmentation and

other fundamental security concepts, to complex in-

dustrial infrastructures. New security devices, which

do not translate well to IT security, are being devel-

oped for IoT systems, such as one-way data commu-

nication diodes, “remote access devices, and protocol

translating gateways” speciﬁcally for industrial pro-

tocols. A well-developed architecture with network

segmentation and appropriate network gateway ap-

pliances allow monitoring of ICS processes without

interfering with the time-sensitive nature of system

availability (Meltzer, 2015).

Jing, et al. (Jing et al., 2014) break down the

IoT domain into several layers of systems types, each

of which can apply security solutions directly to the

sub-types within each system. The top three layers

of Jing’s security architecture are Perception, Trans-

portation, and Application. The Perception layer is

concerned with information communication and col-

lection both in the nodes and the network, which

would be protected by RFID, WSN, and RSN secu-

rity solutions (to name a few). The Transportation

layer involves access to the network, including core

utilities and the LAN itself. The Application layer

supports IoT applications, and security at this level

would be targeted directly at weaknesses in IoT ap-

plications themselves (Jing et al., 2014).

Security solutions identiﬁed within Jing’s archi-

tecture address the technology itself, as well as de-

vices which interact with that technology. For exam-

ple, RFID technology security can be greatly affected

by the devices that use it. Some security solutions in-

clude uniform coding, conﬂict resolution, trust man-

agement, and cryptographic algorithms, all of which

need to be supported by devices which collect and in-

terpret RFID data. Goals for these security implemen-

tations directly include maximizing information secu-

rity during exchange, and limiting interference in the

process (Jing et al., 2014).

Security in the Industrial Internet of Things - The C-SEC Approach

427

5 CONCLUSIONS

In this paper we presented C-SEC, a tool to support

cybersecurity decision making across new technolo-

gies by enabling streamlined, ﬂexible, and repeatable

evaluations. C-SEC has three components, a soft-

ware evaluation tool a laboratory environment, and an

online collaborative environment, and is designed to

assist non-SCADA security personnel in addressing

vulnerabilities in their networks. The C-SEC soft-

ware Laboratory environment provides opportunities

for testing security products on controlled SCADA

networks as well as modeling how they will affect net-

work vulnerabilities. We have also developed metrics

for scoring security product capabilities, as well as al-

gorithms for matching users to suites of products that

address their individual needs.

Many of the security vulnerabilities that charac-

terize SCADA networks are common to the IoT. The

diversity of IoT devices, their resource limitations,

and lifespans that will outlast vendor support mean

that security technology cannot be broadly applied to

smart devices. An internet-oriented approach to IoT

security that takes devices into account is the only fea-

sible strategy for addressing security concerns. C-

SEC focuses on improving the cyber-security pos-

ture of SCADA networks that have long been used

in machine-to-machine communication, and given the

inherent difﬁculties of building secure smart devices,

C-SEC is an ideal technology to integrate up-to-date

security into the IoT.

REFERENCES

Atzori, L., Iera, A., and Morabito, G. (2010). The internet of

things: A survey. Comput. Netw., 54(15):2787–2805.

Axelrod, C. W. (2015). Enforcing security, safety and pri-

vacy for the internet of things. In Systems, Applica-

tions and Technology Conference (LISAT), 2015 IEEE

Long Island, pages 1–6. IEEE.

Curtis, S. and Wolfe, A. W. (2013). Energy-focused fusion

information system integration, a nise funded capabil-

ity investment project. year 1 fy 2013 report. Techni-

cal report, DTIC Document.

Drias, Z., Serhrouchni, A., and Vogel, O. (2015). Taxonomy

of attacks on industrial control protocols. In Proto-

col Engineering (ICPE) and International Conference

on New Technologies of Distributed Systems (NTDS),

2015 International Conference on, pages 1–6. IEEE.

Ecosteer (2014). Open scada and the internet of things.

Technical report.

Hallman, R., Romero-Mariona, J., Kline, M., and

San Miguel, J. (2014). Ditec user priority designation

(upd) algorithm: An approach to prioritizing technol-

ogy evaluations. Technical report, DTIC Document.

Jajodia, S., Noel, S., Kalapa, P., Albanese, M., and

Williams, J. (2011). Cauldron mission-centric cyber

situational awareness with defense in depth. In MIL-

ITARY COMMUNICATIONS CONFERENCE, 2011 -

MILCOM 2011, pages 1339–1344.

Jing, Q., Vasilakos, A. V., Wan, J., Lu, J., and Qiu, D.

(2014). Security of the internet of things: perspectives

and challenges. Wireless Networks, 20(8):2481–2501.

Kezunovic, M. (2002). Future trends in protective relay-

ing, substation automation, testing and related stan-

dardization. In Transmission and Distribution Con-

ference and Exhibition 2002: Asia Paciﬁc. IEEE/PES,

volume 1, pages 598–602 vol.1.

Meltzer, D. (2015). Securing the industrial internet of

things. Technical report, Information Systems Secu-

rity Association.

ONR (2012). Energize: Onr supports new energy partner-

ship. Technical report.

Romero-Mariona, J. (2014). Ditec (dod-centric and inde-

pendent technology evaluation capability): A process

for testing security. In Software Testing, Veriﬁcation

and Validation Workshops (ICSTW), 2014 IEEE Sev-

enth International Conference on, pages 24–25.

Russell, J. (2012). Scada history. Technical report,

http://scadahistory.com.

Sim

oes, P., Cruz, T., Proenc¸a, J., and Montiero, E. (2015).

Specialized honeypots for scada systems. In Cyberse-

curity: Analytics, Technology and Automation.

Stackowiak, R., Licht, A., Mantha, V., and Nagode, L.

(2015). Internet of things standards. In Big Data and

the Internet of Things, pages 185–190. Springer.

Wilhoit, K. (2013). Who’s really attacking your ics equip-

ment? Trend Micro.

Yu, T., Sekar, V., Seshan, S., Agarwal, Y., and Xu, C.

(2015). Handling a trillion (unﬁxable) ﬂaws on a

billion devices: Rethinking network security for the

internet-of-things. In Proceedings of the 14th ACM

Workshop on Hot Topics in Networks, HotNets-XIV,

pages 5:1–5:7, New York, NY, USA. ACM.

Zhu, B. and Sastry, S. (2010). Scada-speciﬁc intrusion de-

tection/prevention systems: a survey and taxonomy.

In Proc. of the 1st Workshop on Secure Control Sys-

tems (SCS).

IoTBD 2016 - International Conference on Internet of Things and Big Data

428