2. Abstract
The rise in awareness of, and concern for, the security of industrial control systems has
coincided with the publication of standards from private sector organizations, and free guidance
documents via government sources. As automation departments have managed to navigate the IT
skills gap over the past few years, the question arises as to whether the emerging information, now
readily available, will allow for a likewise segregated security approach. However, an analysis of
the guidance reveals that not only do none of the publications stand on their own, their
implementation requires extensive inter-departmental knowledge sharing and cooperation.
Keywords
Industrial Automation and Control Systems, Security Standards, Cross-functional
Teams
1 Introduction
A maintenance department, charged with the care of industrial automation
and control systems (IACS), requires technicians capable of maintaining and
repairing the information technology (IT) that is integral to the systems’ operation
and control, including:
Computer systems used to run operator interface applications, as well as
programming applications for programmable logic controllers (PLCs) and
intelligent motor drives.
TCP/IP/Ethernet interconnection networks for communications and control
between the control system and operator PCs.
Data interconnections between the control system and the business
network.
That systems to ensure the integrity and security of these IT systems are lacking,
speaks to the fact that even though the technology and equipment have fully
moved into automation departments, the methods that have ensured their
longevity and success elsewhere have not. A quick survey of the IT systems in
question, consisting at times largely of legacy systems installed by OEMs, reveals
their weaknesses to the trained eye. Examples are the vulnerabilities associated
2
3. with common-off-the-shelf (COTS) PCs used as operator interfaces before the
realities of the modern malware era:
non-existent user access policies
internet/remote network access on the plant floor
non-existent or automatic update policies
Yet, more telling may be the failures of procedures and practices of the
department itself:
well-meaning, unsuccessful update efforts
inadvertent infection of field laptops via careless internet usage.
These deficiencies were pointed out in previous research, where the author cited
the need for either further integration of information technology coursework into
the curricula for automation technicians, or integration of the technicians/
departments themselves. This was presented as a means of addressing the
knowledge and skills gap associated with emerging training needs brought about
by the proliferation of information technology in automation [1].
While the realization of widespread improvements in organizational
structures or technical school curricula remains to be seen, high-profile security
concerns about infrastructure utilizing automation and control systems, has
brought the issue to forefront [2].
With the publication of standards and reports over the past few years,
alongside rising concerns about the security of industrial controls, this research
seeks to investigate whether the emerging avenues of discovery and guidance
provide a ready solution addressable by maintenance departments (with the
existing aforementioned challenges), or one that further justifies the integration of
IT and automation.
1.1 Audience
The author’s experience is in discrete manufacturing sectors, not
necessarily constrained by regulations to develop and implement cyber security
programs. The consequences of failures in these plants do not rise to the levels
associated with critical infrastructure, nor will they suffer the associated
regulatory penalties if they are found lacking in policy or procedures. Likewise,
the safety concerns associated with cyber security are mitigated due to the use of
3
4. traditional electro-mechanical safety circuits, separate from the software-
controlled portions of the equipment.
The drive for connectivity with other networks is for production
information that is closer to real time and automated in its timeliness and
formulation. This is the first step in an interconnectivity that can scale to
enterprise and partner levels, in what Dzung et al. point out is a response to the
need for ―fast and cost effective decisions‖…[based on] ―accurate and up-to-date
information about the plant and process status..[18].‖
The impetus for investigation into the use of IT security standards or
guidance may be due to the increased awareness of the vulnerabilities of the IT
systems involved, or due to an inordinate amount of downtime suffered due to a
failure associated with the previously enumerated deficiencies.
The inclination to attempt to create a stand-alone program, utilizing readily
available documents, is in no way mitigated by the fact that structures pre-exist in
the maintenance department that can readily incorporate new requirements for
reliability of equipment and systems. Preventative Maintenance checks on
equipment and systems whose failures threaten profitability, as well as personal
and equipment safety are continuously performed. Maintenance is likewise, by
nature, indirectly related to profitable functions within the organization.
Therefore, the aforementioned inclination towards quick, self-reliability is equally
related to cost conscientiousness.
Though a quick integration of IT security procedures and checks into the
department is an attractive proposal, it will be seen that the methodologies
presented by the guidance under consideration is extremely cross functional in its
prescription, as well as detailed and time consuming.
2 Guidance
Along with the reports of contemporary security incidents and
vulnerabilities, standards and reports aimed specifically at IACS security can be
found via simple searches for the same. In the United States, one will find
standards available from the International Society for Automation (ISA),
alongside government-sponsored publications from the Department of
Commerce’s National Institute of Standards and Technology (NIST), and the
Department of Homeland Security (DHS) [3-5]. Likewise the leading automation
4
5. vendors in Europe and North America, Siemens [6] and Rockwell [7], reference
the preceding sources.
As these sources formed the core of search results, are not specific to a
certain sector, and are largely available online, they formed the basis for the
research at hand.
2.1 ISA
With members from diverse corporate, government and academic entities
(including Rockwell, Siemens and NIST), the ISA 99 committee’s latest
publication, is ANSI/ISA-99.02.01-2009, Security for Industrial Automation and
Control Systems: Establishing an Industrial Automation and Control Systems
Security Program [3], henceforth referred to as ISA 99-2009. In his overview of
the International Electrotechnical Commission (IEC) approach to industrial
security, Naedele points out that ISA standards ―are also used as best practices
internationally [19]‖. In fact, the ISA 99 family of standards is being used as the
basis for the IEC’s 62443 series with the same title [3].
Referencing ISO 17799 (now 27002, a popular IT security standard) [8]
extensively, and at times roughly follows its outline. ISA 99-2009 is divided into
four clauses and two annexes. The informative portion of the standard, and by far
the largest, is Annex A, which provides guidance for developing the elements of a
cyber security management system (CSMS) [3].
ISA 99-2009 is actually the third in a series that is continuing. The two
previous documents are:
ANSI/ISA-99.00.01-2007, Terminology, Concepts, and Models (part one
of the series).
ANSI/ISA-TR99.00.01-2007, Security Technologies for Industrial
Automation and Control Systems (a technical report). [3]
The three ISA 99 publications are each available for purchase and are all made
available online, for viewing only, to members. [9]
2.2 NIST
Special Publication (SP) 800-82, Guide to Industrial Control Systems
Security, published in June 2011, is available free via download from NIST. The
document is divided into six sections:
5
6. Introduction
Overview of Industrial Control Systems
ICS Characteristics, Threats and Vulnerabilities
ICS Security Program Development and Deployment
Network Architecture
ICS Security Controls [4]
In addition, there are six appendices, including Appendix C, Current Activities in
Industrial Control System Security, which contains an extensive list of
organizations, references, standards, etc., involved in industrial control systems
security [4].
2.3 DHS
Another recent free publication, from the United States Department of
Homeland Security (DHS) Control Systems Security Program (CSSP), is the May
2011 report, Common Cybersecurity Vulnerabilities in Industrial Control
Systems. The report is broken into four parts:
Introduction
Vulnerability Information Sources
Understanding Common Industrial Control System (ICS) Vulnerabilities
ICS Security Recommendations [5]
The report draws from the experiences of the DHS CSSP [12], which
performs assessments of ICS, and from self-assessments via their free software
tool, Cyber Security Evaluation Tool (CSET) [5].
The reports on vulnerabilities are divided between assessments of ICS
software and systems. Likewise, the recommendations are divided among
vendors and ICS system owners [5].
3 Implementation
While one might be inclined to attempt to utilize the preceding publicly
available documents as standards for developing an industrial cyber security
program, the only one presented as such is ISA 99-2009. NIST SP 800-82 is
described as a guidance document, and the DHS publication as a report. While a
complete standard, it becomes apparent as one works through ISA 99-2009, that it
is not meant to serve as an exhaustive guide. However, free resources can serve
6
7. functions well where needed—or where the ISA document may fall short.
Likewise, references are made between the publications [3-5].
What is likewise evident is that the recommendations given are meant for
an inter-disciplinary/inter-departmental approach within the target organizations.
While the aforementioned IT knowledge/skills gap in automation is possibly
being addressed by technicians seeking further education/certification
opportunities, or engineers graduating from modern programs where
computer/digital communications knowledge is inseparable from electrical
engineering, the proliferation of IT security guidance aimed at industry has not
produced methods by which automation departments can fix their security issues
by themselves.
3.1 Guidance interaction
Both SP 800-82 and ISA 99-2009 begin the process of implementing a
cyber security program with the development of a compelling business case for
doing so. ISA 99-2009 documents were used as a reference for development of
the corresponding section in SP 800-82, as well as other sections. However, the
NIST document has the added clarity of referring to its own section three, ICS
Characteristics, Threats and Vulnerabilities, when discussing detailed sources of
threats and vulnerabilities to be used in the business case. [3,4] If the sources
listed at the end of the ISA-2009 section are meant to provide further details of the
same, they appear to be no longer available or at least not readily retrievable [10].
Following the section on developing a business rationale, SP 800-82 gives a brief
overview of the remaining elements in system development and refers to ISA 99-
2009 for details. ISA 99-2009 continues the process by requiring both a high-level
and detailed risk assessment [3,4].
Issues noted in the business rationale drive the high-level risk assessment.
Though no specific methodology is prescribed, a general description of the
components desired is given. Unfortunately, the tool referenced for choosing a
methodology, is one of the aforementioned elusive documents. However, a freely
available NIST document on risk assessment, SP 800-30, is listed in the
references at the end of the section [3]. The general descriptions/recommendations
for risk assessment steps given in the ISA standard tend to resemble the NIST
document as well [3, 11].
7
8. The previously mentioned section on threats and vulnerabilities in NIST
SP 800-82, and the system vulnerabilities portion of the DHS publication can be
utilized for the enumeration of threats and vulnerabilities during the risk
assessments required by ISA 99-2009 [4,5]. Likewise, the free DHS CSET
software tool includes a drag-and-drop drawing program specifically tailored for
control systems that can be used to generate the simple network diagrams called
for in the detailed risk assessment [3, 12].
The output from the detailed assessment is used to assign ratings to
devices within systems, and subsequently to assign target security levels for zones
containing the equipment/systems. The zones need to be added to the diagrams
produced earlier. The DHS CSET drawing tool has this capability available as
well [3,12].
Various NIST publications are referenced throughout the remainder of ISA
99-2009, from business continuity planning and incident response planning, to
conformance reviews [3].
3.2 Departmental interaction
SP 800-82 calls for controls system security programs that are ―consistent
with and integrated with existing IT security experience, programs, and practices,
but…tailored to the specific requirements and characteristics of industrial control
systems technologies and environments [4]‖. It further states that ―while control
engineers will play a large role in securing the [control system], they will not be
able to do so without collaboration and support from both the IT department and
management [4]‖. ISA 99-2009 states, when addressing the cross-functional team
that will put the program into action once management has approved the
endeavor, that the ―goal is to develop a cost-effective cyber security management
system that...will...leverage existing business processes and organizations rather
than create a whole new organization [3]‖. This team is called upon as well in the
steps for organizing for the security program and defining the scope of the same.
The subsequent training and education, business continuity planning, and policy
generation sections likewise prescribe the utilization of existing organizational
frameworks [3].
This overriding theme, though far from the do-it-yourself direction that
controls personnel may initially approach this endeavor from, will become a
8
9. welcome one as the scope, depth, and apparent complexity, of some of the
elements become evident. It is easy to see where having someone familiar with
risk assessment available to help identify the general point in the process where
the high-level assessment ends and the detailed begins would be of no small
consequence. Likewise, Dzung et al. point out that a system not grounded in
policy and based upon appropriate, local assessments is probably fraught with
―effort…wasted on securing system aspects that do not need protection from the
business point of view [18].‖
Fortunately, the guidance given is an across-the-board utilization of
existing resources and structures, that if absent in an organization, may make
concerns about cyber security for IACS moot. Holstein and Stouffer see the ISA
99 committee’s approach to the standard as a ―bold‖ endeavor. ―Rather than
develop a stove-pipe framework for Industrial Automation Control Systems, they
built the framework as an extension of the enterprise Information Security (IS)
security policy and procedures [17]‖.
If an approach is taken to attack the issue piecemeal, the aforementioned
dearth of IT knowledge and skills makes the endeavor questionable. Along these
lines is the recurring subject of network segmentation, found in DHS, NIST and
ISA documents alike. [3-5] In the risk management portion of ISA 99-2009,
reference is made to the zone and conduit models of network segmentation
outlined in the 2007 ISA 99 technical report. The prescription is for barrier
devices, such as firewalls, routers, or layer-three switches to act as restrictive
conduits between zones [3].
The ISA 99-2009 demands for segmentation run from a firewall to manage
communication between the control zone and the business zone, for medium to
high-level risk systems, to the use of a demilitarized zone (DMZ) to reduce or
eliminate communications directly between the zones for high-level risk systems
[3]. SP 800-82 ties the progression from firewall to DMZ to the increasing relative
overall effectiveness of the solutions [4].
Answers to the issue of skills, needed to implement these barriers
effectively, range from automation vendors who have partnered with traditional
IT equipment vendors (therefore providing a familiar equipment platform for IT
personnel to assist with) [13], to third party vendors offering barrier devices
aimed at being programmable by controls personnel [14]. Both of these solutions
9
10. claim to satisfy the ISA zone and conduit model [15, 16]. Yet any independence
offered by the latter solution is tempered by the ISA 99-2009 requirement that a
risk assessment be conducted to define the zones beforehand [3], bringing the
focus back to the tasks that will likely require the most inter-disciplinary resources
and cooperation regardless.
4 Conclusions
The proliferation of policies and guidance, aimed at IACS security, have
not created a situation in which IACS security issues can be fixed by IACS
personnel alone, nor can they be fixed without them. Implementing a standards-
based, comprehensive controls security program, at its core, requires the
acquisition of new knowledge by controls personnel, obtained from different
guidance sources. Yet, much of the knowledge gained, is in the form of
guidelines, that others in the organization will be needed to assist in executing.
Though the IT and security issues between departments may be largely
common, the environment, priorities, and attached equipment are not. The
security/policy/IT knowledge that the IT department brings to the equation will be
as indispensable as the automation/equipment knowledge brought by automation.
5 Afterword
The preceding discussion began with an enumeration of a few of the issues
readily obvious to departments, engaged in the maintenance of IACS, which
would illuminate the need for IT security policy for the same. While the thrust of
this paper has been an investigation of the means by which emerging standards
can be employed in IACS security, it is instructive to list the portions of ISA 99-
2009 that would actually address the aforementioned issues.
As previously stated, the standard is divided into three main categories:
Risk analysis
Addressing risk with the CSMS
Monitoring and improving the CSMS
The issues cited before are all addressed, as would be expected, in the second
category. The category is likewise divided into three groups of elements:
1. Security policy, organization, and awareness
10
11. 2. Selected security countermeasures
3. Implementation [3]
5.4 Policy
The issue of the lack of usage policy is addressed in the first element
group, by the element, Security Policy and Procedures. As the thrust is largely one
of utilizing existing IT policy frameworks [3], the same policies can easily be
applied to the IT equipment in the automation department. This is an area where
the next issue, user access, as well as the tenet of least privilege, likewise comes
into play.
5.1 User Access
The issue of poor or non-existent planning for user access frame works is
addressed in the second element group, Selected Security Countermeasures. Three
of the seven elements in the group are concerned with access control:
Account administration
Authentication
Authorization [3]
The issues of operators, maintenance and administrators, requiring different levels
of access, is of course easily addressed by the element of Account administration
policies. One of the aspects probably not considered by most automation
departments, yet addressed in this section, is that of the administration of accounts
with regard to departing automation personnel.
5.2 Network segmentation
Internet/remote network access at the plant floor is also an element of the
selected countermeasures group. It is addressed by the element of Network
Segmentation. The principle of least privilege drives the communications allowed
between zones via the conduits [3].
5.3 Patch Management
The issue of poorly executed or non-existent patch application is covered
in the third element group of Implementation by the Risk management and
11
12. implementation element [3]. The determination to patch or not is determined by a
combination of the consideration of the security level needs of the
equipment/zone and vendor testing and approval of the patches [3].
12
13. References
1. Johnny L. Welch.: Information technology curriculum and practical opportunities in
automation. In Proceedings of the 2010 ACM conference on Information technology
education(SIGITE '10). ACM, New York, NY, USA, 85-88. DOI=10.1145/1867651.1867674
2. CNBC.com.: CNBC Presents ―Code Wars: America’s Cyber Threat‖.
http://www.cnbc.com/id/43008973/CNBC_PRESENTS_CODE_WARS_AMERICA_S_CYB
ER_THREAT. (2011). Accessed 13 July 2011.
3. International Society for Automation.: ANSI/ISA-99.02.01-2009 Security for Industrial
Automation and Control Systems: Establishing an Industrial Automation and Control Systems
Security Program. ISA, Research Triangle (2009).
4. U.S. Department of Commerce, National Institute of Standards and Technology.: Special
Publication 800-82 Guide to Industrial Control Systems (ICS) Security. NIST, Gaithersburg
(2011).
5. U.S. Department of Homeland Security (DHS), National Cyber Security Division, Control
Systems Security Program.: Common Cybersecurity Vulnerabilities in Industrial Control
Systems. U.S. DHS (2011).
6. Siemens. Process Automation Security. http://www.sea.siemens.com/us/Products/Process-
Automation/safetyandsecurity/industrialsecurity/Pages/Process-Automation-
SafetyandSecurity_Security.aspx. (n.d.). Accessed 5 July 2011.
7. Rockwell Automation:. Security Solutions.
http://www.rockwellautomation.com/solutions/security/. (n.d.) Accessed 5 July 2011.
8. Whitman, M.E., Matford, H.J.: Management of Information Security, Third Edition. Course
Technology, Boston (2010). p. 225.
9. International Society for Automation: Standards ISA.
http://www.isa.org/Template.cfm?Section=Standards2&Template=/customsource/isa/Standar
ds/AutomationStandards.cfm#accessing. (n.d.) Accessed 12 July 2011.
10. American Chemistry Council, Chemical Information Technology Center: CHEMITC.
http://chemitc.americanchemistry.com/. (n.d.) Accessed 11 July 2011.
11. U.S. Department of Commerce, National Institute of Standards and Technology.: Special
Publication 800-30, Risk Management Guide for Information Technology Systems. NIST,
Gaithersburg (2011).
12. U.S. Department of Homeland Security (DHS), National Cyber Security Division, Control
Systems Security Program.: CSET3_Assessment_Fact_Sheet. http://www.us-
cert.gov/control_systems/pdf/CSET3_Assessment_Fact_Sheet.pdf. (n.d.) Accessed 29 June
2011.
13. Cisco.com: cisco-rockwell_automation.
http://www.cisco.com/web/strategy/manufacturing/cisco-rockwell_automation.html. (n.d.)
Accessed 7 July 2011.
14. Tofino Security: Security for SCADA, and industrial automation control systems.
http://www.tofinosecurity.com /. (n.d.) Accessed 26 June 2011.
13
14. 15. Cisco.: Converged Plantwide Ethernet (CPwE) Design and Implementation Guide.
http://www.cisco.com/en/US/docs/solutions/Verticals/CPwE/CPwE_DIG.pdfCPwE_DIG.pdf
(2011). Accessed 14 June 2011.
16. Tofino Security:ansi-isa-99.http://www.tofinosecurity.com/why/ansi-isa-99 (n.d.) Accessed
12 July 2011.
17. Holstein, D., Stouffer, K.: Trust but Verify Critical Infrastructure Cyber Security Solutions. In
Proceedings of the 43rd Hawaii International Conference on System Sciences. (2010).
18. Dzung, D., Naedele, M., Von Hoff, T., Crevatin, M.: Security for Industrial Automation
Systems. In Proceedings of the IEE, Vol. 93, No. 6, June 2005.
19. Naedele, M.: Standardizing Industrial IT Security – A First Look at the IEC Approach. In 10th
IEE Conference on Emerging Technologies and Factory Automation. (2005).
14