1. ISA99 - Industrial Automation and Controls Systems Security
Welcome.
Committee Summary and Activity Update
August 2015
August 2015
Copyright © ISA

2. Purpose
Introduce the ISA99 committee and the ISA series of standards on Industrial Automation and Control Systems Security.
The purpose of this presentation is to provide a general introduction to the ISA99 committee on industrial automation and control system security and its work products.
The intent is not to go into a great deal of detail, but merely to provide enough information to allow the reader to understand the scope and status of the committee’s efforts.
A secondary and perhaps more selfish purpose is to elicit your questions and comments, as members of the ISA99 stakeholders community.
August 2015
Copyright © ISA

3. What are our work products? Where do things stand?
Topics
Who are we?
How do we work?
What are the basics?
What are our work products?
Where do things stand?
This presentation addresses several specific topics.
We will begin with a short description of the committee, its scope its purpose, including how this purpose fits within the larger context of all ISA standards and practices.
From there we will move on to describe a little bit of how the committee is organized and managed. Each of the above items will be kept short, on the assumption that most people are less interested in the details of how standards are developed than their content and how it may be applied.
With the third topic we begin to discuss the content of the committee work products. This begins with a summary of the basic concepts that form the foundation of this content. His is followed by a description of how we have structured and organized a set of standards and practices, each addressing a specific aspect of the subject. This will include a discussion or how the various parts are related, and the interdependencies between them.
In order to get a real appreciation of the status of the work in this area it is next necessary to review some of the recent or current developments. As with any large effort of this type there are many “moving parts” and it is sometimes easy to lose track of recent activities.
In our last topic we will look forward, both in the short and long term. This section will describe some of what we see coming, as well as some of the challenges that we face in order to make progress.
Finally, I will share contact information that will allow you to send us questions or comments.
August 2015
Copyright © ISA

4. Who we are
So, exactly “who” is this committee, where did it come from, and who are the people involved? Perhaps the more interesting question here is what is the committee trying to achieve?
August 2015
Copyright © ISA

5. ISA99 Committee
The International Society of Automation (ISA) Committee on Security for Industrial Automation & Control Systems (ISA99)
500+ members
Representing companies across all sectors, including:
Chemical Processing
Petroleum Refining
Food and Beverage
Energy
Pharmaceuticals
Water
Manufacturing
First let’s take a bird’s eye view of the committee from the outside. Established in 2002 with a small handful of interested people, the committee has since grown to a membership of over 500 people. These members come from virtually all industry sectors, although some are definitely more heavily represented than others. Contrary to what you may have heard, the focus of this group is not limited to any specific sector or industry type. We welcome membership, participation and contribution from anyone with interest and experience in the cybersecurity needs of their respective constituency.
Also, our membership is global, consistent with the global reach and scope of the International Society of Automation (ISA).
August 2015
Copyright © ISA

6. Our Scope
“… industrial automation and control systems whose compromise could result in any or all of the following situations:
endangerment of public or employee safety
environmental protection
loss of public confidence
violation of regulatory requirements
loss of proprietary or confidential information
economic loss
impact on entity, local, state, or national security”
The place to start is with an understanding of the scope that we defined for our efforts. This has remained essentially unchanged since the committee was formed.
It was deliberately stated very broadly so as to provide a solid security context for a wide range of automation related areas.
Such a broad scope is a result of the deliberate decision made by ISA in 2002 to form a single committee to address cybersecurity, rather than ask all other committees (existing and planned) to incorporate cybersecurity into their respective subjects. This approach has the benefit of being able to tap the knowledge of established cybersecurity experts, without requiring experts in other disciplines to become “min-experts” on what is often a very specialized and arcane subject.
The scope definition is based primarily on an analysis of potential consequences, as shown here. Certainly cybersecurity failures are not the only potential source of these consequences, but they may be the least understood in the general engineering community.
August 2015
Copyright © ISA

7. How we Work
That is the committee, but how does it operate? A full and detailed answer to this question is a complex subject itself, but one that is really only of interest to a smaller community of stakeholders, consisting of those who actively participate in committees.
For our purpose today we will focus only on a few specific details that are important for our general stakeholders to understand.
August 2015
Copyright © ISA

8. ISA99 and ISA/IEC 62443 ISA/IEC 62443 is a Series of Standards
Being Developed by 3 Groups
ISA99  ANSI/ISA-62443
IEC TC65/WG10  IEC 62443
ISO/IEC JTC1/SC27  ISO/IEC 2700x
To begin, let’s spend a few minutes on the relationship between the ISA99 committee and committees and work groups of others standards development organizations (SDO’s).
In addition to ISA there are at least two other SDO’s with an interest in the developing cybersecurity standards. The first of these is the International Electrotechnical Commission (IEC). When the ISA99 committee was formed there was an agreement between ISA and IEC to cooperate on the development of cybersecurity standards. This would avoid the need to create duplicate committees in each organization.
As a result of this agreement the ISA99 committee is charged with developing the majority of the standards and practices in the series. These will be issued by ISA with numbers of the form ISA x-y. At the same time or shortly after the intent is for essentially the same standards to be issued by IEC with numbers of the form IEC x-y. There is one specific standard in the series (so far) that is being developed first by IEC. The plan is for ISA to adopt it as an equivalent ISA standard.
Finally, the ISA99 committee is working closely with a joint technical committee (JTC) of ISA and IEC to ensure that our standards are consistent with the more general cybersecurity standards in the ISO series.
These working partnerships can be complex and sometimes difficult, but the result is less duplication of effort, and ultimately less confusion and more consistency for the ultimate users of the standards.
August 2015
Copyright © ISA

9. Other Partners for Related Topics
Process Safety (ISA84, IEC TC65)
Wireless Communications (ISA100)
Certification (ISCI)
Information Sharing (ICSJWG)
Security Framework (NIST)
International Reach (IEC/ISO)
etc.
In addition to the previously mentioned formal relationships between SDO’s the committee also maintains liaison relationships with several other committees and groups both within ISA and externally.
In the case of other ISA committees, recall the decision to centralize the development of cybersecurity standards into a single committee. This requires that this committee work closely with the other committees to ensure that their perspectives and needs are adequately addressed. Examples of committees with which we have such relationships include ISA84 (process safety) and ISA100 (wireless communications).
Within the Automation Federation we work closely with the Industrial Security Compliance Institute (ISCI) to ensure that the ISASecure certification program remains consistent with the contents of our standards.
In addition to other ISA and the Automation Federation we also maintain relationships with external groups such as the Industrial Control Systems Joint Working Group (ICSJWG) and various sector-specific groups and government initiatives, such as the NIST Framework.
Finally, as already described we maintained active relationships with IEC and ISO to ensure global adoption and consistency.
IACS Security
August 2015
Copyright © ISA

10. The Basics General Concepts Fundamental Concepts
With an understanding the committee structure and processes, the next step is to look at the content of the standards, starting with the basic concepts which collectively provide the foundation for the series.
These concepts are divided into two groups. The first of these includes concepts that are related to general purpose information systems security, while the second group includes concepts that are specific or unique to the domain of industrial cybersecurity.
General Concepts
Fundamental Concepts
August 2015
Copyright © ISA

11. Threat-Risk Assessment Policies and Procedures
General Concepts
Security Context
Security Objectives
Least Privilege
Defense in Depth
Threat-Risk Assessment
Policies and Procedures
Effective cybersecurity for industrial automation and control systems is an extension or enhancement to that for general purpose information technology systems. Most of the established concepts associated with general purpose IT security apply in whole or in part in the IACS environment, with some needing additional domain specific guidance or interpretation.
The concepts shown on this slide are described briefly in the first standard in the series (ISA ), along with comments as to the extent of their applicability in this context. In fact, the first of these concepts calls for a thorough understanding of the context for the application of security. This is followed by the necessity of establishing well defined objectives.
Last privilege is a principle or concept that is important in an IACS environment as in any general purpose system. Individuals and roles should be assigned only those privileges and capabilities that are necessary for completion of the necessary tasks.
Defense in depth is also an established concept in cybersecurity that applies well in an IACS environment. If is part of the basis for the more specific zones and conduits that will be described in a few moments. The use of this method is an integral part of threat-risk assessment, also a common concept for all types of IT systems.
Finally, it is critical that all aspects of the IACS cybersecurity program be established and documented in the form of policies and procedures.
Source: ISA , 2nd Edition (Under development)
August 2015
Copyright © ISA

12. Fundamental Concepts Security Life Cycle Zones and Conduits
Security Levels
Foundational Requirements
Program Maturity
Safety and Security
From the general IT security concepts we move to a list of what have been described as Fundamental Concepts, defined as those that form the IACS specific elements of the foundation for the series.
Each of these is described in more detail in the pages that follow.
Source: ISA , 2nd Edition (Under development)
August 2015
Copyright © ISA

13. Security Life Cycles
The first of these fundamental concepts is the life cycle for IACS cybersecurity, as shown in this diagram.
This life cycle is actually composed of three smaller, interconnected life cycles, each devoted to a specific phase and focused on a specific class of stakeholders.
The first of these phases includes all aspects and steps associated with the development of products and technology. The principal players in this phase are the product suppliers. This phase receives requirements from both integrators and asset owners, while providing guidelines and support to each of these subsequent phases.
Once products have been developed and delivered they are applied by systems integrators to construct complete automation solutions. This is the middle phase of this model. The requirements come primarily from asset owners, who in turn receive guidance on and support of the fully integrated system.
Finally, the third phase of the model is focused on the operation and maintenance of the integrated solution by the asset owners. Requirements and expectations are derived from this experience and passed back to either the product supplier or the integrator.
This model is introduced and described in ISA and provides a framework for most of the remaining standards in the series.
Source: ISA , 2nd Edition (Under development)
August 2015
Copyright © ISA

14. Zones and Conduits A network & system segmentation technique:
Prevents the spread of an incident
Provides a front-line set of defenses
The basis for risk assessment in system design
The second of the fundamental concepts is that of zones and conduits. It includes a series of models, requirements and guidelines that describe how a complex in interconnected system can be decomposed into a series of zones, each with a specific set of security requirements that are based on a detailed risk assessment. This concept is based on the recognition that most industrial control systems are far to complex to be treated monolithically with regard to security.
One of the primary benefits of applying this concept is that of containment, where attacks can be confined to a specific subset of the overall system.
The essential elements of this concept are introduced in ISA and the details of its application in risk assessment are addressed in ISA
August 2015
Copyright © ISA

15. System Segmentation A process to understand:
How different systems interact
Where information flows between systems
What form that information takes
What devices communicate
How fast/often those devices communicate
The security differences between system components
Technology helps, but architecture is more important
An essential element of the zones and conduits concept is that of system segmentation. Ideally, much of this analysis will have been done in the course of system design and integration. For existing systems this information has to be developed by reverse engineering the system configuration.
The various system components are described in terms of several attributes, as shown here. Functional interactions and data flows are very important, as they make it possible to understand the security related differences between them. Understanding all of these attributes makes it possible to identify the security related differences between system components. This becomes the basis for the identification of zones. These zones are turn connected by defined conduits that are defined based on information flows.
August 2015
Copyright © ISA

16. Example
This figure is an example of the application of the zones and conduits concept. Each of the “bubbles” corresponds to a zone, and these zones are in turn connected by conduits. A detailed description of this example is beyond the scope of this presentation.
August 2015
Copyright © ISA

17. Casual or Coincidental Violation
Security Levels
Casual or Coincidental Violation
Intentional Violation Using Simple Means with Low Resources, Generic Skills & Low Motivation
Intentional Violation Using Sophisticated Means with Moderate Resources, IACS Specific Skills & Moderate Motivation
Intentional Violation Using Sophisticated Means with Extended Resources, IACS Specific Skills & High Motivation
The third fundamental concept is that of security levels. Similar in some ways to that of safety integrity levels as defined in ISA84 this concept provides a means of determining a range of responses depending on the specific circumstances.
There is one important difference between safety and security levels, in that the latter are not based on a mathematical analysis of probability. Thus security levels are much more qualitative in nature, but are based on an assessment of potential consequences and the perceived nature of the attack.
This concept is also introduced in the ISA standard and applied in other standards in the series, most notably in ISA
August 2015
Copyright © ISA

18. Foundational Requirements
FR 1 – Identification & authentication control
FR 2 – Use control
FR 3 – System integrity
FR 4 – Data confidentiality
FR 5 – Restricted data flow
FR 6 – Timely response to events
FR 7 – Resource availability
As with any set of standards it is important to have a firm basis for the definition of normative requirements. In the case of the series much of this basis comes from the definition of the foundational requirements shown on this page.
The first of these requirements (FR1) speaks to the need be able to identify and authenticate users of the system. This is an established concept that forms the basis of virtually all security programs.
Once the users have been identified and authenticated it is essential to define what can be done by each of these users. This is the subject of the FR2 requirement.
Assuring the overall integrity of the industrial control system is also an essential need. This is the subject of the FR3 requirement.
Although data confidentiality may in some circumstances be relatively less important than in a conventional information system, it remains an essential requirements as described in FR4.
Data communications or transfer is also critical to the successful operation of an industrial control system. The proper control of this data flow is the subject of requirement FR5.
Similar to the situation with data flow, it is essential that the operation of industrial control systems be as deterministic (predictable) as possible, including the response to various events. This is the subject of requirement FR6.
The final requirement in this list (FR6) addresses the availability of critical system resources.
These foundational requirements are described in detail in ISA All of the more detailed technical and process requirements that appear in other standards in the series derive in some manner from the items on this list.
August 2015
Copyright © ISA

19. A means of assessing capability
Program Maturity
A means of assessing capability
Similar in concept to Capability Maturity Models
e.g., SEI-CMM
An evolving concept in the standards
Applicability to IACS-SMS
After a security program has been designed and implemented it is essential to have a means of assessing maturity in order to identify those areas that may require improvement. This is the fifth of the fundamental concepts in the series. It is very similar to other capability maturity models, such as that defined by the Software Engineering Institute (SEI).
Maturity assessment is of particular importance in the standards that address the people and process aspects of the security program, such as ISA , ISA and ISA
At this time this concept is still evolving somewhat as these and other standards are completed and issued.
August 2015
Copyright © ISA

20. Safety is much of the “raison d’etre” for security
Safety and Security
Safety is much of the “raison d’etre” for security
Presenting consequences
Much to be learned from the Security community
Collaboration
ISA99-ISA84 joint efforts
ISA Safety and Security Division
The sixth and final of the fundamental concepts is that of safety and security. Specifically, this concept establishes the basis for more detailed information and guidance with respect to how to response for of the possible combinations of safety and security level.
Since the determination of a suitable response requires consideration of both safety and security related factors, this concept is being developed in conjunction with the ISA84 committee on process safety, as well as other interested and involved parties. This includes the Safety and Security division of ISA.
August 2015
Copyright © ISA

21. Fundamental Concepts Status
Security Life Cycle
Zones and Conduits
Security Levels
Foundational Requirements
Program Maturity
Safety and Security
In summary, the six fundamental concepts at the foundation of the ISA series are well established, with some of them still requiring additional definition and clarification.
These include security levels, program maturity and safety and security.
August 2015
Copyright © ISA

22. Work Products
Now that we have described the fundamental concepts it is possible to move on to a description of the status of each of the work products in the ISA series.
All ISA committees are expect to produce some combination of Standards, Recommended Practices and Technical Reports, depending on the needs associated with the subject at hand. Of these only standards contained “normative” content, generally defined as including clear and direct statements as to what must o shall be done. The other two types of work products are generally considered to include only guidance information.
August 2015
Copyright © ISA

23. The ISA-62443/IEC Series
This graphic appears on our Wiki site and is used to show on a single page the full range of work products developed, in development or planned by the committee. As such, it provides perhaps the best “birds eye” view of what we have produced, and what we plan to produce in the future. The details of this organization change from time to time as circumstances dictate (e.g., the release of a completed standard). All such changes are reviewed and approved by a vote of the committee.
The first thing to note when looking at this diagram is that our work products are organized into four distinct groups or tiers, each with a specific focus.
The first or top tier contains standards and reports that are general in nature, and must be understood by the entire stakeholder community in order to successfully apply the standards.
With these general subjects established we move on to the second tier, which addresses the people and process aspects of an effective security program. The audience for these documents includes people who develop and operate these programs across the entire life cycle of solutions.
With the general concepts and process related aspects addressed we move to the third tier, where the focus is on the technology related aspects of security. This includes both an assessment of available technologies and their suitability for use in this context, as well as the specific requirements related to the technical aspects of a security program.
Finally, the fourth tier focuses on the specific security related technical requirements of the products and components that are used to assemble industrial control systems.
The contents of each of these tiers is described in a bit more detail in the next few slides.
August 2015
Copyright © ISA

24. General Information ISA-62443-1-1 ISA-TR62443-1-2 ISA-TR62443-1-3
Concepts and Models
ISA-TR
Master Glossary
ISA-TR
Metrics
ISA-TR
Lifecycle & Use Cases
In the first tier we have standards and technical reports that contain information that is common or fundamental to understanding the entire series. Working from left to right this starts with an “anchor” standard (ISA ) that introduces the fundamental concepts and models that form the foundation for the other standards in the series. The first edition of this standard was published in A second and more comprehensive edition is currently under development.
As important as concepts and models is a common glossary or lexicon. This need is addressed in the form of the ISA-TR technical report. This re[port has not yet been published, but a draft is available for review and comment. Moreover, all terms and definitions used in the series are maintained on a public web site (Wiki) for review and comment by our stakeholders.
The third item in this tier is a technical report that describes the metrics required to assess the successful application of a cybersecurity program. This document has not yet been published, but is under active development.
Finally, there is a technical report that describes specific use cases or examples at each stage of the cybersecurity life cycle. These examples are being defined in the course of developing the various other standards in the series. This document has not yet been developed.
August 2015
Copyright © ISA

25. Policies and Procedures
ISA
Security Management System
ISA-TR
Implementation Guidance
ISA-TR
Patch Management
ISA
Requirements for Suppliers
As stated earlier, the focus of the second tier of products is on the definition and operation of an effective cybersecurity program.
This begins with the definition of a comprehensive management system that is based on the general approach described in the ISO series, with extensions, enhancements and interpretations as required in the industrial control systems context. The first edition of this standard was released in 2009 and a second edition is currently being written.
In support of the management system definition standard this tier includes a technical report (ISA-TR ) that provides guidance in the application of that standard. In addition to what is required, this report will explain how to go about it. This report has not yet been completed.
Patch or change management is a very important (even critical) element of an effective Management system. For this reason the committee has created a separate technical report on the subject. In addition to describing how to effective manage patches and changes this report also provides a common method for the characterization of this information.
The final document in this tier speaks to the security related requirements for system and product suppliers. This is the one document in the series that has been developed by the IEC. It has been approved and will soon be available.
August 2015
Copyright © ISA

26. System Requirements ISA-62443-3-1 ISA-62443-3-2 ISA-62443-3-3
Security Technologies
ISA
Risk Assessment and Design
ISA
System Requirements
Moving to the third tier we start with a technical report that examines available security related products and technologies and their suitability for use in an industrial systems context. This report has been released and a revised edition is under development.
The second component of this tier is a standard that addresses the task of risk assessment during the design on an industrial control system. This is where the concepts of zones and conduits is described in detail as a means of segregating functions within a large and complex system, according to relative risk. This document has not yet been released but two drafts have been issued for review and comment.
Finally, the third element of this tie describes the specific foundational or system requirements that must be met for a secure industrial control system. This standard has been released and is generally available from either ISA or IEC.
August 2015
Copyright © ISA

27. Component Requirements
ISA
Product Development
ISA
Technical Component Security
It is in the forth tier that we being to delve into much more detailed security requirements for both the technical components (modules and products) as well as for the processes used to design and develop them. The principal intended audience for the standards in this tier includes system and component providers.
The first standard in this tier describes what is required for an acceptable product development process. This standard is close to completion and will soon be issued for review and comment.
The second standard in this tier describes the detailed or derived technical requirements for components of an industrial control system. The term “derived” is used to indicate that these requirements follow directly from the more general foundational requirements described in ISA This standard is close to completion and will soon be issued for review and comment.
August 2015
Copyright © ISA

28. What is Happening
With all of the above information in mid, perhaps the next logical question is what is happening NOW?
The next few pages provide a brief summary of recent development and current activities, leading to a short preview of future developments.
August 2015
Copyright © ISA

29. Recent Developments ISA-TR62443-1-3 ISA-TR62443-2-3 IEC-62443-2-4
Formally assigned to a new WG12 for development
ISA-TR
Published in July 2015
IEC
Published by IEC
Proposed adoption by ISA
First we will review some of the more recent developments related to the ISA series.
The ISA-TR technical report on the subject of metrics has long been identified as a key element of the series. In order to increase the relate of development and provide more emphasis on this product this work has been to a newly created work group (WG12). This group is now in the formative stages.
One of the committee work products that has garnered some interest is the technical report on patch management (ISA-TR ). This document has been completed and all comments received during the review process have been addressed. It will be issued by ISA as soon as the remaining administrative steps are completed.
As mentioned earlier there is one document in the series that has been developed not by the ISA99 committee by rather by work group 10 of IEC technical committee (TC) 65. This standard defines the requirements for ISCS solution providers (IEC ), and is based on earlier work by the WIB organization in Europe. Work on this standard is complete and it is being submitted as an international standard to IEC. When that step is complete there will be a vote of the ISA99 committee to adopt this standard as a part of the ISA series.
August 2015
Copyright © ISA

30. Recent Developments ISA-TR62443-3-2 ISA-TR62443-4-1 ISA-TR62443-4-2
Submitted to committee for approval
ISA-TR
Submitted to committee for comment
ISA-TR
First we will review some of the more recent developments related to the ISA series.
The ISA-TR technical report on the subject of metrics has long been identified as a key element of the series. In order to increase the relate of development and provide more emphasis on this product this work has been to a newly created work group (WG12). This group is now in the formative stages.
One of the committee work products that has garnered some interest is the technical report on patch management (ISA-TR ). This document has been completed and all comments received during the review process have been addressed. It will be issued by ISA as soon as the remaining administrative steps are completed.
As mentioned earlier there is one document in the series that has been developed not by the ISA99 committee by rather by work group 10 of IEC technical committee (TC) 65. This standard defines the requirements for ISCS solution providers (IEC ), and is based on earlier work by the WIB organization in Europe. Work on this standard is complete and it is being submitted as an international standard to IEC. When that step is complete there will be a vote of the ISA99 committee to adopt this standard as a part of the ISA series.
August 2015
Copyright © ISA

31. Current Areas of Attention
Alignment of Management System with ISO 27001:2013
Affirming of Fundamental Concepts
Detailed Requirements
Component Technical
Product Development
The relationship between security and safety
Of course, there is still much work to be done to complete the 6243 series. Some of the specific areas of focus and emphasis are shown here.
The first involves the development of revised edition of the Security Management System standard (ISA ) to improve its alignment with the most recent edition of the ISA standard (2013).
Another major area of emphasis is the development of a second edition of the Concepts and Models standard (ISA ), with a specific focus on affirming and incorporating the fundamental concepts described previously. The intent is to introduce these concepts in that standard, providing the basis for more detailed treatment and analysis in subsequent standards in the series.
Finally, a full description of the detailed requirements of the series is being developed in the form of the Product Development (ISA ) and the Components (ISA ) standards.
August 2015
Copyright © ISA

32. What are our work products? Where do things stand?
Review
Who are we?
How do we work?
What are the basics?
What are our work products?
Where do things stand?
In review, we have seen an overview of the ISA99 committee and its current and planned work products, organized into these specific topics.
August 2015
Copyright © ISA

33. Conclusion
August 2015
Copyright © ISA

34. Questions, Comments, Contributions…
ISA99 Wiki – http//isa99.isa.org
Twitter
Committee Co-Chairs
General:
Eric Cosman
Jim Gilsinn
ISA Staff Contact
Charley Robinson,
Please provide contact information & area of expertise or interest
In conclusion, this page gives information about the various contacts associated with the ISA99 committee. All questions, comments and offers for assistance are welcome.
August 2015
Copyright © ISA

35. Questions
August 2015
Copyright © ISA

36. Document Description Title and Description: ISA99 Committee Overview
Ownership:
ISA99 Leadership
Last Revised:
August 2015
Revision 4
Master Copy:
This document is located on the committee collaboration site, in the Information folder
Copy control:
Only the master copy will be maintained. Any other copies or previous revisions are considered obsolete at the time of copy.
Comments:
August 2015
Copyright © ISA