AGA Report No - Working Group - IEEE

This report is the property of AGA and is part of its process for developing new documents. This report or any of its part shall not be copied, disseminated, cited in literature, presentations or discussions without prior approval from AGA.

Cryptographic Protection of SCADA Communications - DRAFT 1 -

AGA Report No. 12-1

March 24, 2003 Prepared by the AGA 12-1 Working Group

Cryptographic Protection of SCADA Communications

DRAFT 1


Disclaimers and Copyright Nothing contained in this publication is to be construed as granting any right, by implication or otherwise, for the manufacture, sale, or use in connection with any method, apparatus, or product covered by letters patent, or as insuring anyone against liability for infringement of letters patent. Efforts have been made to ensure the accuracy and reliability of the data contained in this publication; however, AGA makes no representation, warranty, or guarantee in connection with this publication and hereby expressly disclaims any liability or responsibility for loss or damage resulting from its use or from the use of any product or methodology described herein; for any violation of any federal, state, or municipal regulation with which this publication may conflict; or for the infringement of any patent from the use of this publication. Nothing contained in this publication should be viewed as an endorsement by AGA of any particular manufacturer’s products. Permission is granted to republish material herein in laws or ordinances, and in regulations, administrative orders, or similar documents issued by public authorities. Those desiring permission for other publications should consult the Operating and Engineering Section, American Gas Association, 400 North Capitol Street, NW, 4th Floor, Washington, DC 20001, U.S.A. Copyright  2003 American Gas Association, All Rights Reserved

ii


DRAFT 1


Executive Summary Over the past year our nation’s outlook on security has changed. Always a core element of American life, security is no longer taken for granted. Today the safety of our country and the resources we rely upon must be worked at daily. As providers of life-critical products and services, natural gas, electric, water, wastewater and pipeline industries find themselves needing to develop new security systems and procedures. We are not primarily concerned with bored teenagers posting pornography on corporate networks or college students testing hacking abilities. Today’s cyber attacks are increasingly based upon criminal intent. Initiated as a proactive measure under the guidance of Presidential Decision Directive 63 (PDD63) and completed with increased urgency and priority subsequent to the heinous events of September 11, 2001, the following report provides a blueprint for protecting utilities’ infrastructures against invasions of privacy and potential terrorist attacks. Our nation’s security is only as strong as its weakest link. Once thought of as secure networks, Supervisory Control And Data Acquisition (SCADA) and Distributed Control Systems (DCS) are in fact vulnerable. This report is focused upon retrofitting security to existing networks with a common goal of protecting resource delivery systems and safeguarding utility company assets in the most efficient and least intrusive manner possible. This recommended practice defines cryptographic protection for SCADA

systems that use asynchronous serial data links that are exposed to cyber attack. The data links to which this report applies are those that are outside of the areas in which the system operator can provide physical and/or communication security. Examples include portions of the SCADA communications that are carried over public switched telephone networks, leased lines, proprietary wire lines and wireless communication links. Recommendations included in this report apply to some Distributed Control Systems (DCS). The contents of this report have been compiled through the collaborative efforts of organizations including the American Gas Association (AGA), the Gas Technology Institute (GTI), the Institute of Electrical and Electronics Engineers (IEEE), National Institute of Standards & Technology (NIST), gas and electric utilities operators, SCADA and cryptographic vendors and security industry experts. By recommending actionable solutions using affordable, off-the-shelf, easily deployable technologies, this

iii


DRAFT 1


report seeks to provide a common basis for new security systems can be developed and implemented across a wide range of utilities infrastructures.

iv


DRAFT 1


Table of Contents Page 1. OVERVIEW ...........................................................................................................................................................1 1.1 1.2 1.3 1.3.1 1.3.2 1.4 1.5

SCOPE..........................................................................................................................................................1 PURPOSE –...................................................................................................................................................1 DOCUMENT ORGANIZATION ........................................................................................................................1 How Individuals Should Read This Report ............................................................................................3 How Companies That Use SCADA Should Use This Report .................................................................4 HOW TO READ THIS REPORT ......................................................................................................................4 PLANNED EVOLUTION OF AGA REPORT 12 ................................................................................................5

2. INTRODUCTION ..................................................................................................................................................6 2.1 DO EXISTING SCADA SYSTEMS NEED TO BE PROTECTED AGAINST CYBER ATTACK? .........................................6 2.1.1 Access is easy .............................................................................................................................................6 2.1.2 Communication access means that the attacker can read SCADA data ....................................................7 2.1.3 With SCADA data, the attacker can alter your system operation ..............................................................7 2.2 THERE IS AN AFFORDABLE SOLUTION AVAILABLE ..............................................................................................7 2.3 WHERE TO BEGIN ................................................................................................................................................8 3. SECURITY POLICY RECOMMENDATIONS..................................................................................................9 3.1 WHY A SECURITY POLICY IS NEEDED ..................................................................................................................9 3.2 WHAT A SECURITY POLICY SHOULD AIM TO ACHIEVE ........................................................................................10 3.3 STRUCTURE OF A SECURITY POLICY ..................................................................................................................10 3.3.1 Purpose ....................................................................................................................................................10 3.3.2 Scope ........................................................................................................................................................10 3.3.3 Responsibilities ........................................................................................................................................11 3.3.4 Contacts ...................................................................................................................................................11 3.3.5 Sanctions ..................................................................................................................................................11 3.3.6 Other information.....................................................................................................................................11 3.4 BEYOND POLICY, WHAT IS DESCRIBED IN A FULL SECURITY PLAN ....................................................................11 3.4.1 Risk assessment ........................................................................................................................................11 3.4.2 Implementation guidelines .......................................................................................................................12 3.4.3 Maintenance plan of action......................................................................................................................12 3.5 THE ROLE OF AGA 12 IN THE SECURITY POLICY ..............................................................................................12 4. TECHNICAL RECOMMENDATIONS ............................................................................................................13 4.1 OVERVIEW ........................................................................................................................................................13 4.2 CRYPTOGRAPHIC MODULE IDENTIFICATION ......................................................................................................13 4.3 FIPS 140-2 REQUIREMENTS ..............................................................................................................................13 4.4 AGA 12-1 SECURE COMMUNICATIONS PROTOCOL REQUIREMENTS - GENERAL ..............................................15 4.5 SESSIONS ..........................................................................................................................................................15 4.6 AGA 12-1 KEY MANAGEMENT REQUIREMENTS ..............................................................................................15 4.7 FIRMWARE UPDATES ........................................................................................................................................15 4.8 PLAINTEXT PASSTHROUGH ...............................................................................................................................16 4.9 FUTURE DIRECTIONS ........................................................................................................................................17 5. OPERATIONAL RECOMMENDATIONS.......................................................................................................18

v


DRAFT 1


5.1 5.2 5.3 5.4 5.5

COMMISSIONING –.....................................................................................................................................18 MAINTENANCE ..........................................................................................................................................18 KEY MANAGEMENT ...................................................................................................................................18 FORENSICS/AUDIT .....................................................................................................................................18 BROADCAST/MULTICAST CAPABILITIES .....................................................................................................19

6. QUALITY RECOMMENDATIONS..................................................................................................................20 6.1 INSTALLATION AND PHYSICAL ACCESS REQUIREMENTS ....................................................................................20 6.1.1 Master station physical access.................................................................................................................20 6.1.2 Field installation/device physical access .................................................................................................20 6.2 ENVIRONMENTAL REQUIREMENTS ....................................................................................................................20 6.3 POWER REQUIREMENTS ....................................................................................................................................21 6.4 CRYPTOGRAPHIC QUALITY ...............................................................................................................................21 6.5 AGA 12-1 COMPLIANCE ...................................................................................................................................21 6.6 INTEROPERABILITY AMONG MANUFACTURERS .................................................................................................21 7. SYSTEM REQUIREMENTS ..............................................................................................................................22 7.1 EXTERNAL COMMUNICATION INTERFACES TO THE SCADA SYSTEM ................................................................22 7.1.1 Control center communication interface requirements............................................................................22 7.1.2 Local SCADA master communication interface requirements.................................................................22 7.1.3 RTU communication interface requirements............................................................................................22 7.2 INTRUSION DETECTION AND FORENSICS ............................................................................................................23 7.3 QUALITY REQUIREMENTS FOR SCADA SYSTEM’S CRYPTOGRAPHIC MODULES ................................................23 7.3.1 Interoperability ........................................................................................................................................23 7.3.2 Scalability.................................................................................................................................................23 7.3.3 Reliability .................................................................................................................................................23 7.3.4 Availability ...............................................................................................................................................23 7.3.5 Maintainability.........................................................................................................................................24 7.3.6 Flexibility and expandability....................................................................................................................24 8. TECHNICAL REFERENCES ............................................................................................................................25

vi


DRAFT 1


ANNEXES A

Bibliography (Informative)

16

B

Definition of Terms and Acronyms (Normative)

17

C

"SCADA for Dummies" (Informative)

31

D

Protecting SCADA Communications (Informative)

38

E

"Cryptography for Dummies" (Informative)

43

F

Security Requirements for Cryptographic Modules (Informative)

44

G

Sample SCADA Communication Security Policy (Informative)

47

H

Symmetric Key Management (Normative)

48

I

Cryptographic System Test Plan (Normative)

49

J

Sample Purchase Orders and Discussion of the Implications (Informative) 62

K

Cryptographic Protocol Description (Normative)

63

L

FIPS-PUB 140-2 (Normative)

71

M

Device Manufacturers Security Policy (Informative)

73

vii


DRAFT 1


ACKNOWLEDGEMENTS Paul Blomgren, Rainbow/Mykotronx Bill Burr, NIST Jim Coats, Triangle MicroWorks Bernie Cowens, Rainbow/Mykotronx Byron Coy, U.S. DOT/RSPA, Pipeline Safety Jim Evans, St. Claire Group, LLC Matthew Franz, CISCO Systems Ray Gannon, Bristol Babcock Grant Gilchrist Art Griesser, NIST Dennis Holstein, OPUS Publishing Jim Khalaf, Rainbow Technologies John A. Kinast, GTI Joe McCarty, GTI Michael McEvilley, Decisive Analytics Kevin McGrath, KeySpan Brian McKeon, Airlink John Meyo, Weston Technology Steve Pettit, Wisconsin Electric-Wisconsin Gas Fred Proctor, NIST Ali Quraishi, AGA Bill Rush, GTI Irv Schwartzenburg, Emerson Process Mgmt. Mark Seiden, MSB Associates George Shaw, Peoples Energy Lee Smith, HLS Consultant Services John Tengdin, OPUS Publishing Al Wavering, NIST Joe Weiss, EPRI James Westervelt, PSE&G Clay Weston, Weston Technology Andrew Wright, CISCO Systems

- – 8 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


1. Overview 1.1

Scope

This recommended practice defines cryptographic protection for SCADA systems that use asynchronous serial data links that are exposed to cyber attack. An affordable retrofit solution, which can be implemented by inserting cryptographic modules at each end of the communication link, is recommended. Public switched telephone networks, leased lines, proprietary wire lines and wireless communication are addressed. This specification does not address modification of software or hardware in existing SCADA systems, but does define operating parameters needed to use the cryptographic system. Recommendations included in this report apply to some Distributed Control Systems (DCS). 1.2

Purpose –

This report establishes the recommended practice to implement cryptographic protection on SCADA communication links. Cryptographic modules implementing this practice will provide the functions, features, and performance specified, and should introduce only minimal interference with normal SCADA communications. Cryptographic system developers should use this report to design and develop cryptographic solutions. End users should use this report to define requirements for purchasing, installing, commissioning, and operating cryptographic solutions to protect infrastructure against cyber attack. 1.3

Document Organization

In addition to the overview described in this section, Section 2 is an informative description of who needs security and why. Section 3 is a normative description of a recommended security policy. Technical, operational, and quality recommendations are described in sections 4 through 7. References are included in Section 7. Annexes are summarized in the table below, including an entry indicating whether the annex is normative or informative in nature.



DRAFT 1


ANNEX TITLE A B C D

E

F G

H I

J K L M

SUMMARY

Bibliography Definition of Terms and Acronyms SCADA for Dummies

Bibliography Terms and acronyms used throughout the document. Background on system being protected SCADA Communication A basic outline of SCADA Threats communication systems, and discussions about protection problems, potential assailants, types of attacks, and limits of protection. Cryptography for Basics of cryptography- what it is, Dummies what it does, what it does not do, and special issues relating to SCADA systems. Security Requirements for Technical statement of required Cryptographic Modules cryptographic protection capabilities Provides a model for a wideSample SCADA Communication Security ranging corporate policy regarding information security, emphasizing Policy units deployed in the field. Symmetric Key Symmetric key generation, Management distribution, use Cryptographic System Test plans for all configurations of Test Plan cryptographic modules designed to meet the requirements of AGA Report 12. A user's guide to this report Sample Purchase Orders and Discussion of the Implications Cryptographic Protocol Packet structure, commands, and Description protocol, FIPS-PUB 140-2 Reprint of Federal standard, included for convenience Device Manufacturers A manufacturer's guide to this Security Policy report


TYPE Informative Normative Informative Informative

Informative

Informative Informative

Normative Normative

Informative Normative Normative Informative


DRAFT 1


1.3.1

How Individuals Should Read This Report

This report is written to address the needs of several different audiences; the purpose of this section is to identify those audiences and to guide them in locating and understanding this AGA Report. To use this document, first identify which of these audience descriptions best describes you best fit into. Then go to the paragraphs immediately following the audience descriptions to be directed to the Report Sections that we believe should be of greatest interest to you, listed in the order in which we suggest you read them. The following audiences for this Report have been identified: •

Executives responsible for the SCADA systems who must decide on appropriate protection

•

SCADA system operators who must understand the cryptographic aspects of operating and protecting their systems

•

Engineers and designers who must specify distribution and transmission company cryptographic protection

•

Manufacturers who wish to make equipment that complies with this Report

•

Consultants and system integrators who are called on to advise SCADA operators on the design and operation of such systems in a manner that reduces likelihood of successful cyber-attack

•

Cryptographic experts, and

•

Certifying agencies that wish to validate compliance with this Report.

The sections thought to be of most interest to each audience - and the order in which they may be most easily read - are as follows: Executives should read the Executive Summary, Sections 1, 2, and 3, and Annex G. SCADA system operators should read Sections 1, 2, 3, 5, and Annex D. Engineers and designers should read Sections 1, 2, 3, 4, 5, 6, 7, and Annexes D, E, F, G, I, J, and L. Manufacturers should read the Executive Summary, Sections 1, 2, 3, 4, 6, 7, and Annexes D, E, F, H, I, J, K, L, and M Consultants and system integrators should read the Executive Summary, Sections 1, 2, 3, 5, 6, 7, and Annexes D, E, F, G, H, I, J, K, L, and M. Cryptographic experts should read Sections 1, 2,3, 4, 5, 6,7, and Annexes C, D, F, G, H, I, J, K and M - – 3 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


Certifying agencies should read The Executive Summary, Sections 1, 2, 4, 6, 7, and Annexes F, G, H, I, K, and L 1.3.2 How Companies That Use SCADA Should Use This Report This document consists of a combination of normative and informative sections whose collective objective is to aid utilities in understanding and mitigating their SCADA system data vulnerabilities. The process of creating a more secure SCADA environment requires a combination of business, policy, operational and technical decisions. This section provides a guide for using the information contained in the document to create a suitable solution to meet your particular organization’s needs. The first step is to familiarize yourself with the physical characteristics of your SCADA system. Does it have any communication links that are at risk of being tapped by a potential assailant or into which unauthorized signals could be introduced? If not, then this document does not apply to your system. If so, the next step is to evaluate the vulnerability of those exposed data streams to attack and the risk to your organization of a successful attack. 1.4

How To Read This Report

Words defined in this standard are intended for use only with sections of this standard. Definitions set forth in any document referenced by this standard shall be the acceptable definition for use of that document only. Words not specifically defined in this standard shall have their ordinarily accepted meaning or such as the context may imply. Annex B is a complete set of definitions set forth in this standard. The following is a subset of those definitions, provided to aid the reader of this standard. May: the word may, equivalent to “is permitted,” is used to indicate a course of action permissible within the limits of this standard. Must: the use of the word must is deprecated and shall not be used when stating mandatory requirements. The word must is only used when describing unavoidable situations. Recommended: the word recommended is used to indicate flexibility of choice with a strong preference alternative. Shall: the word shall, equivalent to “is required to,” is used to indicate mandatory requirements, strictly followed in order to conform to the standard and from which no deviation is permitted. Should: the word should, equivalent to “is recommended that,” is used to indicate• Among several possibilities one is recommended as particularly suitable, without mentioning or excluding others. • That a certain course of action is preferred but not required. • That (in the negative form) a certain course of action is deprecated but not prohibited. An additional set of terms that are important to understand are "normative" and "informative". Normative material (found in the numbered sections in the body of this - – 4 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


report) is the set of requirements that are mandatory for the product or system to claim compliance with AGA 12-1. Informative material is included to make the content of the standard easier to understand. As such, informative material might include suggestions for more efficient operation, explain parts of the standard, or supply the rationale for decisions that were made. Various annexes are specifically designated as either normative or informative. Note that it is mandatory that products or systems claiming compliance with this document comply with all normative annexes. 1.5

Planned Evolution of AGA Report 12

AGA plans to issue a series of AGA 12 documents to incorporate lessons learned, and to expand the scope to address new SCADA/DCS designs. AGA 12-1’s goal is to “get the plain text messages off the wire as quickly as possible.” To achieve this goal AGA 12-1 focuses attention on the retrofit market, which encompasses 80% of existing SCADA systems. New SCADA systems that are part of a truly distributed processing architecture of networked Intelligent Electronic Devices (IEDs, a general term that refers to any device that incorporates one or more processors with the capability to receive or send data/control from or to an external source) will be the focus of AGA 12-2. In addition to other challenges AGA 12-2 will provide additional cryptographic protocol specifications to enhance interoperability of cryptographic components produced by different vendors. Retrofit solutions based on AGA 12-1 will be field tested, and lessons learned will require changes to current specifications. These changes will be subject to version control, and published as updates to AGA 12-1.



DRAFT 1


2. Introduction The objective of this section is to make the reader aware of the significant threats against SCADA communication links, and to recommend a course of action. 2.1 Do existing SCADA systems need to be protected against cyber attack? Can someone really gain access to your SCADA system? And if they do, what damage can they inflict? These two questions need to be addressed before one looks for solutions to a problem that may not exist. 2.1.1 Access is easy A few people may have the impression that SCADA systems are inherently secure so that access by an intruder is not possible, but that is not the case. Here are some of the issues: Impression

Reality

We use leased lines, so nobody has access It’s easy to tap these lines. The web site to our communications. www.tscm.com/outsideplant.html shows many examples. We use dial-up phone lines, but nobody A tap on outgoing lines or detailed billing records knows the phone numbers. quickly reveals every phone number dialed by the master. Software is available on the Internet to automatically dial banks of numbers and identify those that are answered by a modem. We use dial-back modems so that Once the line is tapped, dial-back is easily unauthorized users cannot gain access. defeated. Other known methods do not require tapping the line. Our systems are protected by passwords Methods of stealing passwords are widely known. The easiest is to simply eavesdrop when the password is sent, in the clear, over the communications link. There are simple methods to decode frequencyWe use frequency hopping spread hopping sequences. The Wireless LAN Association spectrum radio, the same as the military specifically recommends using encryption on all for secure communications networks, including spread spectrum. That’s what the military uses - encryption. We use a proprietary bit oriented protocol Even proprietary protocols are more widely known than many realize. Vendors, vendors’ consultants, so an eavesdropper couldn’t understand your current and former employees, current and our SCADA messages. former employees of other companies using the same SCADA protocol will know the details. Software tools for analyzing protocols can be downloaded from the Internet. - – 6 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


An attacker could be a disgruntled employee, an employee who has recently been laid-off, a third-party maintenance contractor, a vendor supplying SCADA hardware and software, or a rogue state. All have easy access to your SCADA system. With little effort an attacker can scan the communication links between remote sites, and between remote sites and control centers. Access can also be gained through back channels used to establish field device operational settings and through back channels used to modify field device software. In a control center, many SCADA systems write data to a master station database, which is then read by others to perform a wide variety of business functions. This interface may also be compromised -- giving the attacker access to either SCADA operations, or to sensitive data used by business operations. Although access to business data is extremely important, AGA Report 12 does not address this issue. 2.1.2 Communication access means that the attacker can read SCADA data Based on the above table, it is prudent to assume that an attacker can learn how an installed SCADA system operates. The ability to access and read SCADA data then provides two important pieces of information to the attacker: Status data provides the information needed to understand the status of systems that control operations, and control data (settings) and commands provide the information needed to perform the control actions. 2.1.3 With SCADA data, the attacker can alter your system operation If an attacker can read SCADA data and understands how the SCADA system operates, then he can alter system operation by issuing false commands or by establishing control settings that cause the system to operate in a degraded mode or fail. The motivation to do this may be to do malicious damage to the service provider in terms of reliability and availability of service, or to the customer in terms of loss of service resulting in the disruption of the customer’s operation. If the attack is well-coordinated and wide spread, the result could cause significant problems to the health and safety of the affected population. Or, the motivation may be good-old-fashion greed. For example, gas and electricity are sold as commodities. If the transmission and distribution system operation is predictably altered, the attacker may be able to use this knowledge to reap a significant financial gain. 2.2 There is an affordable solution available The technology to counter cyber attack on SCADA systems is available today. AGA Report 12-1 is focused on one important aspect of the problem – the attacker’s ability to



DRAFT 1


read SCADA status and control data by intercepting its transmission over asynchronous communication links, and to issue commands that cause false operations1. AGA Report 12 defines the requirements to implement a cryptographic system that will work on most SCADA communications systems installed today. It includes the means to encrypt SCADA messages so that unprotected messages are not sent over the communications channels, which are susceptible to cyber attack. The recommended encryption algorithms and cryptographic key management features meet Federal Standard FIPS-PUB 140-2 to assure confidentiality that can be certified. The recommended practice defined in AGA Report 12-1 is designed to provide a retrofit solution that is not intrusive to either the SCADA master or to remote terminal units (RTUs). The cryptographic system can be implemented in link-encryption modules at the ends of the communication link. These modules could be inserted between the SCADA master and the modem in the control center, and between the remote terminal unit and modem in the field2. They may also be used on multidrop lines. The modules communicate with their counterparts in a manner transparent to the SCADA system once communication is established. Therefore, little or no changes to SCADA master or field device operational hardware/software are required, nor is any change required to the communication modems. 2.3 Where to begin AGA Report 12 addresses a wide range of issues related to cryptographic system requirements, design guidance, testing, and commissioning. In addition to hard-core requirements, many options are defined to address special circumstances of the end users. To effectively apply AGA Report 12-1 recommendations, as a first step, the user needs to define a “Security Policy,” as summarized in the next section.

1

AGA Report 12-1 does not address endpoint security to protect against access through the SCADA database serving the business functions, nor does it address protecting data at rest. 2

This may also apply to other unprotected links, such as dial-up to relay IEDs.



DRAFT 1


3. Security policy recommendations AGA 12-1 recommends the development of a security policy. This section addresses why a security policy is needed, what a security policy aims to achieve, characteristics of a security policy, beyond the policy – what is described in a full security plan, and the role of AGA 12 in the security policy.

3.1 Why a security policy is needed Process control systems, SCADA in particular, and the information they contain, are of vital importance to the efficient operation of gas, electric, water, waste water and pipeline transmission and distribution. These systems and the associated information processing tools and services are to varying degrees integrated with the business functions. With increasing reliance on electronic information comes a corresponding concern for the security of that information in transit and at rest. Institutions must be able to rely on the four key aspects of information security: •

Availability (knowing that the information can always be accessed)

•

Integrity (knowing that the information is accurate and up-to-date, and has not been deliberately or inadvertently modified)

•

Confidentiality (knowing that sensitive information can be accessed only by those authorized to do so)

•

Authenticity (knowing the source of the information and the identity of those using it.)

More precisely, since neither the systems themselves nor those who operate them can ever be totally reliable, the organization must reduce risks to an acceptable level, to react promptly and appropriately to any security incident, and to restore information systems to their normal operational state in an acceptable period of time. Security breaches, often involving prominent commercial organizations, are reported periodically in the press and often generate substantial adverse publicity. Such incidents tend to fuel the popular conception that the major threat to information security comes from hostile attacks perpetrated via the Internet. Although there is some truth in this, the picture it paints is highly oversimplified. Electronic information is at risk for a whole variety of reasons, and of particular concern is a malicious act by a sophisticated attacker who seeks to gain financial advantage, to cause serious damage, or to create a state of disruption or terror in the community. Investing in suitable security measures has a significant cost. It is inevitable that security concerns will consume staff time, and in most cases there is likely to be security-related expenditure on hardware, software and services as well. The value of this investment can only be correctly judged in the context of a policy on information security. It is all too easy to fund this area inadequately or inappropriately. In order to rationally allocate funds, the organization must assess its risks using a process much like the following: •

Identify the mission and key assets of the organization.

•

Identify the threats that can cause loss or damage to assets or impact the organization’s ability to fulfill its mission.

•

Evaluate the potential consequences of security breaches, including loss of assets and impact on public health and safety, revenues, reputation, public confidence, and contract or regulatory compliance.



DRAFT 1


•

Identify means of preventing attacks and/or mitigating their costs or effects.

•

Prioritize and implement security measures based on degree of risk3 and available resources.

The impact on the organization, should a security breach occur, could potentially be very serious. Conversely there is little point in spending money unnecessarily to protect data of little value or which can easily be recreated. The other benefit of an information security policy is that it provides a framework within which to define roles and responsibilities with respect to data security, to formulate and justify any procedures which are felt to be needed, and to make explicit management’s attitude to any actions that threaten the security of information assets.

3.2 What a security policy should aim to achieve On the practical and operational front, the policy should provide the context for a supporting set of guidelines and procedures, which will establish, at a detailed level, how security is implemented for all the SCADA systems concerned. Overall the policy must define the role that information security plays in supporting the mission and goals of the utility. It should be linked to (and should depend upon) the corporate information strategy, and should be drawn up by a sub-group of personnel responsible for this strategy. Even though much of the work on information security will be performed by middle managers and technical staff, it is important that senior management be committed to the importance of information security and should play their full part in winning acceptance for the policy’s promulgation within the enterprise.

3.3 Structure of a security policy An early decision to be taken in drafting a security policy is the level of detail it should contain. It is strongly recommended that the utility should adopt a structure with a short, easily understood high-level policy document – intended to be read and accepted by all staff – supported by a number of more specific documents. Examples of the latter are given in the following section. Although the high-level policy document should, like all statements of policy, be reviewed periodically to ensure that it remains in step with the evolving needs of the organization, it should be possible to frame it in a way that is relatively independent of particular technologies. This should ensure that the policy document does not have to change too rapidly. A model structure for a high-level information security policy might include the following main headings.

3.3.1 Purpose The purpose should describe the main goals of the policy, and the reasons why the policy is needed. It may be helpful to include any references to legal compliance issues under this heading.

3.3.2 Scope The scope should describe the infrastructure and SCADA systems to which the policy applies, and the people who are stakeholders in it. Stakeholders in the policy typically 3

Degree of risk is based on the likelihood of a successful attack and the potential consequences of the attack.



DRAFT 1


include all users of the information systems, and non-user stakeholders. Users include operators, engineers, and those responsible for related business function. Non-user stakeholders may include, managers who are concerned with operational and budgetary issues, and those concerned with the legal, regulatory, financial liability, and of the reputation of the utility – senior management, board of directors, share holders, internal and external auditors, and other legal and business advisors, and those responsible for interpreting and enforcing compliance with the policy.

3.3.3 Responsibilities A statement of the structure or structures through which responsibility for implementing security measures in various parts of the organization is delegated. Key personnel in this respect include the Information Security Officer (if such a post exists), and departmental system or network managers in an organization with significant devolution to departments. It is suggested that the responsibilities of individual staff should be spelled out in a supporting document under the title of the "Acceptable Use Policy, Regulations for the Use of SCADA Systems”, or similar wording; such a document is likely to be in existence already.

3.3.4 Contacts A statement of how and to whom any actual or suspected security incidents should be reported. A contact for questions about interpretation or enforcement of the policy.

3.3.5 Sanctions A statement of the action to be taken by management in the event that a breach of security occurs. If flagrant or repeated abuses of security are regarded as gross misconduct (potentially grounds for dismissal) the policy should state this clearly.

3.3.6 Other information Other information should describe a list of references to any additional documents that particular groups may need to know about (see annexes to this document).

3.4 Beyond policy, what is described in a full security plan Drawing up a security policy or policies is of course only the start of a full security plan. The policy defines the utility's attitude to security and makes clear the part that all employees and contractors have to play in creating a suitable culture of information security. Converting policy into practice requires a risk assessment, implementation guidelines, and a maintenance plan of action.

3.4.1 Risk assessment Risk assessment should address the need to prioritize and rank-order the risks by performing the following tasks. Setting a value on the utility's physical, technological and information assets. Determining the importance of reputation, public confidence, disruption of vital services to the community, and the potential threat to the life and health of their customers. Assessing the risks to those assets (by first identifying the threats to which each asset is subject, and then assessing the likelihood that that a threat will be realized in practice). From the foregoing steps, determining the security level appropriate to the protection of each asset, i.e. the security measures which are felt cost-effective to deploy.



DRAFT 1


3.4.2 Implementation guidelines Implementation guidelines should include the necessary budget and staff resources needed to procure and install the required security measures. And, to put in place the continuing training and auditing needed to support the effective operation of the required security measures.

3.4.3 Maintenance plan of action A maintenance plan of action should include a timetable for regular review of the security plan to keep in step with the evolving needs, and with changes in local personnel and the external environment.

3.5 The role of AGA 12 in the security policy AGA 12-1 describes a comprehensive method to protect SCADA data in transit over the communication links. Specific examples of possible security policies to protect the SCADA infrastructure are included in Annex G of this report.



DRAFT 1


4. Technical Recommendations This section sets forth the basic technical requirements for cryptographic modules designed to comply with AGA 12-1 4.1 Overview To assure cryptographic quality and to simplify validation of cryptographic modules, all AGA 12-1 compliant modules shall be FIPS 140-2 compliant with an overall rating of Level 2, as set forth in Clause 4.2. In addition to FIPS 140-2 compliance, AGA 12-1 compliant modules shall also comply with the requirements set forth in Clause 4.3. Many of the security requirements of AGA 12-1 address cryptographic modules installed at a remote site. The security requirements at the central computers may be different, and the data may not actually travel through an asynchronous serial link at the central computer end. AGA 12-1 recognizes the possibility that not all of the security requirements may apply to the cryptographic protection used at the central computer. In all cases, the cryptographic protection method used at the central computer shall be no less secure than the hardware and software used to control the SCADA system. Cryptographic protection at the central computer can take the form of software, hardware, or both. Any central computer security requirements such as limited physical and logical access and password protection shall apply equally to the cryptographic protection hardware and/or software. The user should be aware of the potential threat from insiders as it applies to both the SCADA system control software and the central computer cryptographic protection method. A cryptographic protection method that meets all of the security requirements of AGA 12-1 may not provide complete protection against the insider threat. The protection of the secret cryptographic keys against theft or exposure is particularly important. The most effective protection against intentional insider threats is enforcement of an effective security policy.

4.2 Cryptographic Module Identification Every Cryptographic Module (CM) shall include a unique identification value designated the CMID. The CMID shall be stored in non-volatile memory and shall be protected against deletion or alteration for the life of the CM. A manufacturer may not claim AGA compliance for any product that does not include a CMID. The CMID consists of two fields, designated MODEL and SERIAL. The MODEL field is two bytes in length, and the SERIAL field is three bytes in length. The MODEL field designates a specific manufacturer and model number. All units with the same model field shall use sequential serial numbers, with no two units having the same serial number. The serial number is contained in the SERIAL field. The MODEL value is assigned by the AGA 12 Users Group and the SERIAL value is assigned by the manufacturer. 4.3 FIPS 140-2 Requirements All AGA 12-1 compliant cryptographic modules shall comply with the following requirements. Here, the "Section" refers to the section of FIPS 140-2 (included here as Annex L). "Level" refers to the Security Level as defined in Section 1 of FIPS 140-2. Notes are the FIPS 140-2 requirements as further specified by AGA 12-1. Unless otherwise stated, cryptographic modules - – 13 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


shall incorporate the general details and documentation requirements in the corresponding FIPS 140-2 Section without modification. FIPS 140-2 specifies requirements for CMs that can be used for a number of purposes, with different levels of security. Although it is possible to assign an overall security level, AGA 12-1 details which levels are required for different aspects of CMs, as shown in the following table. FIPS 140-2 Section 4.2—Cryptographic Module Ports and Interfaces 4.3.1—Roles

4.3.2—Services 4.3.3—Operator Authentication

4.4—Finite State Model

4.5—Physical Security 4.6—Operational Environment 4.8— Electromagnetic Interference/Electro magnetic Compatibility (EMI/EMC) 4.9.1—Power-Up Tests 4.10.2—Delivery and Operation 4.10.3— Development

AGA 12-1 Comments and Additional Constraints Cryptographic Module Ports and Interfaces must satisfy Security Levels 3 and 4. •

The User Role may be assumed by machine such as an IED, FEP, or central computer. • The Crypto Officer Role may only be assumed by a properly authorized human. • The Maintenance Role shall be provided. Modules shall support a bypass mode. • Security Level 2 (Role-Based Authentication) to control access to the module is required. • Security Level 3 (Identity-Based Authentication) is optional, based on a utility's security needs and operations. • The User states in the model shall reflect normal operation of the modules. • Bypass states and Maintenance states are included because of the inclusion of those functions in previous sections. Compliant modules shall meet Level 2 (use of tamper-evident packaging). Utilities may desire Level 3 in some cases, because evidence of tampering may not be observed in a timely fashion when cryptographic modules are remotely located. Security Level 2 is required. Compliant modules shall meet Security Level 2 (which is the same as Level 1), for business use.

Compliant modules shall meet Security Level 2. Compliant modules shall meet Security Level 2 (and 3 and 4). Compliant modules shall meet Security Level 2. - – 14

AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


4.4 AGA 12-1 Secure Communications Protocol Requirements - General Part of the AGA 12 development process was research to find a secure communications protocol suitable for the SCADA retrofit application. Annexes D and F outline the criteria used in the search. No suitable existing protocol was found. As a consequence, the SCADA Link Security (SLS) protocol found in Annex K was developed for the application. Because the communications protocol is a critical element of security, AGA 12-1 requires conformance with Annex K.. The SLS protocol provides a means for remote management of cryptographic modules. Manufacturers and/or users may choose to prevent remote access to certain functions that may compromise security or impact operations. The capability to block remote access to specific functions is a vendor option.

4.5 Sessions To avoid the time required for strong domain authentication and authorization, individual SCADA messages are sent within the context of sessions. At least one session exists for each communicating pair of cryptographic modules. The session holds communication state information including initialization vectors, keys that are valid only for the life of the session, and parameters for communication. Session establishment accomplishes domain authentication, authorization, and the establishment of a session data key. Within a session, authentication and authorization are inferred from the possession of valid session data keys. 4.6 AGA 12-1 Key Management Requirements Companies employing cryptographic protection are strongly advised to implement a security policy. A model security policy is included as Annex G of this document. Procedures related to key management (generation, transfer, storage, lifetime, invalidation) are a vital part of the security policy. AGA 12-1 specifies a key management method in Annex H. Compliance with AGA 12-1 requires implementation of this method. Annex H relies entirely on the use of a symmetric (secret key) algorithm. The authors of AGA 12-1 recognize the value of asymmetric (public key) algorithms, especially for initial key establishment and entity authentication. The characteristics and constraints of SCADA systems create unique problems in the implementation of a key management method using asymmetric algorithms. At the time of publication of AGA 12-1, these problems were not satisfactorily addressed. It is anticipated that a future version of AGA 12 will include a key management method using an asymmetric algorithm approved by FIPS 140-2. It is further anticipated that both methods (symmetric and asymmetric) will be approved by AGA 12.

4.7 Firmware Updates Cryptographic modules may support the capability for the addition or replacement of firmware after the modules are deployed. This capability is desirable because it allows manufacturers to correct problems, update compliance, or add features without requiring replacement of the module. If supported, the firmware update function must meet the following requirements: •

The code shall be “signed” by the manufacturer. The specific method of signing is not specified at this time, but the purpose is to ensure that the code originates with the manufacturer and that it has not been altered.



DRAFT 1


•

The manufacturer shall specify whether the code affects approved security functions. Only the Maintenance role shall authorize a firmware update that affects approved security functions. As specified by FIPS 140-2, authorization of the Maintenance role erases all Critical Security Parameters.

When supported, firmware updates may be installed through local and/or remote transmission. Local transmission is through a cable connected to the maintenance port of a CM. Remote transmission is through the secure communications protocol.

4.8 Plaintext Passthrough Plaintext pass-through (hereafter referred to as “pass-through”) is a mode in which a CM allows plaintext to travel between the ciphertext port and the plaintext port or vice-versa without alteration or authentication. Pass-through can take either of two forms: 1. No messages are encrypted or decrypted. 2. Certain messages and/or message characteristics are identified. Only these messages (or messages having these characteristics) are passed through unaltered. All other messages are encrypted (or decrypted and subject to any specified authentication). An example is the selective pass-through of specific modem commands and responses. It is not mandatory for a CM to support any form of pass-through. A CM may support either form of pass-through specified above under the following conditions: 1. CMs shall be shipped with all forms of pass-through disabled. 2. Crypto-officer authorization shall be required to enable any form of pass-through. 3. Any action or event resulting in the loss of Critical Security Parameters (CSPs, which are security-related information, such as cryptographic keys, passwords, or PINs whose disclosure or modification can compromise the security of a cryptographic module) shall also cause the CM to disable all forms of plaintext pass-through. 4. When a user attempts to enable any form of pass-through, the CM or configuration software shall issue the following warning: “WARNING – ENABLING PASSTHROUGH MODE SIGNIFICANTLY INCREASES THE RISK OF UNAUTHORIZED COMMUNICATIONS ACCESS”. While the message is displayed, the user shall be required to confirm the choice. 5. The CM shall create an audit log entry noting the form of pass-through that was enabled. 6. The CM documentation shall include a complete description of all supported forms of pass-through. The above warning shall be included as part of any discussion of passthrough in the CM documentation. It is recommended that the user security policy also address the use of pass-through.



DRAFT 1


4.9 Future Directions Several important capabilities are not addressed by AGA 12-1. Further research is required, and it is hoped that vendors will share their methods of addressing these problems. In order to claim AGA 12-1 compliance, vendors shall publish complete descriptions of these methods, permit their adoption by AGA 12 and other vendors, and respond to comments posted by the AGA 12 Users Group with regard to the security and practicality of the methods. Specific areas include the following: •

Mixed mode; users are likely to desire mixing of protected and unprotected devices on a network. A CM that must communicate with both protected and unprotected devices must employ a method of securely recognizing unprotected devices and switching to pass-through mode to exchange messages with them.

•

Broadcast; many SCADA systems require the occasional transmission of messages that are intended for every device on the network, as opposed to messages that are directed to specific devices. Further, these messages are sometimes used to synchronize clocks or operations. The SLS protocol as defined does not provide a mechanism for broadcast. This is further complicated in the mixed mode system as described above.

•

Error and forensic information; for compatibility and consistency, it is desirable that AGA 12 include standard lists of explicitly defined error codes and forensic registers.

•

Management commands; for compatibility and consistency, it is desirable that AGA 12 includes a subset of explicitly defined remote management commands for functions such as key management, collection of forensic information, and enabling/disabling pass-through mode.

•

Modem pass-through; when a CM is used with a modem, it is necessary for the CM to recognize modem commands and responses and pass them through unencrypted.



DRAFT 1


5. Operational Recommendations The purpose of the section is to recommend practices that support secure operations. As has been stressed in several other places in this report, it is not sufficient to buy and install hardware and then forget entirely about security. 5.1

Commissioning –

In commissioning the cryptographic module, one permissible approach is to install modules in the plaintext mode. The cipher-text mode is then turned on all at once by a command, which may be offered as an option by the manufacturer. There may also be an in-band command to switch to the plaintext mode in case of failure or emergency. Note that it is critical to protect this command carefully, since its use disables all cryptographic protection. 5.2 Maintenance The need for maintenance and support may arise in situations in which it is desired to alter or upgrade software or to repair a malfunctioning CM. AGA 12-1 does not require the ability to upgrade firmware, but it is a recommended option. If the manufacturer does provide this feature, it shall be an option for the utility to be able to disable this capability permanently. AGA 12 will limit vendor technical support access to selected areas. This is a FIPS PUB 140-2 role. It is recommended that a SCADA or DCS operator develop a security policy statement that will cover the limits of the maintenance, cryptographic officer, user, and vendor maintenance roles. 5.3

Key management

Although AGA 12-1 does permit the use of a single symmetric session key on all units, this practice is strongly discouraged. While this single key-operating mode is somewhat more secure than plaintext operation, the compromise of the key or the loss of a single cryptographic module compromises the security of the entire system. There is concern that use of this system provides a false sense of security because while CMs are installed and appear to protect the system, though in fact the protection is relatively easy to compromise. Keys may be changed using physical access to the unit or may be changed using “in-band” key management options. For managing session keys and to provide a common operating mode for interoperability, it is recommended that •

Every device must support session key managing using a master key.

• Public key encryption may be used as an option for managing master and session keys. If public key encryption is present on the CM, it must provide RSA as a minimum. 5.4

Forensics/audit

A common minimal set of forensic counters shall be included as a requirement for AGA 12 compliance. This allows a SCADA operator to compare forensic counters among different manufacturers and to maintain a consistent forensic data set. - – 18 AGA Report 12-1, Draft 1 March 24, 2003


DRAFT 1


• • • • • • • • • • • • • •

Total messages sent, Total messages received, Total messages received with errors, CRC errors for which a vendor may provide more detail as to their origins, Hash errors for which a vendor may provide more detail as to the origins, Total session requests that the CM originated, Total session requests that the CM responded to, Total originating session request that failed for which a vendor may provide more detailed information, Total responding session requests that the CM rejected for which a vendor may provide more detailed information, Total session termination commands sent, Total session termination commands received, Total key management messages sent, Total key management messages received, and Total key management errors for which a vendor may provide more detailed information,

Prudent operation requires that these counters be examined at an interval to be set by corporate policy to determine whether there is evidence of attempts to penetrate the security of the system. These forensic counters are not sufficient in themselves to assure that attempted cyber-attacks will be detected. A system analogous to Intrusion Detection Systems could assist in this analysis. 5.5

Broadcast/multicast capabilities

While some SCADA and DCS operators expressed a strong desire for the ability for secure broadcast and/or multicast capabilities, AGA 12-1 did not include this capability. It was not feasible to develop a secure technique for this capability within the time schedule that early deployment of cryptographic retrofit protection was felt to be required. Vendors may develop such a capability and may submit the methodology to the AGA 12-1 Users' Group for possible adoption as an open standard approach.



DRAFT 1


6. Quality Recommendations Section 6 defines system requirements and constraints for deploying cryptographic protection of SCADA communications. Cryptographic modules may require configuration of communications and security parameters before beginning operations. A vendor may recommend that critical security parameters are initially entered by specially designated personnel under controlled conditions. It is important to be aware of such issues before planning or beginning deployment. Refer to the product documentation for information about initialization. During deployment of cryptographic protection, a system is likely to include some IEDs with cryptographic modules and some without. The cryptographic module vendor(s) should provide a means for the central computer(s) to communicate with both protected and unprotected IEDs.

6.1 Installation and physical access requirements A cryptographic protection scheme, especially a retrofit system, may be easily defeated through physical access. It is important to secure the protected equipment, cryptographic module, and connecting cable(s) against unauthorized access. To help protect against physical access threats, a cryptographic module may include an intrusion detection feature. Typically such a feature will erase critical security parameters if unauthorized access is detected, preventing an intruder from using the cryptographic module to gain access to the communications channel. Such a feature typically requires installation of one or more sensors connected to the cryptographic module. If the cryptographic module detects an intrusion event, communications with the protected device will probably be terminated and it will probably be necessary to visit to the site to reinitialize the critical security parameters. Refer to the manufacturer-supplied product documentation to determine whether it includes such a feature and specific information about using it.

6.1.1 Master station physical access The master station physical location should be secured from unauthorized entry. This includes the operator controls, the other master station hardware, and the termination cabinet for the communications circuits to the field devices such as remote terminal units (RTUs). The encrypting/decrypting devices on communications circuits should be installed in locked cabinets.

6.1.2 Field installation/device physical access The encrypting/decrypting devices on communications circuits should be installed in locked termination cabinets.

6.2 Environmental requirements Master stations are typically installed in office environments, with no special environmental requirements for the cryptographic hardware. Field devices, including RTUs, are typically installed in non-controlled, non-air conditioned or heated environments that are sheltered from precipitation. Depending on the location, the ambient temperature may range from –40 degrees C to +65 degrees C (-40 degrees F to + 149 degrees F) in a non-ventilated enclosure. Humidity may range from 10 to 95% non-condensing. The field cryptographic hardware should be able to operate through the expected temperature and humidity changes for the specific location. See IEEE 1613 Standard Environmental Requirements for Communications Networking Devices in Electric Power Substations.



DRAFT 1


6.3 Power requirements Power requirements are not governed by this document.

6.4 Cryptographic quality The most reliable indicator that a cryptographic module is well designed and that the actual implementation is in conformance with good practice is its being listed as conforming to the requirements of FIPS PUB 140-2 by a laboratory that is a member of the Cryptographic Module Validation Program (CMVP). Under this program, NIST accredits internationally recognized laboratories that are qualified to certify that CMs conform to Federal Information Processing Standards. This assurance includes both the specifications and the adequacy with which the specification is implemented. Obtaining a certification can take six months to a year and cost approximately %50,000 of dollars; this is not a minor investment in time, money, or effort for a manufacturer. Consequently, early products designed to comply with AGA 12-1 and FIPS PUB 140-2 will probably not be so certified, and will only be able to be measured by the extent to which they are designed to comply with FIPS PUB 140-2.

6.5 AGA 12-1 compliance In addition to the requirements of FIPS PUB 140-2, AGA 12-1 imposes other requirements. To date, no certification process has been established for compliance with AGA 12-1. In the interim period, the AGA 12-1 Users Group will provide for a limited suite of tests for compliance and will publish the results of these tests on its web site.

6.6 Interoperability among manufacturers Interoperability among CMs made by different manufacturers generally is desirable. Among other reasons, it reduces the SCADA or DCS operator risk that a particular manufacturer no longer supports a product, leaves the industry, or for any other reason leaves the system operator in a difficult situation. Interoperability also simplifies inventory and training issues, as well as leading to price competition. However, different systems have different characteristics, values, protection needs, etc, leading to a requirement for differentiated products. Ideally, products would be highly interoperable, differing only in features. The AGA 12-1 working group adopted a target of having limited interoperability. It was decided to restrict interoperability to the communications area, not the setup or configuration area. Setup is an infrequent task (theoretically, only at the start of use of a module), so incompatibilities here should not pose a major problem.



DRAFT 1


7. System Requirements Section 7 defines system requirements and constraints on cryptographic protection of SCADA communications.

7.1 External communication interfaces to the SCADA system External communication interfaces to the SCADA system include interfaces to a SCADA master in a control center, interfaces to a local SCADA master in a substation, and interfaces to an RTU in a substation, or to an RTU outside the substation (e.g., pole top RTU). The communications interfaces are typically serial asynchronous links operating over leased lines, dial-up lines, or radio links. It is now recognized that any of these links are vulnerable to cyber attack. Mitigation of this threat, where it occurs, will require a combination of encryption and authentication hardware/software on each of the vulnerable interfaces.

7.1.1 Control center communication interface requirements A SCADA master in a control center represents a repository of data used by other control center business functions. Communication access to the SCADA master should be protected from cyber-attack. •

If protection against cyber attack is provided for business functions that have access to the SCADA master, then based on a risk assessment a determination will be made to determine if cryptographic protection of this interface is required. If required, AGA Report 12 requirements defined for the cryptographic module apply.

•

Cryptographic modules implemented on these communication interfaces should not degrade the functional or performance capability of the business function that has authority to access the SCADA master.

7.1.2 Local SCADA master communication interface requirements Local SCADA masters in a substation represent a repository of data used by operational personnel to perform authorized tasks. Communication access to the local SCADA master should be protected from cyber-attack. •

Cryptographic modules implemented on these communication interfaces should not degrade the functional or performance capability of the operational function that has authority to access the local SCADA master.

•

Local Intelligent Electronic Devices (IEDs) that communicate with a local SCADA master do not require cryptographic protection over this interface.

•

Cryptographic protection of local IEDs that have communication access to the local SCADA master is outside the scope of AGA Report 12.

7.1.3 RTU communication interface requirements Remote Terminal Units (RTUs) in a substation or external to a substation represent a repository of data used by operational personnel to perform authorized tasks. Communication access to RTUs should be protected from tampering. •

Cryptographic modules implemented on these communication interfaces should not degrade the functional or performance capability of the operational function that has authority to access RTUs.



DRAFT 1


•

Local Intelligent Electronic Devices (IEDs) that communicate with RTUs do not require cryptographic protection over this interface.

•

Cryptographic protection of local IEDs that have communication access to RTUs is outside the scope of AGA Report 12.

7.2 Intrusion detection and forensics AGA Report 12 recommends that high value SCADA systems integrate an intrusion detection system (IDS) to detect cyber attacks and record the information needed to legally prosecute the attacker. A fundamental tool for intrusion detection is the audit record. AGA Report 12 recommends two plans to record the outgoing activity by users as input to IDS: Native audit records: Virtually all multi-user operating systems include accounting software that collects information on user activity. The advantage of using this information is that no additional collection software is needed. The disadvantage is that the native audit records may not contain the needed information or may not contain it in a convenient form. Detection-specific audit records: A collection facility can be implemented that generates audit records containing only that information required by IDS. One advantage of such an approach is that it could be made vendor independent and ported to a variety of systems. The disadvantage is the extra overhead involved in having, in effect, two accounting packages running on a machine. Procurement needs to incorporate the requirements derived from the utility’s firewall filtering policy into the intrusion detection filters for operation’s SCADA networks. AGA Report 12 recommends a “deny-everything-not-specifically-allowed” for this network. A “deny-everything” policy makes intrusion detection easy: Just set an alarm for violations.

7.3 Quality requirements for SCADA system’s cryptographic modules 7.3.1 Interoperability Cryptographic modules should not degrade the capability of IEDs to interoperate4 over networks on which they were designed to interoperate.

7.3.2 Scalability Cryptographic modules should not significantly degrade the scalability5 of networks designed to operate without cryptographic protection.

7.3.3 Reliability Cryptographic modules should not significantly degrade the reliability of networks designed to operate without cryptographic protection.

7.3.4 Availability Cryptographic modules should not significantly degrade the availability of networks designed to operate without cryptographic protection.

4

Interoperability requires that cryptographic modules transcend products and networks.

5

Scalability defines how capacity and load affect performance.



DRAFT 1


7.3.5 Maintainability Cryptographic modules should not significantly degrade the maintainability of networks designed to operate without cryptographic protection.

7.3.6 Flexibility and expandability Cryptographic modules should not significantly degrade the flexibility and expandability of networks designed to operate without cryptographic protection.



DRAFT 1


8. Technical References DNP Technical Bulletin 2002-x, Message Authentication Object IEEE 100: “The Authoritative Dictionary of IEEE Standards Terms”, 7th ed.: Institute of Electrical and Electronics Engineers Internet Security Glossary (RFC 2828), The Internet Society National Institute of Standards and Technology FIPS PUB 140-2 “Security Requirements for Cryptographic Modules” National Institute of Standards and Technology FIPS PUB 180-2 “Secure Hash Standard” National Institute of Standards and Technology FIPS PUB 197 “Advanced Encryption Standard” National Institute of Standards and Technology SP 800-38A “Recommendation for Block Cipher Modes of Operation”



DRAFT 1


ANNEXES



DRAFT 1


AGA 12-1 ANNEX A BIBLIOGRAPHY (Informative) REVISION 0.5

Submitted by AGA 12-1 Working Group March 19, 2003

- – A-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Bibliography Smith (1997) provides a readable introduction to the subject of cryptography applied to the Internet, with examples of commercial deployment. Much of this discussion can be applied to control systems with some modification. Since this book predates AES, visiting the AES website will provide more recent details. Schneier (1999) has a readable - but very detailed discussion of cryptography and protocols, but with little insight into how to deploy it in control systems. Menezes, et al, provide a readable discussion on the details of many areas of cryptography and attacks, but this book also pre-dates AES. NIST's FIPS PUB 140-2 provides detailed guidance on the requirements Government agencies must impose on their cryptographic modules; many private companies use the FIPS guidelines because the guidelines were developed by expert cryptographers and deemed adequate to protect Federal information. The process by which laboratories are accredited to certify Cryptographic modules is described on a NIST web site. AES Home page, http://csrd.nist.gov/CryptoToolkit/aes/ American Gas Association Report (AGA 12-1) "Cryptographic Protection of SCADA Communications" Menezes, Alfred J., van Oorschot, Paul C., and Vanstone, Scott A. (1997) Handbook of Applied Cryptography, CRC Press National Institute of Standards and Technology (NIST), Federal Information Processing Standard FIPS PUB 140-2, "Security Requirements for Cryptographic Modules" National Institute of Standards and Technology (NIST), web site at URL csrc.nist.gov/cryptval/ Schneier, Bruce (1999) Applied Cryptography: Protocols, Algorithms & Source Code in C, Addison Wesley Smith, Richard E. (1997) Internet Cryptography, Addison Wesley,

- – A-2 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


AGA 12-1 ANNEX B DEFINITION OF TERMS AND ACRONYMS (Normative) REVISION 0.5


- – B-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


GLOSSARY OF TERMS AND ACRONYMS Following each term or acronym given below is a number in parentheses that indicates the source from which the item was taken. A Glossary of Terms The following definitions are tailored for use in this standard: Access authority: An entity responsible for monitoring and granting access privileges for other authorized entities. (3) Access control: Restricts access to resources only to privileged entities. (3) Accountability: A property that ensures that the actions of an entity may be traced uniquely to that entity. (3) Approved: FIPS-Approved and/or NIST-recommended. (1) Approved mode of operation: a mode of the cryptographic module that employs only approved security functions (not to be confused with a specific mode of an Approved security function, e.g., DES CBC mode). (1) Approved security function: for this standard, a security function (e.g., cryptographic algorithm, cryptographic key management technique, or authentication technique) that is either a) specified in an Approved standard, b) adopted in an Approved standard and specified either in an annex of the Approved standard or in a document referenced by the Approved standard, or c) specified in the list of Approved security functions. (1) Archive: See Key management archive. (3) Association: A relationship for a particular purpose. For example, a key is associated with the application or process for which it will be used. (3) Asymmetric key algorithm: See Public key cryptographic algorithm. (3) Attribute authority: An entity with a signing key and the authority to create attribute certificates that bind a privilege to another certificate, usually an identity certificate (i.e., a public key certificate that binds a public key with the identity of the owner of the public key). (3) Authentication: A process that establishes the origin of information, or determines an entity’s identity. (3) During discussions, the AGA 12-1 group found that "Authentication" has two distinct meanings. One is authentication of one cryptographic module (CM) and another, simply establishing that the module is talking to the module to which it believes it is talking. The other meaning of authentication is establishing that the CM indeed is really associated with domain (i.e., user defined name) identity with which it is claimed to be associated. (7) Authentication code: a cryptographic checksum based on an Approved security function (also known as a Message Authentication Code). (1) Authorization: Access privileges granted to an entity; conveys an “official” sanction to perform a security function or activity. (3) Automated key transport: the transport of cryptographic keys, usually in encrypted form, using electronic means such as a computer network (e.g., key transport/agreement protocols). (1)



DRAFT 1


Availability: Timely, reliable access to information by authorized entities. (3) Backup: A copy of information to facilitate recovery, if necessary. (3) Bandwidth: the rate at which a data path (e.g., a channel) carries data, measured in bits per second. Bose-Chaudhuri-Hocquenghem (BCH) Code - A class of security code that is relatively simple to implement in hardware and that provides a high degree of immunity to transmission errors for a small reduction in communication efficiency. Block: a group of contiguous characters formed for transmission purposes. (2) Can: the word can, equivalent to “is able to,” is used to indicate possibility and capability, whether material or physical. (2) Certificate: See public key certificate. (3) Certification authority: The entity in a Public Key Infrastructure (PKI) that is responsible for issuing certificates, and exacting compliance to a PKI policy. (3) Cipher Block Chaining (CBC): a block cipher mode that enhances electronic codebook mode by chaining together blocks of ciphertext it produces. (5) Ciphertext: Data in its encrypted form. (3) Ciphertext port: the CM communications port connected to a protected communications link; communications on this port may be in plaintext or ciphertext. (7) Cleartext: unencrypted data without and format additions or changes, such as framing or padding. (7) Client: a station or program requesting a service. (2) Closed session: the session has been terminated and a new key is required for the next session. (7) Commissioning: the process of installing cryptographic protection on a system or portion of a system that has not been previously protected by cryptography. Compromise: the unauthorized disclosure, modification, substitution, or use of sensitive data (including plaintext cryptographic keys and other CSPs). (1) Confidentiality: the property that sensitive information is not disclosed to unauthorized individuals, entities, or processes. (1) Contingency plan: A plan that is maintained for disaster response, backup operations, and post-disaster recovery to ensure the availability of critical resources and to facilitate the continuity of operations in an emergency situation. (3) Control information: information that is entered into a cryptographic module for the purposes of directing the operation of the module. (1) Critical security parameter (CSP): security-related information (e.g., secret and private cryptographic keys, and authentication data such as passwords and PINs) whose disclosure or modification can compromise the security of a cryptographic module. (1) Cross certification: Used by one CA to certify any CA other than a CA immediately adjacent (superior or subordinate) to it in a CA hierarchy. (3) Cryptanalysis: 1. Operations performed in defeating cryptographic protection without an initial knowledge of the key employed in providing the protection. 2. The study of mathematical techniques for attempting to defeat cryptographic techniques and information system security. This includes the process of looking for errors or weaknesses in the implementation of an algorithm or of the algorithm itself.



DRAFT 1


Cryptographic boundary: an explicitly defined continuous perimeter that establishes the physical bounds of a cryptographic module and contains all the hardware, software, and/or firmware components of a cryptographic module. (1) Cryptographic key (key): a parameter used in conjunction with a cryptographic algorithm that determines 1. 2. 3. 4. 5. 6.

the transformation of plaintext data into ciphertext data, the transformation of ciphertext data into plaintext data, a digital signature computed from data, the verification of a digital signature computed from data, an authentication code computed from data, or an exchange agreement of a shared secret. (1)

Cryptographic key component (key component): One of two secret random numbers that are combined to produce a Master Key using split knowledge procedures. (7) Cryptographic module (CM): the set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation) and are contained within the cryptographic boundary. (1) Cryptographic Module Identifier (CMID): a unique number that is installed in each module by the manufacturer and cannot be reset. (7) Cryptographic module security policy: a precise specification of the security rules under which a cryptographic module will operate, including the rules derived from the requirements of this standard and additional rules imposed by the vendor. (See Annex C.) (1) Crypto officer: an operator or process (subject), acting on behalf of the operator, performing cryptographic initialization or management functions. (1) Cryptoperiod: The time span during which a specific key is authorized for use or in which the keys for a given system or application may remain in effect. (3) Cyber attack: Exploitation of the software vulnerabilities of information technology-based control components. (8) Cyclic Redundancy Check (CRC): Sometimes called "cyclic redundancy code". A type of checksum algorithm that is not a cryptographic hash but is used to implement data integrity service where accidental changes to data are expected. Data encrypting key: See data key. (3) Data key: An ephemeral key used to encrypt data.. (7) Data origin authentication: Corroborating that the source of the data is as claimed. (3) Decryption: The process of changing ciphertext into plaintext using a cryptographic algorithm and key. (3) Data path: the physical or logical route over which data passes; a physical data path may be shared by multiple logical data paths. (1) Denial-of-service (DoS): the prevention of authorized access to a system resource or the delaying of system operations and functions. (See: interruption.) (5) Differential power analysis (DPA): an analysis of the variations of the electrical power consumption of a cryptographic module, using advanced statistical methods and/or other techniques, for the purpose of extracting information correlated to cryptographic keys used in a cryptographic algorithm. (1)



DRAFT 1


Digital signature: the result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication 2. data integrity, and 3. signer non-repudiation. (1) Distributed Network Protocol Version 3.0 (DNP3): a SCADA protocol based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working group 03 , used to exchange data between RTU’s and remote control points. Distribution: See key distribution. (3) Dual control: A process that uses two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. No single entity is able to access or use the materials, e.g., cryptographic keys. (3) Eavesdropping: Listening to and understanding the content of a message. (4) Electromagnetic compatibility (EMC): the ability of electronic devices to function satisfactorily in an electromagnetic environment without introducing intolerable electromagnetic disturbances to other devices in that environment. (1) Electromagnetic interference (EMI): electromagnetic emissions from a device, equipment, or system that interfere with the normal operation of another device, equipment, or system. (1) Electronic codebook (ECB): A block cipher mode in which a plaintext block is used directly as input to the encryption algorithm and the resultant output block is used directly as ciphertext. (5) Electronic key entry: the entry of cryptographic keys into a cryptographic module using electronic methods such as a smart card or a key-loading device. (The operator of the key may have no knowledge of the value of the key being entered.) (1) Emulate: to represent a system by a model that accepts the same inputs and produces the same outputs as the system represented. For example, to emulate an 8-bit computer with a 32-bit computer. (2) Encrypted key: a cryptographic key that has been encrypted using an Approved security function with a key encrypting key, a PIN, or a password in order to disguise the value of the underlying plaintext key. (1) Encryption: The process of changing plaintext into ciphertext using a cryptographic algorithm and key. (3) Entity: An individual (person), organization, device or process. (3) Environmental failure protection (EFP): the use of features to protect against a compromise of the security of a cryptographic module due to environmental conditions or fluctuations outside of the module’s normal operating range. (1) Environmental failure testing (EFT): the use of testing to provide a reasonable assurance that the security of a cryptographic module will not be compromised by environmental conditions or fluctuations outside of the module’s normal operating range. (1) Ephemeral keys: Short-lived cryptographic keys that are statistically unique to each execution of a key establishment process (e.g., unique to each message or session). (3) Error detection code (EDC): a code computed from data and comprised of redundant bits of information designed to detect, but not correct, unintentional changes in the data. (1)



DRAFT 1


Fabrication: data or message forgery—often referred to as spoofing—based on the impersonation of one or more parties to compromise the authenticity of the communication system. Finite state model: a mathematical model of a sequential machine that is comprised of a finite set of input events, a finite set of output events, a finite set of states, a function that maps states and input to output, a function that maps states and inputs to states (a state transition function), and a specification that describes the initial state. (1) Firmware: the programs and data components of a cryptographic module that are stored in hardware (e.g., ROM, PROM, EPROM, EEPROM or FLASH) within the cryptographic boundary and cannot be dynamically written or modified during execution. (1) Hardware: the physical equipment within the cryptographic boundary used to process programs and data. (1) HMAC: A keyed hash that can be based on any iterated cryptographic hash (e.g., SHA-1), so that the cryptographic strength of HMAC depends on the properties of the selected cryptographic hash. (5) Hash function: A function that maps a bit string of arbitrary length to a fixed length bit string. Approved hash functions satisfy the following properties: 1. It is computationally infeasible to find any input that maps to any pre-specified output, and 2. It is computationally infeasible to find any two distinct inputs that map to the same output. (3) Hardware Security Module: A special CM used to generate and store key materials. The HSM is part (or in some cases all) of a Key Escrow System. Hash value: The result of applying a hash function to information. (3) Intelligent Electronic Device (IED): any device incorporating one or more processors with the capability to receive or send data/control from or to an external source (e.g., electronic multifunction meters, digital relays, controllers). (2) In-band: Changing crypt parameters over the communication link. In-band signaling: signaling applications in which the signaling information is transmitted in the same information flow as the data. (2) Informative: material included to make the content of a standard easier to understand. Initialization vector (IV): a vector used in defining the starting point of an encryption process within a cryptographic algorithm. (1) Input data: information that is entered into a cryptographic module for the purposes of transformation or computation using an Approved security function. (1) Input-output: pertaining to input, output, or both (2). Integrity: the property that sensitive data has not been modified or deleted in an unauthorized and undetected manner. (1) Interception: capture and disclosure of message contents—often referred to as sniffing—or use of traffic analysis to compromise the confidentiality about the communication system based of message destination or origin, frequency or length of transmission, and other communication attributes. Interface: a logical entry or exit point of a cryptographic module that provides access to the module for logical information flows representing physical signals. (1)



DRAFT 1


Interruption: degrading or destroying the communication links or device using message flooding, generation of invalid messages, or physical attacks on the communication system; most commonly known as denial of service (DoS) or if distributed denial of service (DDoS) if multiple attackers are involved. Key: see cryptographic key Key component: see cryptographic key component. (1) Key confirmation: a method of determining that an entity has the correct keying material. (3) Key de-registration: a stage in the lifecycle of keying material; the removal of all records of keying material that was registered by a registration authority. (3) Key distribution: the transport of a key and other keying material from an entity that either owns the key or generates the key to another entity that is intended to use the key. (3) Key Escrow System: Software, devices and procedures used to generate, store, and retrieve cryptographic keys and key materials securely for the purposes of installation, maintenance, and backup. Key encrypting key: a cryptographic key that is used for the encryption or decryption of other keys. (1) Key establishment: the process by which cryptographic keys are securely distributed among cryptographic modules using manual transport methods (e.g., key loaders), automated methods (e.g., key transport and/or key agreement protocols), or a combination of automated and manual methods (consists of key transport plus key agreement). (1) Keying material: the data (e.g., keys and IVs) necessary to establish and maintain cryptographic keying relationships. (3) Keying material installation: a stage in the lifecycle of keying material; the installation of keying material for operational use. (3) Key loader: a self-contained unit that is capable of storing at least one plaintext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module. Key management: the activities involving the handling of cryptographic keys and other related security parameters (e.g., IVs and passwords) during the entire life cycle of the keys, including their generation, storage, establishment, entry and output, and zeroization. (1) Key management archive: a stage in the lifecycle of keying material; a repository containing keying material of historical interest. (3) Key management infrastructure: the framework and services that provide for the generation, production, distribution, control, accounting, and destruction of all cryptographic material, including symmetric keys, as well as public keys and public key certificates. It includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that distributes, manages, and supports the delivery of cryptographic products and services to end users. (3) Key Management Plan: the Key Management Plan is the document that describes for a cryptographic device or application the management of all key management products and services distributed by the Key Management Infrastructure and employed by that cryptographic device or application. The Key Management Plan documents how current and/or planned key management products and services will be supplied by the Key Management Infrastructure and used by the cryptographic application to ensure that lifecycle key management support is available. (3)



DRAFT 1


Key Management Policy: the Key Management Policy is a high-level statement of organizational key management policies that identifies high-level structure, responsibilities, governing standards and guidelines, organizational dependencies and other relationships, and security policies. (3) Key management product: a key management product is a cryptographic key (symmetric or asymmetric) or certificate used for encryption, decryption, digital signature, or signature verification; and other items, such as certificate revocation lists and compromised key lists, obtained by trusted means from the same source, which validate the authenticity of keys or certificates. Software that performs either a security or cryptographic function (e.g., keying material accounting and control, random number generation, cryptographic module verification) is also considered to be a cryptographic product. (3) Key Management Practices Statement: the Key Management Practices Statement is a document or set of documentation that describes in detail the organizational structure, responsible roles, and organization rules for the functions identified in the Key Management Policy. (3) Key management service: a key management service is a function performed for an existing cryptographic product. Examples are key ordering, distribution, re-key, update of product attributes, and certificate revocation. Other cryptographic services include key recovery and the distribution, accounting, tracking, and control of software that performs either keying material security or cryptographic functions. (3) Key pair: a public key and its corresponding private key; a key pair is used with a public key algorithm. (3) Key recovery: a stage in the lifecycle of keying material; mechanisms and processes that allow authorized entities to retrieve keying material from key backup or archive. (3) Key registration: a stage in the lifecycle of keying material; the process of officially recording the keying material by a registration authority. (3) Key revocation: a stage in the lifecycle of keying material; a process whereby a notice is made available to affected entities that keying material SHOULD be removed from operational use prior to the end of the established cryptoperiod of that keying material. (3) Key Specification: a Key Specification documents the data format, encryption algorithms, hashing algorithms, signature algorithms, physical media, and data constraints for keys required by a cryptographic device and/or application. (3) Key transport system: Software, devices and procedures used to generate, store, and retrieve cryptographic keys and key materials securely for the purposes of installation, maintenance, and backup. (7) Key transport: secure transport of cryptographic keys from one cryptographic module to another module. (1) Key Transport Device: A special CM used to transport keys and key materials between an HSM and a CM or another HSM Key update: a stage in the lifecycle of keying material; alternate storage for operational keying material during its cryptoperiod. (3) Key wrapping: encrypting a symmetric key using another symmetric key (the key encrypting key). A key used for key wrapping is known as a key-encrypting key. (3) Label: information that either identifies an associated parameter or provides information regarding the parameter’s proper protection and use. (3)



DRAFT 1


LAPB: The X.25 version of HDLC, which uses peer-to-peer communication with both ends able to initiate communication on duplex links. Latency: the time it takes for a packet to cross a network connection, from sender to receiver. Man-in-the-middle: A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data in order to masquerade as one or more of the entities involved in a communication association. (5) Manual key entry: the entry of cryptographic keys into a cryptographic module, using devices such as a keyboard. (1) Master: a device that initiates communications requests to gather data or perform controls. (2) Master terminal unit: Master key: A permanent key unique to each CM, used to establish Session Establishment Keys. (7) May: the word may, equivalent to “is permitted,” is used to indicate a course of action permissible within the limits of this standard. (2) Message: an ordered series of characters used to convey information. (2) Message authentication code (MAC): Data that is associated with authenticated information that allows an entity to verify the integrity of the information. (3) Microcode: the elementary processor instructions that correspond to an executable program instruction. (1) Mixed operation: operating a distributed system with a mix of plain text and cipher text communications on the same line. (2) Modification: Intercepting a message, changing it, and passing it on so that it now requests what you want instead of what the original sender requested. (4) Must: the use of the word must is deprecated and shall not be used when stating mandatory requirements. The word must is only used to describe unavoidable situations. (2) Node: a generic term encompassing both CCs and RDs. (6) Nonce: a random or pseudo-random value used within an authentication system. (2) Non-repudiation: A service that is used to provide proof of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party as having originated from a specific entity in possession of the private key of the nominal originator. (3) Normative: requirements that are mandatory for the product or system to claim compliance.) Open session: the session has been established and communication is actively occurring. (7) Operational storage: A stage in the lifecycle of keying material; the normal storage of operational keying material during its cryptoperiod. (3) Operational use: A stage in the lifecycle of keying material; a stage whereby keying material is used for standard cryptographic purposes. (3) Operator: an individual accessing a cryptographic module or a process (subject) operating on behalf of the individual, regardless of the assumed role. (1) Output data: information that is produced from a cryptographic module. (1)



DRAFT 1


Password: a string of characters (letters, numbers, and other symbols) used to authenticate an identity or to verify access authorization. (1) Personal identification number (PIN): an alphanumeric code or password used to authenticate an identity. (1) Physical protection: the safeguarding of a cryptographic module, cryptographic keys, or CSPs using physical means. (1) Plaintext: unencrypted data with format additions or changes, such as framing or padding. (7) Plaintext key: an unencrypted cryptographic key. (1) Plaintext port: the CM communications port connected to a protected device; all communications on this port are in plaintext. (7) Port: a physical entry or exit point of a cryptographic module that provides access to the module for physical signals, represented by logical information flows (physically separated ports do not share the same physical pin or wire). (1) Private key: a cryptographic key, used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public. (1) Proof-of-possession (POP): a verification process whereby it is proven that the owner of a key pair actually has the private key associated with the public key. (3) Protection Profile: an implementation-independent set of security requirements for a category of Targets of Evaluation (TOEs) that meet specific consumer needs. (1) Pseudorandom number generator (PRNG): an algorithm that produces a sequence of bits that are uniquely determined from an initial value called a seed. The output of the PRNG “appears” to be random, i.e., the output is statistically indistinguishable from random values. A cryptographic PRNG has the additional property that the output is unpredictable, given that the seed is not known. (3) Public key: a cryptographic key used with a public key cryptographic algorithm that is uniquely associated with an entity and that may be made public. (Public keys are not considered CSPs.) (1) Public key certificate: a set of data that uniquely identifies an entity, contains the entity’s public key, and is digitally signed by a trusted party, thereby binding the public key to the entity. (1) Public key (asymmetric) cryptographic algorithm: a cryptographic algorithm that uses two related keys, a public key and a private key. The two keys have the property that deriving the private key from the public key is computationally infeasible. (1) Public Key Infrastructure (PKI): a framework that is established to issue, maintain and revoke public key certificates. (3) Public seed: A starting value for a pseudorandom number generator. The value produced by the random number generator may be made public. The public seed is often called a “salt”. (3) Random Number Generator: Random Number Generators (RNGs) used for cryptographic applications typically produce a sequence of zero and one bits that may be combined into sub-sequences or blocks of random numbers. There are two basic classes: deterministic and nondeterministic. A deterministic RNG consists of an algorithm that produces a sequence of bits from an initial value called a seed. A nondeterministic RNG produces output that is dependent on some unpredictable physical source that is outside human control. (1) Raw data: data that has not been processed or reduced from its original form. (2)

- –B-10 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Real-time system: a system in which the correctness of a computation depends not only upon the results of the computations but also upon the time at which the outputs are generated. (2) Recommended: the word recommended is used to indicate flexibility of choice with a strong preference alternative. (2) Remote device (RD): any RTU, PLC, IED, etc. that is a candidate for cryptographic protection. (6) Remote Terminal Unit: Removable cover: a cover designed to permit physical access to the contents of a cryptographic module. (1) Replay: Recording message traffic and “playing it back” to a device later in order to make it do what you want. (4) Repudiation: The ability to deny that a transaction took place (e.g., “I never performed that control) (4) Risk: an expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. (5) RSA: the public key algorithm that was developed by Rivest, Shamir, and Adleman. (3) Salt: a value that may be publicly known and is sometimes used in cryptographic processes. (3) SCADA: see supervisory control data acquisition system. Secret key: a cryptographic key, used with a secret key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. (1) Secret key (symmetric) cryptographic algorithm: a cryptographic algorithm that uses a single secret key for both encryption and decryption. (1) Secret seed: A secret value that used to initialize a pseudorandom number generator. The resulting value from the random number generator should remain secret or private. (3) Secure communication protocol: A communication protocol that provides the appropriate confidentiality, authentication and content integrity protection. (3) Secure Hash Standard (SHS): The U.S. Government standard [FP180] that specifies the Secure Hash Algorithm (SHA-1), a cryptographic hash function that produces a 160-bit output (hash result) for input data of any length < 2**64 bits. (5) Security domain: A system or subsystem that is under the authority of a single trusted authority. Security domains may be organized (e.g., hierarchically) to form larger domains. (3) Security policy: see Cryptographic module security policy. (1) Security services: Mechanisms used to provide confidentiality, data integrity, authentication or nonrepudiation of information. (3) Seed key: a secret value used to initialize a cryptographic function or operation. (1) Server: a device or computer system that is dedicated to providing specific facilities to other devices attached to the network. (2) Session: a period defined either by an amount of time, a number of messages, or a user initiated change during which two CMs operate using specific parameters. Also see Open Session, Closed session, and Suspended session. (7) Session Establishment Key: A long-lasting key used to establish secure sessions. (7)



DRAFT 1


Shall: the word shall, equivalent to "is required to", is used to indicate mandatory requirements, strictly to be followed in order to conform to the standard and from which no deviation is permitted. (2) SHA-1: See: Secure Hash Standard. Shared secret: A value that is generated during a key agreement process; the shared secret is typically used to derive keying material for a symmetric key algorithm. (3) Should: the word should, equivalent to “is recommended that,” is used to indicate• Among several possibilities one is recommended as particularly suitable, without mentioning or excluding other. • That a certain course of action is preferred but not required. • That (in the negative form) a certain course of action is deprecated but not prohibited. (2) Signature generation: Uses a digital signature algorithm and a private key to generate a digital signature on data. (3) Signature verification: Uses a digital signature algorithm and a public key to verify a digital signature. (3) Simple power analysis (SPA): a direct (primarily visual) analysis of patterns of instruction execution (or execution of individual instructions), obtained through monitoring the variations in electrical power consumption of a cryptographic module, for the purpose of revealing the features and implementations of cryptographic algorithms and subsequently the values of cryptographic keys. (1) Slave: a device that gathers data or performs control operations in response to requests from the master, and sends response messages in return. A slave device may also generate unsolicited responses. (2) Sniffing: see Interception. Software: the programs and data components within the cryptographic boundary, usually stored on erasable media (e.g., disk) that can be dynamically written and modified during execution. (1) Split key: A cryptographic key that is divided into two or more separate data items that individually convey no knowledge of the whole key that results from combining the items. (5) Split knowledge: a process by which a cryptographic key is split into multiple key components, individually sharing no knowledge of the original key, that can be subsequently input into, or output from, a cryptographic module by separate entities and combined to recreate the original cryptographic key. (1) Spoof: Pretending to be an authorized user and performing an unauthorized action. (4) Static keys: Static keys are relatively long-lived and are common to a number of executions of a given algorithm. (3) Statistically unique: For the generation of n-bit quantities, the probability of two values repeating is less than or equal to the probability of two n-bit random quantities repeating. Thus, an element chosen from a finite set of 2n elements is said to be statistically unique if the process that governs the selection of this element provides a guarantee that for any integer L≤2n the probability that all of the first L selected elements are different is no smaller than the probability of this happening when the elements are drawn uniformly at random from the set. (3) Status information: information that is output from a cryptographic module for the purposes of indicating certain operational characteristics or states of the module. (1) Supervisory Control Data Acquisition System (SCADA): a system operating with coded signals over communication channels so as to provide control of remote equipment (using typically one communication channel per remote station). The supervisory system may be combined with a data



DRAFT 1


acquisition system, by adding the use of coded signals over communication channels to acquire information about the status of the remote equipment for display or for recording functions (2) Suspended session: the open session is on a link that is not being used. (7) Symmetric key: A single cryptographic key that is used with a secret (symmetric) key algorithm. (3) Symmetric key algorithm: See Secret key cryptographic algorithm. (3) System software: the special software within the cryptographic boundary (e.g., operating system, compilers or utility programs) designed for a specific computer system or family of computer systems to facilitate the operation and maintenance of the computer system, and associated programs, and data. (1) System initialization: A stage in the lifecycle of keying material; setting up and configuring a system for secure operation. (3) Tamper detection: the automatic determination by a cryptographic module that an attempt has been made to compromise the physical security of the module. (1) Tamper evidence: the external indication that an attempt has been made to compromise the physical security of a cryptographic module. (The evidence of the tamper attempt should be observable by an operator subsequent to the attempt.) (1) Tamper response: the automatic action taken by a cryptographic module when a tamper detection has occurred (the minimum response action is the zeroization of plaintext keys and CSPs). (1) Target of Evaluation (TOE): an information technology product or system and associated administrator and user guidance documentation that is the subject of an evaluation. (1) TEMPEST: a name referring to the investigation, study, and control of unintentional compromising emanations from telecommunications and automated information systems equipment. (1) Threat: Any circumstance or event with the potential to adversely impact a system through unauthorized access, destruction, disclosure, and modification of data or denial of service. (3) Throughput: the total capability of equipment to process or transmit data during a specified time period. (2) TOE Security Functions (TSF): used in the Common Criteria, a set of the TOE consisting of all hardware, software, and firmware that must be relied upon for the correct enforcement of the TOE Security Policy. (1) TOE Security Policy (TSP): used in the Common Criteria, a set of rules that regulate how assets are managed, protected, and distributed within a Target of Evaluation. (1) Traffic analysis: Listening to messages, and without understanding their content, inferring information from the fact that certain messages are always sent when certain real-life events happen (e.g., closing a breaker). (4) Trusted path: a means by which an operator and a TOE Security Function can communicate with the necessary confidence to support the TOE Security Policy. (1) Unauthorized disclosure: An event involving the exposure of information to entities not authorized access to the information. (3) User: an individual or a process (subject) acting on behalf of the individual that accesses a cryptographic module in order to obtain cryptographic services. (1) User initialization: A stage in the lifecycle of keying material; the process whereby a user initializes its cryptographic application (e.g., installing and initializing software and hardware). (3)



DRAFT 1


User option: an option that a vendor has provided and that a user may or may not configure to operate. (7) User registration: A stage in the lifecycle of keying material; a process whereby an entity becomes a member of a security domain. (3) Validation authorities: NIST and CSE. (1) Vendor option: an option that a vendor may or may not offer on a product. (7) Vulnerability: A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (5) Wiretapping: An attack that intercepts and accesses data and other information contained in a flow in a communication system. (5) X.25: The X.25 protocol, adopted as a standard by the Consultative Committee for International Telegraph and Telephone (CCITT), is a commonly used network protocol. The X.25 protocol allows computers on different public networks (such as CompuServe, Tymnet, or a TCP/IP network) to communicate through an intermediary computer at the network layer level. X.25's protocols correspond closely to the data-link and physical-layer protocols defined in the Open Systems Interconnection (OSI) communication model. X.509 certificate: The ISO/ITU-T X.509 standard defined two types of certificates – the X.509 public key certificate, and the X.509 attribute certificate. Most commonly (including this document), an X.509 certificate refers to the X.509 public key certificate. X.509 public key certificate: The public keys for a user (or device) and a name for the user (or device), together with some other information, rendered unforgeable by the digital signature of the certification authority that issued the certificate, encoded in the format defined in the ISO/ITU-T X.509 standard. Zeroization: a method of erasing electronically stored data, cryptographic keys, and CSPs by altering or deleting the contents of the data storage to prevent recovery of the data. (1) B Acronyms The following acronyms and abbreviations are used throughout this standard:

AES Advanced Encryption Standard specified in FIPS PUB 197. (3) AGA American Gas Association ANSI American National Standards Institute (1) API Application Program Interface (1) BCH Bose-Chaudhuri-Hocquenghem Code CA Certification Authority (3) CAPP Controlled Access Protection Profile (1) CBC Cipher Block Chaining (1) CC Common Criteria (1) CIO Chief Information Officer (3) CKL Compromised Key List (3) CM Cryptographic Module (1) CMID Cryptographic Module Identifier (7) CMVP Cryptographic Module Validation Program (1) CN Client Node (3) CRC Cyclic Redundancy Check (3) - –B-14 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


CRL Certificate Revocation List (3) CSE Communications Security Establishment of the Government of Canada (1) CSN Central Service Node (3) CSP Critical Security Parameter (1) CSTP Cryptographic System Test Plan DCS Distributed Control System DDoS Distributed Denial of Service DEK Data Encryption Key (3) DES Data Encryption Standard (1) DKT Key Transport Device DNP3 Distributed Network Protocol version 3.0 DOD Department of Defense (1) DoS Denial of Service DPA Differential Power Analysis (1) DSA Digital Signature Algorithm specified in FIPS PUB 186-2. (3) DTR Derived Test Requirements (1) EAL Common Criteria Evaluation Assurance Level (1) ECB Electronic Codebook (5) ECDSA Elliptic Curve Digital Signature Algorithm (3) EDC Error Detection Code (1) EEPROM Electronically-Erasable Programmable Read-Only Memory (1) EFP Environmental Failure Protection (1) EFT Environmental Failure Testing (1) EMC Electromagnetic Compatibility (1) EMI Electromagnetic Interference (1) EPROM Erasable Programmable Read-Only Memory (1) FCC Federal Communications Commission (1) FIPS Federal Information Processing Standard (1) FIPS PUB FIPS Publication (1) GUI Graphical User Interface HDL Hardware Description Language (1) HMAC Hash-Based Message Authentication Code (1) HSM Hardware Security Module IC Integrated Circuit (1) IED Intelligent Electronic Device (2) IG Implementation Guidance (1) ISO International Organization for Standardization (1) ITSEC Information Technology Security Evaluation Criteria (1) IV Initialization Vector (1) KAT Known Answer Test KEK Key Encrypting Key (3) KD Data Key KE Session Establishment Key KM Master Key KMI Key Management Infrastructure (3) KMP Key Management Policy (3) - –B-15 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


KMPS Key Management Practices Statement (3) LAN Local Area Network (3) MAC Message Authentication Code (3) MCT Monte Carlo Test MPH Messages Per Hour MTU Master Terminal Unit NIST National Institute of Standards and Technology (1) NTIS National Technical Information Service (1) OMB Office of Management and Budget (3) PIN Personal Identification Number (1) PKI Public Key Infrastructure (3) PLC Programmable Logic Controller POP Proof-of-Possession (3) PRNG Pseudorandom Number Generator (3) PROM Programmable Read-Only Memory (1) PSN Production Service Node (3) PSRN Primary Services Node (3) RTU Remote Terminal Unit RA Registration Authority (3) RAM Random Access Memory (1) RD Remote Device (6) RNG Random Number Generator (1) ROM Read-Only Memory (1) RTU Remote Terminal Unit (2) SCADA Supervisory Control Data Acquisition System (2) SHS Secure Hash Standard (5) SPA Simple Power Analysis (1) TDES Triple Data Encryption Standard; Triple DES (3) TOE Target of Evaluation (1) TSF Target of Evaluation Security Functions (1) TSP Target of Evaluation Security Policy (1) URL Uniform Resource Locator (1) Sources for definitions and acronyms:

(1) FIPS PUB 140-2, (2001) “SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES”, Section 2, Glossary of terms and acronyms, National Institute of Standards and Technology. (2) IEEE 100: The Authoritative Dictionary of IEEE Standards Terms”, 7th ed.: Institute of Electrical and Electronics Engineers. (3) Glossary provided by Bill Burr, NIST (4) DNP Technical Bulletin 2002-x, Message Authentication Object (5)Internet Security Glossary (RFC2828), The Internet Society. (6)Clay Weston (7)AGA 12-1 Committee - –B-16 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


AGA 12-1 ANNEX C “SCADA FOR DUMMIES” (Informative) REVISION 0.5

Submitted by AGA 12-1 Working Group February 28, 2003

- – C-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Businesses have always been faced with the need to monitor and control continuous processes, both large and small. In most simple cases this means the process is equipped with some kind of instrumentation for monitoring and some kind of actuating (executing) device for control. Using these tools the local or remote operators can control the process for which they are responsible and keep it running 24 hours a day, 7 days a week. Supervisory Control And Data Acquisition (SCADA6) systems were developed to reduce labor costs, and allow system-wide monitoring and remote control from a central location. At each remote site, an RTU (Remote Terminal Unit) is connected by local wiring to the field devices to be controlled and monitored. The RTU also has a communication port, which is used to communicate with the control center over a communication link. The communication link can be dial up phone, leased line, spread spectrum radio, etc. depending on cost and availability. Using the communication links from the control center, an operator can thus monitor and control many field installations using SCADA. SCADA systems have been in place since the 1930s. They have an operational life cycle on the order of 30 years. Most SCADA communications in this installed base operate at very low speeds - on the order of 300 bps to 9600 bps. SCADA equipment at the field sites has to operate with very high reliability in a hostile environment; e.g., extreme temperature ranges. These systems were designed and installed at a time when there was little concern for communication security. The environmental characteristics of SCADA field sites (electric utility transmission and distribution substations, gas gate stations and pressure reducing stations, pump stations, and pole-top field devices) are not further addressed in this annex.

C. 1 Characteristics of SCADA SCADA functions include data acquisition, monitoring and event processing, control functions, disturbance data collection and analysis, and reports and calculations7. SCADA systems are implemented as distributed process control systems that operate on the order of seconds or 10’s of seconds depending on their primary role. Real time control and protection of equipment at the remote site is a local requirement (and requires response in the order of milliseconds in some cases); it is not a SCADA requirement.

C.1.1. Data acquisition The basic information with regard to gas, electric, water, waste water, pipeline transmission and distribution operations is collected by field instruments and control devices located at sites remote from the operator’s control center. Data may also be entered manually or calculated, and are treated exactly like the automatically collected data. For instance, the operator can enter data from passive systems without data acquisition equipment after the data is received by telephone, fax, or some other report.

C.1.1.1. Status indications The status of field devices, alarm signals, and other signals is represented by means of “status indication.” These status indications are contact closings connected to digital input boards in the RTU. Normally there are both single (1-bit) and double (2-bit) status indications. Double bit indications are used for two-state devices where one bit represents a CLOSED position contact and other bit an OPEN position contact. This facilitates detection of false (“00”) and intermediate values; e.g., “00” combinations. There may also 6

Pronounced "SKAY da"

7

The characteristics of SCADA are based on material presented in the book “Power System Control Technology” by Torsten Cegrell, 1986 Prentice-Hall International (UK) Ltd. The concepts presented have been modified to be applicable to gas, water, waste water, and pipeline process control applications.



DRAFT 1


be 3 bit status indications where the third bit indicates if there has been fast CLOSED-OPEN-CLOSED sequence of status changes between the scans, such as with automatic reclosing of circuit breakers. Status indications are normally transmitted from RTUs on the next status scan request. There is also a complete scan at start-up and restart of the control system. Some control systems have other scanning schemes implemented.

C. 1.1.2. Measured values Measured values of various inputs are collected by the RTUs. Two types of values are normally collected: •

Analog values, transformed via an analog/digital (A/D) converter to a binary format

•

Digitally coded values, also in binary format.

The binary formatted values are sent to the control center, usually on each scan of the RTU of analog inputs. The values also need to be scaled into engineering format before being presented to an operator on a graphical user interface (GUI) or used in an application program. Scaling is generally linear, but sometimes non-linear scaling is required. Scaling is commonly implemented as a function of the front-end processor (FEP) at the Control Center. The FEP does the scaling as the values are received, and the scaled values are then stored in the database. In some systems, the values are scaled when they are retrieved from the database and not when they are stored. Scanning of measured values is done either cyclically, or on a report by exception basis, where individual dead-bands are set for each measuring point and transmission occurs when the value has changed more than the dead-band since the last report. The latter method is typically used to reduce communication channel loading. It also involves a cyclic scan at startup or restart. Dead-bands can be stored centrally and transferred at start-up to the RTUs, and when the operator or control system engineer changes them.

C.1.2. Monitoring and event processing Acquired process control data is automatically monitored to ensure that measured and calculated values lie within permissible limits. The measured values are monitored with regard to rate-of-change and for continuous trend monitoring. They are also recorded for post-fault analysis. Status indications are monitored with regard to changes, and time tagged by the RTU. Monitoring these data may have various objectives and of course differs between different data. If the monitoring detects a violation of limits and changes of status indications, event processing reports such events to the operators.

C.1.2.1. Status monitoring Each status indication is compared with the previous value stored in the database. An event is generated when the status changes. The status is usually monitored against a pre-set “normal” status, thus creating a normal/off-normal operation state (of the device), which can be presented to the operator. The reporting of status changes can be delayed by a number of seconds. This is useful for suppressing transient alarm signals and temporary intermediate positions of two-state devices. Special delaying schemes are also often implemented, for instance to detect automatic reclosure operations by combining electric circuit breaker changes and status signals for the automatic equipment itself. In the case of a successful reclosure of local automatic equipment, alarms are suppressed.



DRAFT 1


C.1.2.2. Limit value monitoring Each measured value can often be monitored against a set of limit values. Limits can be introduced on both sides of a typical, or reasonable, value. This value may correspond to the physical quantity or the normal zone of that physical value. Some possible reasons for their existence are: •

Upper and lower reasonable limits which are used for specifying a range where a reasonable value should appear. If the limit is violated, there is a failure in the control system itself.

•

Upper and lower alarm limits used to specify operating limitations. Violation of an alarm limit normally results in an alarm message to the operator.

•

Upper and lower warning limits used to alert the operator, enabling intervention before an alarm limit is exceeded.

•

Zero value limit, used to specify a dead-band around the zero value. A value inside the zero dead-band can then be regarded as zero, not making the violation subject to event processing.

There are various solutions for implementing limit value monitoring. It can be implemented at the control center or remotely. The more advanced remote data collection schemes always use limit value monitoring. When implemented in the control center, the monitoring is usually carried out in connection with updating values in the database. The limit values are specified individually for each measuring point and can be change by the operator at the GUI. When limit value monitoring is performed remotely, the new limits are transferred to the RTU via the SCADA communication network.

C.1.2.3. Trend monitoring There are many types of monitoring of trends in measured values. Some possibilities are: •

Rate-of-change detection for trend detection

•

Presentation of values in curve displays. This is often combined with some sort of algorithm for extrapolation; e.g., load forecasting and trends for levels of water reservoirs.

C.1.2.4. Data quality attributes All data collection and monitoring functions normally result in a set of status flags associated with the individual data. These flags constitute data quality attributes associated with the individual data as they are presented to the operator. Some commonly used data quality attributes are blocked for updating, blocked, substituted, manually entered, out of limit (reasonable/alarm/warning/zero), alarm state, and unacknowledged.

C.1.2.5. Alarm processing At remote sites, automatic (non operator initiated) changes may occur on critical pieces of equipment. These changes of state are detected by the master station during the next systems scan, and are immediately presented to the operator as alarms on the graphical user interface (GUI), and logged with a time tag of when the event occurred. In the case of a major disruption many alarms may be generated in rapid sequence. The operator’s GUI only presents them all as alarms. In some more advanced SCADA systems, alarm-processing software may be employed to establish the root cause of the incident.

C.1.3. Control functions Control functions are grouped into four subclasses: individual device control, control messages to regulating equipment, sequential control schemes, and automatic control schemes.



DRAFT 1


C.1.3.1. Individual device control Executing ON/OFF, START/STOP, or TRIP/CLOSE commands are used to control simple on/off devices.

C.1.3.2. Messages to regulating equipment Transmission of messages to regulating equipment represents a more advanced control function, and is performed on an as-needed basis. Applications include RAISE/LOWER regulation and set point adjustment. As an example of RAISE/LOWER control, the operator selects the control point of a regulating valve controlled by an RTU and issues a single RAISE or LOWER command, which will incrementally raise or lower the flow. The operator observes the change of flow in the analog value, and issues another command if additional change is needed. In the case of set point regulation, the operator sends a new set point to an RTU control function. The new value is checked against predetermined limits, to prevent abnormal values from being entered. The RTU responds with the new set point, which it has implemented.

C.1.3.3. Sequential control schemes Sequential control means that a series of correlated individual control commands are executed. Sequential control schemes are designed to permit a sequence of such control commands to be executed automatically in predefined order, including suitable logical checks and time delays. Typically, only one operator command is required to initiate the control sequence.

C.1.3.4. Automatic control schemes Automatically initiated commands are represented by closed control loops.

C.2. SCADA communication systems SCADA is always implemented as a distributed process control system. Data acquisition and control are performed by remote terminal units (RTUs), and by field devices that include functions for communications or signaling.

C.2.1. Dedicated communication channel configurations Dedicated communication channel configurations may be implemented in any of several arrangements as shown in Figures 1 through 4. The equipment shown in the control center is a simple example. The operator and engineer displays are interfaced to a “master station. And, the master station is interfaced to a front-end processor (FEP), which is then connected to communication modems, one for every dedicated communication channel. Some smaller control systems combine the FEP with the master station. Others incorporate the display system in workstations that include the master station and FEP functions. The point-to-point configuration (Figure 1) is functionally the simplest type; however, the method is rather expensive as a unique channel as well as separate communication equipment is necessary for each line. In a series configuration (Figure 2), a number of RTUs or field devices share the same channel. This has an impact on the efficiency and complexity of SCADA operations. In the series star configuration (Figure 3) several channels are concentrated on one RTU. In the multi-drop or party line configuration (Figure 4), the control center master station is connected to more than one RTU by one common path. Figure 4 also shows in the configuration that a multi-drop may include a splitter so that two or more RTUs can share a single modem.



DRAFT 1


These basic configurations can be combined into more complex communication networks. Beyond the basic components mentioned, it would be possible to use dedicated communication computers to handle communication exchange, message switching, buffering of messages, etc.

Figure 1 – SCADA system can be configured point-to-point



DRAFT 1


Figure 2 – SCADA systems can include RTUs connected in series

Figure 3 – SCADA systems can include RTUs connected in a series-star architecture



DRAFT 1


Figure 4 – SCADA system with RTUs in a multi-drop architecture

C.2.2. Native communication protocols Different principles were described above to establish communication between two entities – a sender and a receiver of data. All these fundamentals are parts of rules, which make the two entities able to understand each other. A set of rules defining a communication procedure is called a communication protocol. Without a communication protocol the two entities would not be able to understand each other; they will not agree upon how to start and maintain a dialogue. A communication protocol defines for example: The structure of messages Dialog rules and acknowledgement procedures Establishment of error detection and correction Recovery rules

C.2.3. Communication links A communication link is that part of the communication system used to connect two pieces of equipment that are going to communicate with each other. The link is the path for the movement of data. Typical communication links used for SCADA include leased lines, dial up phone lines radio, microwave, and satellite. Figure 5 shows some of the ways to communicate between equipment used to control gas or electricity transmission. Gas transmission RTUs are located in gate stations where gas pressure is reduced and gas is distributed to customers. Electricity transmission RTUs are located in transmission substations, which are part of a complex grid network. After lowering the voltage, electricity is distributed to customers through



DRAFT 1


the distribution system that include RTUs in distribution substations. Analogous systems can be described for water, wastewater, and other pipeline systems.

Figure 5 - Example Communication links

Figure 5 shows that each control center can be configured so that the FEP communication is through a modem or includes a WAN card if SCADA communication is over the enterprise wide area network (WAN). A remote access computer can communicate over the enterprise WAN, or over the public switched telephone network (PSTN) using a dial-up modem. RTUs and other intelligent electronic devices (IEDs) may also include WAN cards for communications. If the PSTN is shared, at each remote site an auto-answer modem and port switch8 is needed to communicate with the RTU or IED.

8

A port switch is only needed if the port is shared.



DRAFT 1


AGA 12-1 ANNEX D PROTECTING SCADA COMMUNICATIONS (Informative) REVISION 0.5


- – E-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


SCADA systems have a unique set of technical and operational characteristics that impact the types of threats and vulnerabilities that can be addressed by cryptography. This section discusses these characteristics, lists potential assailants and attack methods, and identifies how cryptography can and cannot be used to secure SCADA communication links.

D.1

Characteristics of SCADA Communication Systems

SCADA communication systems can be attacked through their communication links. Figures 1 through 4 illustrate common SCADA communication architectures as they are configured when protected with link encryptor cryptographic modules. Note that in each case, the cryptographic module is located between the modem and the computer to which it is attached.

Figure 1 - Cryptographic modules protecting a point-to-point architecture.



DRAFT 1


Figure 2 - Cryptographic modules protecting RTUs connected in series



DRAFT 1


Figure 3 - Cryptographic modules protecting RTUs connected in a multi-drop architecture

Figure 4 - Cryptographic modules protecting RTUs connected in a series-star architecture - – E-4 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


D.1.1 SCADA Communications Security Issues As discussed in Annex C, SCADA information typically travels over exposed communications links, and often there are multiple means of accessing the SCADA system or facility (such as backup communication links and direct links to IEDs or other components). Existing SCADA communication security measures range from weak to nonexistent. SCADA messages are rarely encrypted and passwords, when used, can be easily intercepted. Tapping the links allows message traffic to be easily interpreted, whether or not proprietary protocols are used. D.1.2. Technical Characteristics of SCADA Communication Systems These are the typical technical characteristics of SCADA communication systems related to cryptographic protection. • •

• • •

• • •

Low speed communications (300-19,200 bps) are typically used. Lengthy authentication processes or excessive overhead introduced by cryptographic protection may cause the SCADA system to report a failure of the communications link. Many SCADA systems generally use poll response messaging where the poll is short (less that 16 bytes) and responses have variable lengths (from tens of bytes to tens of kilobytes). The number of bytes that cryptographic integrity protection adds to each message thus becomes a significant factor in overhead. Many messages are the same (such as poll messages) making it relatively easy to guess the content of messages. Links are often subject to high noise levels, especially radio. Most SCADA systems use error detection and retransmission schemes. CRC-16 and Bose-Chaudhuri-Hocquenghem (BCH) are commonly used for error detection. Some systems also allow for unsolicited reporting from remote units. Some common SCADA protocols use inter-character delays to identify message boundaries. The cryptographic protection must preserve these delays and must not introduce inappropriate inter-character delays. Most SCADA protocols use timeouts to detect transmission failures, and typically will retransmit unacknowledged messages one or more times. The cryptographic protection must not add delays that cause message turnaround times to exceed the timeout periods, or the SCADA operator must increase the timeouts to accommodate cryptographic protection. Communications channels may be heavily utilized. The overhead or latency introduced by cryptographic protection may prevent the system from completing poll cycles in the allocated time. In some cases performance may be degraded to unacceptable levels. Some SCADA systems permit broadcast or multicast messages in which one computer simultaneously sends the same message to several or all other computers in the system. A few systems allow one remote to communicate with another without routing the communication through a central computer.



DRAFT 1


D.2

Threats

An analysis of potential threats to SCADA systems is necessary for this discussion. A short list of potential assailants, their technical capabilities of doing harm, and possible attacks will provide a few illustrative examples of how the threats can arise. This section first illustrates a few assailants and possible attacks. This section discusses a general set of threats that were considered in the development of AGA 12-1. D.2.1 Potential Assailants and Capabilities Our analysis assumes an intentional human threat ranging from highly unstructured (a lone “script kiddy” launching attacks from home against targets about which he knows little to nothing) to the most structured (a nation state with an advanced information warfare capability and with almost unrestricted funding.) Along this continuum, threat agents can include: ! Hackers, crackers, protesters, activists ! Employees and former employees of the system operator, vendors, customers, and contractors ! Business competitors or market traders ! Domestic or foreign activists or terrorists ! Foreign governments ! Combinations of the above D.2.2 Methods of Cyber-Attack This section focuses on the non-physical methods of attacking SCADA communication systems. Although threat agents may have a variety of political, psychological, or economic motives, at the lowest level, their objectives can be classified as attempts to gain unauthorized access, to steal service, or to destroy/degrade information, equipment, or communication capabilities. Adversaries have a variety of techniques at their disposal to achieve the objectives of an attack against a communication link. Non-physical attacks include: ! ! ! !

Interception of traffic Fabrication (forging) of messages Modification of message traffic Interruption of connectivity or service

Attacks may also be classified as passive (interception) or active (fabrication, modification, or interruption) and may be combined to conduct more sophisticated attacks that result in greater damage to the system. For example, replay attacks involve both interception and fabrication. Man-in-the-middle attacks combine interception, fabrication, and modification of message where a third party impersonates the sender and receiver, altering traffic at will. Hijacking attacks are frequently used to take control of communication channels after a user authentication.



DRAFT 1


Attacks may be conducted at multiple protocol layers. Obviously, cryptographic methods cannot provide protection against direct physical attack. D.2.3 SCADA Risks A capable assailant (a "threat agent") combined with a SCADA vulnerability creates a risk for a SCADA asset. Risks that have been identified include: ! Loss of system control that causes economic damage or injury to people or reputation ! Misuse or alteration of control settings to cause damage or injury ! Physical or economic attacks that are made more effective by virtue of information interception ! Exploitation of implementation flaws or improperly configured systems to gain unauthorized access to devices or conduct a denial of service

D.3

Scope of Protection

Cryptographic protection substantially increases the difficulty for a potential attacker to exploit the identified vulnerabilities. This section addresses the scope of protection in two ways: it first identifies what is being protected and then identifies the cryptographic techniques that provide the protection. Attacks not addressed are also described. D.3.1. Scope of What is Being Protected Following the recommendations in this document will provide cryptographic protection to SCADA systems whose data passes through asynchronous serial data links. Public switched telephone networks, leased lines, proprietary wire lines and wireless communication are addressed. Recommendations included in this report also apply to other remote access pathways (such as substation protection device configuration ports) and some Distributed Control Systems (DCS). D.3.2. Scope of Protection Technology An affordable retrofit solution, which can be implemented by inserting cryptographic modules at each end of the communication link, is recommended, as shown in Figures 1 through 4. This specification does not address modification of software or hardware in existing SCADA systems, but does define operating parameters needed to use the cryptographic system. D.3.3. Attacks Not Addressed It is important to recognize that deployment of cryptography will not protect against all possible attacks against SCADA communication networks. Specifically, following AGA 12 recommendations will not protect against the following identified threats to SCADA communications: - – E-7 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


! Physical destruction of SCADA system components ! Attacks on master control or other central computer systems via non-SCADA communication links ! Harmful actions performed by authorized personnel ! Some forms of denial of service ! Connections to SCADA systems on the “clear” side of the link encryptors.

D.4

Mapping SCADA Threats to Recommended Protection

This section compares the threats with the corresponding recommended protection against the threat. It begins by addressing the basic assumptions that are required for secure operation of the network with the installed protection. Next, the discussion focuses on the capabilities of the recommended cryptographic system and how they relate to the threat. For the purposes of this Annex, protocol requirements are discussed only in general terms. Detailed discussions of the criteria used to select the cryptographic and communication protocols are included as Annex F and a proposed protocol is included as Annex K. D.4.1 Underlying Assumptions For the purposes of developing this document, the following assumptions were made relative to the overall security posture of the system. The communication link is accessible at some point. This is a conservative assumption, since if the link is actually protected or inaccessible, assailants may not be able to attack the SCADA communication network. ! The practices in this document will be primarily used to retrofit equipment using asynchronous serial communications. For example, most RTUs connect to radios or modems using RS-232, RS-485, or similar asynchronous interfaces. ! Management has and enforces policies that ensure sound operational practices on the SCADA communication network. Ideally, the SCADA security policies are a part of a much larger, coherent strategic security policy for the entire company. ! Security through obscurity is not adequate protection. Even proprietary binary protocols are often widely known, and are subject to disclosure and analysis. A determined attacker can find phone numbers or frequencies, tap phone lines, and decode spread spectrum sequences. Proprietary organization of information such as I/O mapping and scaling is also subject to disclosure and analysis.



DRAFT 1


D.4.2 How AGA-12 Addresses Likely Attacks Protection Mechanism AES-CBC Shared Secret (Master Key) Unique Identifier (CMID) Session Counter Protocol Error Checking (CRC) MAC Digital Certificates (Public Key) Tamper Indication FIPS PUB 140-2

Interception Fabrication Alteration Disruption Message Session Key Replay Replay Extraction X

X X

X

X X

X

X X X

X X X

The column headings are possible methods of attach and he row headings are possible security methods recommended in this attack. An "X" in the cell indicates that the security mechanism mitigates the method of attack. . In general, various types of protection are as follows: ! Integrity: several levels are provided. At the lowest levels, CRC error checking is the only protection. This level is used when the communications link cannot support the overhead and latency introduced by strong integrity checking. It is recognized that this does not constitute cryptographic integrity checking. It is not intended to protect against cryptanalytical attacks. At the highest levels, 64-bit or 128-bit message authentication codes are used. ! Confidentiality: provided by AES encryption operating in CBC mode. ! Prevention of block insertion, deletion, and reordering: CBC mode ensures that the message will be garbled if any of these attacks occur. The garbled message will be detected by the native protocol error checking (in minimal protection mode) or by error/integrity checking built into the cryptographic protocol. ! Prevention of message replay: The last encrypted block of the last successful message is used as the initial vector for each message. A replayed message will be out of sequence and thus will be garbled. ! Prevention of session replay: an optional timer or message counter can be used when session replay is a risk. ! Authentication: retrofit modules can only authenticate themselves, not the devices they protect. Given this limitation, several methods are available. At the lowest level, the shared secret key provides some assurance. Each module includes a unique identification - – E-9 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


code that can be used for further assurance. The option for public key cryptography provides additional stronger options.

- –E-10 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


AGA 12-1 ANNEX E “CRYPTOGRAPHY FOR DUMMIES” (Informative) REVISION 0.5

Submitted by AGA 12-1 Working Group January 7, 2003



DRAFT 1


Annex E will familiarize the reader with some of the important terms and concepts of cryptography in general and symmetric or one-key cryptography in specific. Symmetric cryptography is the classical genre of cryptography in which the sender and the recipient both have, a priori, a common secret quantity. It is the use of this a priori secret quantity in developing a secure functioning cryptographic system that is the focus of symmetric cryptography9. If the reader is not familiar with the threats that must be countered by cryptographic protection, then it is recommended that the reader should first read AGA 12-1-Annex D.

E.1 First considerations Cryptography provides several benefits but is performed primarily for message privacy and authentication. Encryption provides message privacy by rendering information unreadable to anyone but the intended recipient(s). Authentication, as applied to persons or devices, seeks to ensure that a message has been sent by a known party or device. Integrity checking can also be applied to the contents of a message where encryption is used to ensure any alteration of the contents of a message in transit can be detected. Plaintext is text presumed understandable to anyone who should view it10. Encryption changes plaintext to ciphertext, text that is not interpretable by any unauthorized person who should happen to see it. A cryptographic algorithm is the set of rules used to transform the plain text into ciphertext11. Consider for example a simple plaintext/ciphertext alphabet pair, where DOG in plaintext is GRJ in ciphertext12. The cryptographic algorithm substitutes, letter-for-letter, an agreed-onciphertext letter for each plaintext letter. In an elementary way, three ingredients one needs to operate a cryptographic system are: the cryptographic algorithm, the keying variable, and the plaintext from the sender. With these it is possible to generate the ciphertext for the recipient. Theoretically, to decipher a secure system, one must know each of these three elements; although a standard assumption is that the adversary knows everything except the keying variable. However, don’t be complacent – keep in mind the following tenets: •

The fact that a cryptographic principle has a large number of keying variables does not, in itself, guarantee that the cryptographic principle is a good choice for building a secure cryptographic system.

•

The fact that a cryptographic principle is complex does not, in itself, guarantee that the cryptographic principle is a good choice for building a cryptographic system.

9

Annex E is based on the book “Cryptography Demystified” by John E. Hershey, McGraw-Hill TELECOM 2003. The basic terms and concepts described by Hershey have been tailored for AGA 12-1 application.

10

A message containing a string of binary numbers (all ones and zeros) is also called plaintext.

11

Many algorithms use a keying variable to establish how the plaintext is transformed into ciphertext.

12

This is commonly known as the “Caesar Cipher” or an extension of the Caesar Cipher, which is discussed at length by Hershey.



DRAFT 1


E.2 Digitization of Plaintext The study of plaintext (the statistics, patterns, and other characteristics) is one of the most important considerations of cryptography. Annex C described a generic SCADA system and Annex D mapped the vulnerabilities of this SCADA system to the threats that can be addressed by a cryptographic system. Annex F describes the threat assessment. Simply put, SCADA systems run on bits; which in the native SCADA protocol are digitized into a steam of bits, and in some cases the stream is grouped into bytes (8 bits/byte).

E.3 Conversion of plaintext to ciphertext – the keytext generator Figure 1 shows an example of a module that generates keytext (a steam of ones and zeros) that is exclusive-ored bit by bit to a stream of plaintext to form a stream of ciphertext. It is important that the key generator appear to have no memory; that is, the output at any time must appear to be independent of what has preceded it. If this independence is lacking, the preceding keytext bits might help predict the current keytext bits.

Figure 1 Conversion of plaintext to ciphertext

There are two extremely important considerations. First, the same keytext should never be used to encipher two different plaintexts. If this is done, a classic and serious cryptographic error occurs, in the literature called a “problem of depth”. The second consideration is that an inquiry should be made into the randomness of the keytext. Are ones and zeros equally probable or can there be a slight bias? However, there are other requirements; addressed to the cryptographic system that comprises the keytext generator, which grow out of the possible use of a cryptographic system in a hostile environment.



DRAFT 1


E.3.1 The secret keying variable The cryptographic system must provide security even under the assumption that its design is known. This is required because the security of the cryptographic system must not rest solely with its design, as eventually the design will become known. The security therefore depends on something else – the key or keying variable that is easily changeable. It is a secret quantity that is inserted into a publicly known cryptographic system that configures or sets the cryptographic keytext generator in a unique state. This state is presumably unknowable to all parties except those possessing the secret.

E.3.2 Matched plaintext and ciphertext will not compromise the keying variable The cryptographic system must provide security under the assumption that the opposition may amass as much matched plaintext and ciphertext as desired. This can be stated in a number of equivalent ways. One way is to say that the prediction of the keytext bit at time t+1 is not aided by the knowledge of the keytext bits preceding it. Another way to say it is that the matched plaintext and ciphertext do not affect the security of the secret keying variable.

E.4 Block cipher function – modern keystone Modern one-key commercial cryptography is built around a component termed the block cipher function13. The block cipher function is endorsed by the US Department of Commerce’s National Bureau of Standards, which defined the Data Encryption Standard (DES), published as a Federal Information Processing Standard Publication (FIPS PUB) number 46 in 1977. A more robust extension of DES was published as triple DES. In 2001, FIPS PUB 197 – called the Advanced Encryption Standard (AES) was published. AES uses at minimum a 128 bit keying variable, and is AGA 12’s algorithm of choice.

E.4.1 Confidentiality modes Three modes are described: electronic code book mode, counter mode, output feedback mode, and cipher block chaining mode. E.4.1.1 Electronic code book mode The simplest, most basic method for operating the block cipher function is the electronic code book (ECB) mode. This mode uses the block cipher function to encrypt or decrypt a b-bit input word under the control of a secret keying variable. The ECB mode is one of only two modes that use the block cipher function in the decrypt mode for decryption. In the ECB mode, the same b-bit input block yields the same b-bit output block for the same keying variable. As such, the ECB mode is not a suitable confidentiality mode for the encryption of most message traffic. However, the mode is well suited for encrypting secret keying variables or other cryptographic variables that must be securely transmitted. It is also suitable for password verification. In this mode a user generates a password and the password generation function uses the user’s password (usually after a publicly known hashing process has been applied to it) as the keying variable for the block cipher function. The password generation function then proceeds to encrypt a b-bit known string, such as b-zeros, to encrypt the results of the previous encryption, and so on for a plurality of cycles. The result of the last encryption is then stored as the password check. 13

See NIST Special Publication 800-38A 2001 Edition for an expanded discussion on a recommendation for block cipher modes of operation.



DRAFT 1


The ECB mode may also be useful for key updating. Key updating is a technique in which a keying variable is operated on using a one-way function. E.4.1.2 Counter mode The counter (CTR) mode is essentially a coupling of a counter or other suitable finite state sequential machine with the ECB mode. In the CTR mode the cipher function is operated in the encrypt mode and its input block is filled with a setting that is successively changed. In the case of a counter, the setting is simply incremented. As long as the same setting is not used twice, the keytext generated by the block cipher function will not repeat and cause a depth situation. E.4.1.3 Output feedback mode The output feedback (OFB) mode uses the block cipher function operated in the encrypt mode, and its starting point is determined by a b-bit initialization vector (IV) that is loaded into the block cipher function’s input register before encryption is commenced. The b-bits produced by the first encryption and delivered to the output block are used as keytext and the next contents of the input register. Therefore, the encryption proceeds, using the output block contents as keytext and the IV for the next cycle. E.4.1.4 Cipher block chaining In a way, cipher block chaining (CBC) is somewhat similar to the ECB mode as it uses the block cipher function in the decrypt mode for decryption. Recall that a deliberate change in the ciphertext of a message protected under the OFB confidentiality mode results in a change in the corresponding portion of decrypted plain text. Note that there is a vulnerability analogy in the CBC mode in that a deliberate change introduced into the IV causes a change in the corresponding portion of the first ciphertext block.



DRAFT 1


AGA 12-1 ANNEX F SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES (Informative) REVISION 0.5

Submitted by AGA 12-1 Working Group

- – F-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


The following is a description of the operating environment (OE) for transferring SCADA messages point-to-point over low-speed serial communications links, designated OE, followed by a letter that will allow for future reference: OE-A. Low speed communications is primary link; typical parameters are 300-19,200 bps, 8 data bits, no parity, 1 stop bit. In general higher baud rates are thought to require more time for modems to negotiate than the entire time it takes to issue a SCADA command and receive a reply using modems operating at the lower baud rates. In some cases, there are secondary, backup communication links. OE-B. Short message lengths for many commands and responses: < 16-32 bytes. Almost all messages are less than 256 bytes (or some value around that, because data size is often one byte length) OE-C. Responses to queries can be as short as the query, or be significantly longer, even formatted as multiple messages (e.g., a request for historic information or range of data), but are formatted as individual responses. OE-D. The serial connection ensures order of multiple sent messages. OE-E. Noise can interfere with integrity of messages (especially on radio links). Typically integrity is checked using a checksum or CRC as part of the message. OE-F. SCADA native protocols are usually designed to handle damage or nonreceipt of messages due to noise and other interference with timeouts and retries built into application. OE-G. Ignorance of SCADA message format is desirable — transparent link encryptor approach OE-H. Messages have low cryptographic entropy. The number of acceptable messages is less than the number of bytes sent, often contain a byte count, addressing information that is either 8 or 16 bit to/from addresses, one byte commands, possible addressing of parameters tend to be in the low number range except on equipment with extensive capability and even then 64 or less. OE-I. The processors used in SCADA systems are typically slow and have little additional memory. In general, SCADA environments have been built on the polled—response model, where each remote device is queried by the host device (usually a computer) and the remote responds with its status, reading, set point, etc. Some systems operate on the polled—report-by-exception model, where remotes report only changes when polled. Some systems use an unsolicited—report or unsolicited—report-by-exception model where remote units send on their own (may be triggered by timeout from previous message or variation beyond limits from previous readings). Many systems perform polling on a near-continuous basis, i.e., polling of the next remote device starts shortly after the response has been received from the previous remote. Other systems may be polled on a scheduled basis with infrequent polls or commands by operator discretion. Some systems use the SCADA system to detect intrusion at the remote site, using a tamper switch inside the remote equipment box. Some systems provide for a broadcast address and a multi-drop communications system. Some allow for a store and forward operation on a command to extend communications range. There is at least one system that allows one remote unit to control another remote unit (peer to peer) The physical security may be weak in some locations. Equipment may be stolen from service trucks or remote locations System wide cryptographic keying should be avoided since the entire system would depend on the protection of a single secret key. Cryptographic keys should be very difficult to extract from Cryptographic Modules (CMs), which will be widely distributed. Rekeying should not be labor intensive to minimize costs and time to rekey. If an attack results in system compromise and damage to the infrastructure, utility personnel will be fully occupied with safety issues and restoring service, and be unavailable for rekeying units.



DRAFT 1


The general conclusions (C) listed below are based on the above: C-A. C-B. C-C.

C-D. C-E.

C-F. C-G.

C-H. C-I.

Encapsulation of SCADA messages is required to ensure transport of all information between devices. Attempting to interpret all or most SCADA message formats may be too complicated for implementation. Significant overhead (lots of additional bytes per SCADA message, lots of handshaking messages per SCADA message) will detrimentally affect the total number of messages capable of being sent in a given time period (message rate). SCADA messages (both queries and responses) or data packets (in some protocols) are small enough that they can fit within one packet in IP-related protocols, i.e., issues such as fragmentation and packet ordering in IP-related protocols are probably not a concern in the handling of SCADA messages. The communications protocol is not processing out-of-order packets (serial link ensures order). Reliable transport may not be necessary when moving SCADA messages. Because the application typically handles retries, retrying at a lower level may complicate operation. Discarding invalid messages may be a better fit with SCADA protocols, because remote SCADA devices also respond in the same manner. Reliable transport may be needed when moving other messages (those between encryption devices e.g., module authentication, key establishment). The SCADA application knows nothing of these messages. Protocols requiring complete message buffering before encrypting and sending, e.g., to place a length at the start of the encapsulated message, are thought to add unacceptable delays to the SCADA query-response times (3 x message transmission, host => CM, then CM == connection => CM, then CM => remote) Conversely, anything that reduces added latency is preferred, e.g., processing incoming blocks and sending them as they are completed. Use of direct connections with dial-up and leased lines eliminates the option of on-line authentication of remote and host CMs. If authentication is to occur, it must be some form of offline certification method (e.g., there is no call to a certifying agent) or direct challenge-response method. All parts necessary to authenticate must be on the module itself.

The desired functions (F) of a CM include: F-A. F-B. F-C. F-D. F-E. F-F.

Encryption of SCADA messages to prevent eavesdropping and command insertion —AES Blocking of replay attacks — inclusion of some form of message sequence number, timestamp, challenge-response (however, c-r may take too long; see C-B) Assurance of the integrity of the SCADA message, that it has not been modified in any fashion, e.g., noise, attack — CRC or SHA-1 Confirmation of identity of SCADA message sender (actually, of sender’s module) — HMAC Establishment of symmetric encryption keys through encryption channel — Diffie-Hellman, new keys encrypted with Key Exchange Key, new keys encrypted with RSA Recognition/authentication of CMs to each other; establishes that units haven’t been switched out or spoofed — certificates, challenge-response keys/algorithms

The concept of a session probably should be adopted to minimize the ratio of initialization & negotiation handshaking to SCADA message transmission. Current network-level protocols (SSL/TLS, SSH, IPSec) have the following elements for a “session”: 1. 2. 3. 4.

Client/server (initiator/responder) recognition, authentication Algorithm negotiation Key negotiation Data transmission protected by algorithms, keys



DRAFT 1


5. Session conclusion / return to previous point for renegotiation Using this framework, the following protocol outline has been developed. A workable definition of a “session” is the time period established for use of a set of algorithms, keys, operating modes, etc., for protecting SCADA messages. Sessions may be of short duration (per SCADA message, hour, day) or long (month, large number of messages, etc.). Sessions are automatically terminated at the end of the defined period, or can be terminated early: by a renegotiation request, by an external signal (e.g., loss of carrier detect on a leased line), by a time-out (e.g., no messages received within a given period), or by reaching a limit of the number of cryptographic errors encountered, either total or in a continuous stream. Cryptographic errors are messages that fail a test on the message, e.g., HMAC. Total errors are those that have occurred since a session start. Continuous stream of errors is the number of consecutive errors that have occurred, which is reset to 0 when a valid message is received. Due to the potentially noisy media used in serial communications, it was felt that some message errors can be permitted before requiring session termination, within the restraints defined. Negotiation can be done similarly to any of the noted protocols, including SSH’s person-readable plaintext exchange. Authentication can take place in the clear with most techniques (certificates, challenge-response with a nonce and shared secret). Most messages from host to remote are repeated instances of the same query. If Electronic Code Book (ECB) mode was used, most ciphertext messages would be the same (if the plaintext ended on a block boundary or did not use random padding), and unique messages, such as commands, would be identifiable because they are different. Cipher Block Chaining (CBC) is the most commonly chosen mode to address this problem (in the modes listed above). However, the possibility of losing previous blocks due to noise would require negotiation of a new Initialization Vector. Alternatively, the IV could be sent as part of the message (the first block), but this would extend the ciphertext message length by one block. Use of a 32-bit message sequence number or timestamp (if equipped with a RTC), prepended to the plaintext message would result in different ciphertexts for the same plaintext in the first block, even in ECB mode. Use of CBC would vary the ciphertexts of the following message blocks; the assumed Initialization Vector is 0 for the first block. Check to ensure currently received value is larger than previously received value should block replays. Note: use of unix time (second since 1970-01-01 00:00:00) assumes that messages are sent less frequently than once a second in this environment. Use of a flag indicating end-of-message is required to signal location of padding and HMAC value, because of the desire to process blocks on the fly instead of buffering entire messages (see C-G).



DRAFT 1


AGA 12-1 ANNEX G SAMPLE SCADA COMMUNICATIONS SECURITY POLICY (Informative) REVISION 0.5


- – G-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Model Field Communications Security Policy Overview SCADA, or supervisory control and data acquisition, is a specific implementation of industrial automation the utility industry uses to control and monitor the production, processing, transportation, and distribution of its products. For the purposes of this discussion, the term "utility company" will be understood to apply to any organization that operates a SCADA system. This of course includes utilities, as well as transmission companies, gathering field operators, or any other gas, water, or electric SCADA system. In addition, many of these polices also apply to Distributed Control Systems (DCS) that are more general than SCADA. Since a utility company’s facilities are typically dispersed over a large geographic area, utilities have implemented various wide-area communications channels in their SCADA network to link the facilities together. The availability, reliability, and security of these field communications links are of vital importance to the operational, financial, safety, and public image aspects of the utility’s business. This model policy was created on the following assumptions regarding field communications: •

This is a standalone policy; at this time there are no higher-level policy considerations feeding into this document.

•

This policy relates to data communications between facilities and/or equipment owned, leased, and/or operated by a utility company, its subsidiaries, its business partners and in some cases, customers.

•

The utility company or its subsidiaries may or may not own the media or channels in which the data communications will occur.

•

The type or nature of the data being transmitted over the medium is operationally oriented, including but not limited to SCADA or DCS commands and sensor readings.

•

At this time, this policy only addresses serial, asynchronous data communications methodology, such as RS232 or IEEE 485.

•

There is a need to secure access to the utility operator’s operations networks and reduce their overall vulnerability to external intrusion (e.g., hacking, entry of false data, eavesdropping, etc).

•

At this time, communication security is being added to the communication media as a retrofit appliance.

•

Utility companies will use this document as a sample policy that they will modify and incorporate into their own policies. Accordingly, the document illustrates how a company might use the wording by using the expression as a placeholder where an actual company might put its own name. While it is assumed that some of the following wording may be of help in drafting policies, it is also understood that the policies below will require modification before they can be adopted in specific cases.

•

Readers of this model policy will pay careful attention to the choice of words "shall" (meaning must in order to comply) and “may” (indicating the policy allows a range of possible choices). Companies desiring a more restrictive policy will use "shall".

•

While essentially all of the information in this Annex can be found scattered throughout the AGA 12-1 report and various other standards, for the convenience of those focused on writing a policy document this material is assembled in a single place and organized from a policy perspective.



DRAFT 1


Model Policy Introduction Purpose The purpose of this policy is to define standards for communications between 's operations management centers, including their extensions, and remote facilities. This policy is designed to minimize the potential exposure to from damages, which may result from unauthorized use of resources. Damages include the loss of sensitive or company confidential data, intellectual property, damage to physical property, loss of production and/or distribution capabilities, damage to public image, damage to critical internal systems, etc.

Scope This policy applies to all employees, partners, contractors, vendors and agents with a -owned, employer-owned or personally owned computing device used to connect to the network. This policy applies to local access and remote access connections used to do work on behalf of , including but not limited to reading or sending operational information. Local access and remote access implementations that are covered by this policy include, but are not limited to, Internet, LAN, dialup modems, leased-lines, frame relay, ISDN, DSL, cable modems, satellite, microwave, packet radio, wireless LAN’s, cellular, VPN, SSH, Browsers, etc.

Policy General •

It is the responsibility of employees, partners, contractors, vendors, and agents with access privileges to 's operations network to use it for authorized operational purposes only, in accordance to ‘s Acceptable Use Policy.

•

It is the responsibility of employees, partners, contractors, vendors and agents with remote access privileges to 's operations network to ensure that the security of their remote access connection is given the same consideration as the user's onsite connection to communication links.

•

The ‘s employees, partners, contractors, vendors and agents shall not grant access to any unauthorized party to the 's operational network for any purpose. The ‘s employee, partner, contractor, vendor or agent bears responsibility for the consequences should unauthorized access be granted.

•

All information accessed and/or transmitted over 's operational network must adhere to ‘s Information Sensitivity Policy.

•

The following documents should be reviewed for detailed policy information when utilizing or accessing 's network via local or remote access methods:



DRAFT 1


1. 2. 3. 4. 5. 6. 7.

Cryptography Policy SCADA Cryptographic Module Policy Hardware Security Module Policy * User Authentication and Encryption Token Policy * Access Control Policy Acceptable Use Policy Information Sensitivity Policy

* These model policies apply only to companies using this hardware.

Requirements •

Per ‘s Information Sensitivity Policy, all authorized information traveling over the ‘s field communications channels shall be periodically reviewed to determine its criticality and sensitivity levels.

•

Per ‘s Information Security Audit Policy, all field communications channels shall periodically undergo a Vulnerability Assessment, Risk Assessment, and Risk Analysis to determine if any new threats are identified. This assessment should include, but is not limited to: assessing the security impact of new or unauthorized information or capabilities that have been made available intentionally or accidentally, verifying that all configuration and security settings are correct and current, assessing vulnerability to new hacking techniques or identified weaknesses, etc.

•

Per ‘s findings of the Information Security Audit Policy, Vulnerability and Risk Assessment Policy, and Information Sensitivity Policy periodic assessments, ‘s operations network shall be secured appropriately. Corrective actions, if warranted could include, but are not limited to, adding appropriate security measures, or simply removing or deactivating the offending capability/vulnerability.

•

Only devices (communications infrastructure devices, security devices, computing devices or SCADA/DCS devices) approved by ‘s InfoSec department shall be connected to ‘s operations network.

•

All ‘s confidential information transmitted or accessible over non-company owned field communications channels, including but not limited to leased-lines, dialup, public networks, or wireless shall be encrypted by an approved security device before transmission.

•

All security devices attached to ‘s operations network to provide data encryption of information transmitted or accessible over ‘s field communications channels shall adhere to ‘s SCADA Cryptographic Security Module Policy and shall be approved by ’s InfoSec department.

G.2.3.3 Operational Guidelines •

’s InfoSec department shall establish a checklist for implementing and auditing this policy.

Enforcement Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.



DRAFT 1


Checklist To be developed by the user

Definitions Revision History



DRAFT 1


Model A Cryptography Policy Purpose The purpose of this policy is to provide guidance that limits the use of encryption and digital signatures to those algorithms, protocols and cryptographic hardware that have received substantial public review and have been proven to work effectively. Additionally, this policy provides direction to ensure that national government regulations are followed, and legal authority is granted for the dissemination and use of encryption technologies outside of their country of origin.

Scope This policy applies to all > employees, partners, contractors, vendors and agents accessing ’s business or operational networks, or sending and receiving confidential information as defined in ’s Information Sensitivity Policy.

Policy General •

Only algorithms approved by a recognized national organization shall be accepted by this policy. •

For the United States, only algorithms approved by the National Security Agency (NSA) and the National Institute for Standards and Technology (NIST), as listed in FIPS Publication 1402 Annex A shall be accepted by this policy.

•

Export Control and usage regulations for cryptographic hardware and algorithms shall be reviewed and adhered to when using cryptography across national borders.

•

All cryptographic keys shall be generated, employed, and managed in an approved manner based on their intended use.

•

All cryptographic keys used to encrypt and decrypt information14 owned by or entrusted to , stored on physical computer media owned, leased or operated by , or injected into cryptographic hardware owned, leased or operated by shall be generated, exchanged and escrowed by ’s InfoSec department.

•

For the United States, compliance with the practices recommended in AGA Report No. 12-1 shall be taken as being in compliance with this policy.

14

Information in this instance refers to tangible data-sets such as a file, a folder, an email message, other long-lived cryptographic keys, etc. It does not refer to intangible data such as a data stream (i.e.; a SSL or VPN session) or short-lived cryptographic keys (a session key).



DRAFT 1


Requirements Algorithms •

For encryption of files and emails, and for use by link-encryptors, AES (with keys of length 128, 192, and 256-bits) is approved.

•

For hashing or file integrity checking, SHA-1, HMAC, and CCITT CRC-16 are approved.

•

For digital signatures, RSA and ECDSA are approved.

Cryptographic keys Keys for non-repudiation (digital signatures, legal equivalent of a handwritten signature): •

A public and private key pair shall be generated and stored in hardware that conforms to FIPS PUB 140-1 or FIPS PUB 140-2 with an overall security rating of Level 2 or higher.

•

The private key shall never be exposed outside of the approved hardware device.

•

Key pairs for use with RSA shall be at least 1024 bits in length.

•

Key pairs for use with ECDSA shall be at least 160 bits in length.

Keys for blob (file or volume) encryption of company information: •

Encryption key(s) (a public and private key pair for asymmetric encryption or a single key for symmetric encryption) shall be generated in hardware that conforms to FIPS PUB 140-1 or FIPS PUB 140-2 with an overall security rating of Level 2 or higher.

•

If the encryption key(s) is/are to be used in hardware other than in-which it was/they were generated, a copy of the encryption key(s) shall be injected into the new hardware that conforms to FIPS PUB 140-1 or FIPS PUB 140-2 with an overall security rating of Level 2 or higher, in an approved manor prior to its use.

•

A copy of the encryption key(s) for use with ’s information, computing devices and/or networks, shall be stored in escrow via an approved manner, with ’s InfoSec department prior to its/their use.

•

RSA-based blob encryption key pairs shall be at least 1024 bits in length.

•

ECDSA-based blob encryption key pairs shall be at least 160 bits in length.

•

Symmetric blob encryption keys shall be at least 128 bits in length.

Keys for data communications (tunneling or link-level) encryption •

Session keys (one-time use or time-limited use) may be generated in software or by hardware.

•

Session keys shall be at least 128 bits in length.

•

Session keys shall be transmitted to the remote hardware encryption device(s) in the following approved manner: •

Session keys shall not be transmitted to a remote hardware encryption device as plaintext; they shall be encrypted prior to transmission by use of a key encryption key or key encryption key pair.



DRAFT 1


• •

•

Symmetric key encryption keys shall be generated in hardware that conforms to FIPS PUB 140-1 or FIPS PUB 140-2 with an overall security rating of Level 2 or higher. Key encryption keys shall be injected into two or more hardware encryption devices that conform to FIPS PUB 140-2 with an overall security rating of Level 2 or higher, in an approved manner prior to their use.

•

Symmetric key encryption keys shall be at least 128 bits in length.

•

Symmetric keys for key exchange shall be managed in conformance with AGA 12-1, Annex H.

•

Key encryption key pairs shall be generated and utilized in hardware encryption devices that conform to FIPS PUB 140-1 or FIPS PUB 140-2 with an overall security rating of Level 2 or higher.

•

RSA-based Key encryption key pairs shall be at least 1024 bits in length.

•

ECDSA-based Key encryption key pairs shall be at least 160 bits in length.

Session keys shall be exchanged via a key exchange algorithm approved by this policy.

Compliance with the practices recommended in AGA Report No. 12-1 will be taken as being in compliance with this policy.

Key escrow Note: key escrow, e.g.; the secure storage of encryption keys, is an important business continuity issue for any organization that employs a cryptosystem. If an organization protects a tangible dataset (e.g.; a file, a disk volume or other keys) via encryption and the encryption key(s) is/are lost or damaged, the dataset will no longer be accessible to the organization. Loss of this data may result in serious business implications. Since a key escrow system is a central repository of encryption keys that protects an organization’s confidential information, special care needs to be taken to protect the integrity of, and to ensure the proper operation or management of, the key escrow system. •

If requires that encryption keys or key pairs shall be generated on a Hardware Security Module (HSM), ’s InfoSec department shall require that the HSM shall be approved as defined in ’s Hardware Security Module Policy. •

•

’s InfoSec department shall generate a Key Escrow Encryption Key on an approved HSM specifically for use in Key Escrow operations.

’s InfoSec department shall only exchange encryption keys or key pairs between approved cryptographic hardware as defined in this policy. •

’s Key Escrow Encryption Key shall only be exchanged with another approved HSM for disaster recovery or redundancy (i.e.; load-balanced server farms) purposes.

•

’s InfoSec department shall employ approved key exchange practices, protocols and algorithms to transfer encryption keys and key pairs between HSM’s and other cryptographic hardware.

•

All encryption keys and key pairs to be escrowed in ’s Key Escrow Repository, shall be encrypted using an approved algorithm on an approved HSM containing and utilizing ’s Key Escrow Encryption Key, prior to their being escrowed.

•

’s InfoSec department shall establish a policy and procedure for Key Escrow, including but not limited to: establishing the Key Escrow Encryption Key; creating and managing of a backup Key Escrow Encryption Key; defining the number of operators (i.e.; four-hands) required to perform Key Escrow procedures; establishing, certifying, managing and operating a



DRAFT 1


Key Escrow Repository system, and disaster recovery plans if the Key Escrow Encryption Key should be compromised. •

’s InfoSec department shall establish a policy and procedure for employees, partners, contractors, vendors and agents to: request, employ, manage, and destroy an encryption key or key pair.

Cryptographic hardware All cryptographic hardware utilized by , must comply with one of the following policies: •

SCADA Cryptographic Module Policy

•

Hardware Security Module Policy *

•

User Authentication and Encryption Token Policy *

* These model policies apply only to companies using this hardware.

Operational guidelines •


Certification •

shall require that all CMs comply with the requirements of AGA Report 12-1 and are certified to comply by an approved National Voluntary Laboratory Accreditation Program testing facility.


Checklist ’s InfoSec department shall establish a checklist for implementing and auditing this policy.

Definitions Hardware Security Module (HSM)

Key Escrow

An HSM is a cryptographic device designed to generate, store and utilize high-quality cryptographic keys in a safe and secure manner. An HSM employs a protective boundary around its components that actively monitors for signs of tampering. If the HSM detects tampering, it will erase the cryptographic key material, thereby preventing the keys from becoming compromised. Key escrow is a practice that provides backup for encryption keys. If a data-set is encrypted and later the decryption key is lost, the data-set is also lost. Companies employ key escrow to



DRAFT 1


Key Escrow Encryption Key Key Escrow Repository Key Exchange Non-repudiation

protect against loss of cryptographic keys and the electronic information they protect. Key Escrow Encryption Keys are special purpose encryption keys specifically utilized to encrypt other encryption keys. A Key Escrow Repository is a system and database specifically designed, protected and operated to store encryption keys. The practice of securely transferring cryptographic keys between two entities, such as an HSM and an end point device (a user token or a link encryptor, etc). Non-repudiation is a process employing digital signatures that positively identifies the author of a transaction and guarantees the integrity of the transaction.

References FIPS Publication 140-2 Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm FIPS PUB 140-2 Annex A

Approved Security Functions Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm

Revision History

- –G-10 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Model B SCADA Cryptographic Module Policy Purpose The purpose of this policy is to provide guidelines for the selection for purchase and operational procedures of a SCADA Cryptographic Module (CM).

Scope This policy applies to all operations networks owned, leased, shared or operated by , its subsidiaries or partners, containing SCADA or DCS technology that employs serial or asynchronous technology as part of its communications channel in or between the master control center, its extensions and/or remote facilities.

Policy General •

Only CM’s conforming to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 2 or higher will be accepted by this policy.

•

Only CM’s conforming to applicable cryptographic algorithms as defined in ’s Cryptography Policy will be accepted by this policy.

•

Only CM’s conforming to cryptographic key generation, storage, usage, and exchange practices for data communications encryption as defined in ’s Cryptography Policy will be accepted by this policy.

Requirements Selection for purchase specifications •

The CM shall meet Level 3 requirements for Cryptographic Module Ports and Interfaces, section 4.2 of FIPS Publication 140-2 (or FIPS PUB 140-1 during the transition period to FIPS PUB 1402). •

•

Data communications ports: •

CM’s shall provide a minimum of two physical data ports, one for wide area communications and one for local area communications.

•

Both physical data ports shall conform to the EIA RS-232 standards with bit rates up to 115kbps. The physical ports may be either 25-pin D connectors or 9-pin D connectors. (Note: this type of statement will typically be modified to describe the ports the SCADA operator uses. However, the statement should be sufficiently general that it will not require frequent policy change in response to changes in technology the company is using.)

Management ports: •

CM’s shall provide a local access port for local configuration and management.



DRAFT 1


• •

The CM shall provide at least the following roles as defined in Roles, section 4.3.1 of FIPS Publication 140-2 •

•

•

•

CM’s may provide a local access port for strong authentication (two-factor authentication).

User Role •

The CM is intended to be an autonomous non-intrusive appliance used to encrypt data that passes through it (i.e.; a link encryptor). As such, it does not have a user as implied by the FIPS documentation. It is possible to imply that in normal operation the data stream passing through the SSM could be the “user”.

•

The User Role does not require authentication.

Crypto Officer Role •

The Crypto Officer Role shall perform both cryptographic functions (key generation, key exchange, etc) and security functions (set passwords, etc).

•

The Crypto Officer Role shall require strong authentication.

Maintenance Role. •

The Maintenance Role shall only perform maintenance functions (set configurations, run diagnostics, etc).

•

The Maintenance Role shall require strong authentication.

The CM shall provide at least the following services and states as defined in Services, section 4.3.2 and Finite State Model, section 4.4 of FIPS Publication 140-2. •

•

The CM shall provide the following services and states for management: •

The CM shall provide a Local Management service, conducted on a dedicated out-ofband data port (trusted path). Local management communications may be conducted in plaintext.

•

The CM shall provide a Remote Management service, conducted over the wide area communications port and/or the local area communications port. All remote management communications shall be encrypted.

The CM shall provide the following services and states for pass-through data: •

The CM shall provide a bypass service that performs no cryptography on the data stream (transparent: plaintext data in not encrypted).

•

The CM shall provide a SCADA Security service that performs cryptography on the data stream (plaintext data is encrypted).

•

The CM shall support (pass-through and/or encrypt/decrypt) SCADA protocols in a transparent manner:

•

CM environmental specifications: •

Temperature range: -40º to 80ºC

•

Humidity: 0 to 95% non-condensing

•

Water resistance

•

Drop to concrete from a height of 2 meters



DRAFT 1



’s InfoSec department shall conduct a pre-acceptance audit of all CM’s before they are approved for installation in ’s operations network. The acceptance test shall include, but not be limited to, inspection of the shipping box for damage and tamper evidence; inspection of the CM for damage and tamper evidence; recording the CM’s serial number, model number and version number; running CM self test diagnostics both locally and remotely; performing an initialization procedure to destroy all previous cryptographic keys, passwords/PINS and configuration settings.

•

’s InfoSec department shall conduct a pre-installation configuration procedure for all CM’s before they are installed in ’s operations network. The configuration procedure must include, but not be limited to, establishing the Crypto Officers digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the Maintenance digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the cryptographic key exchange key(s). The configuration procedure may include, but not be limited to, establishing cryptographic session keys; establishing the CM’s friendly name; performing any other configuration tasks or settings.

•

’s InfoSec department shall establish a CM key exchange policy that will determine the reasons, periodic timeframes, and procedures to perform a key exchange on all or selected CM’s within ’s operations network.

•

’s InfoSec department shall establish a CM inspection policy that will determine periodic timeframes and procedures for inspecting CM’s that are deployed in ’s operations network.

•

’s InfoSec department shall establish a policy and procedure for reporting tamper evidence of CM’s, possible compromised CM cryptographic keys, and a mitigation plan to re-secure ’s operations network.

•

’s InfoSec department shall establish a policy and procedure for initializing any CM’s that are taken out of service to prevent password/PIN, key exchange keys or session keys, etc., from being compromised.

•


Certification •

. shall require that all CMs comply with the requirements of AGA Report 12-1 and are certified to comply by an approved National Voluntary Laboratory Accreditation Program testing facility.





DRAFT 1


Definitions

References FIPS Publication 140-2 Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm

Revision History



DRAFT 1


Model C Hardware Security Module Policy (Only applies to companies using this hardware)

Purpose The purpose of this policy is to provide guidelines for the selection for purchase and daily operational policy and procedures associated with a Hardware Security Module (HSM). This model policy applies only to those companies opting to use an HSM and will not appear in the policies of other companies.

Scope This policy applies to all operations networks owned, leased, shared or operated by , its subsidiaries or partners that employ cryptographic security requiring secure key generation, encryption, escrow, and exchange.

Policy General •

Only HSM’s conforming to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher shall be accepted by this policy.

•

Only HSM’s conforming to applicable cryptographic algorithms as defined in ’s Cryptography Policy shall be accepted by this policy.

•

Only HSM’s conforming to cryptographic key generation, storage, usage, and exchange practices for non-repudiation, encryption, escrow and exchange as defined in ’s Cryptography Policy shall be accepted by this policy.

•

The HSM shall have a programmers interface (API).


The HSM shall meet Level 4 requirements for Self Test, section 4.9 of FIPS Publication 140-2 (or FIPS PUB 140-1).

•

Physical form factor:

•

•

The HSM may be implemented as a card for supporting a single server

•

The HSM may be implemented as a network appliance for supporting a server farm.

Cryptographic Module Ports and Interfaces: •

The HSM shall provide a minimum of one physical port for data and maintenance. •

For HSM’s configured as a card for internal integration into a single sever, an industry standard bus specification such as PCI is acceptable.



DRAFT 1


• • •

The HSM shall provide a minimum of one physical port (trusted path) for strong authentication.

The HSM shall provide at least the following roles as defined in Roles, section 4.3.1 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

•

•

User Role •

The User Role shall only perform user functions such as key generation, key exchange and key escrow functions.

•

The User Role shall require strong authentication.


The Crypto Officer Role shall only perform CO functions such as: create other users (User Role, Maintenance Role); perform HSM initialization; create and backup Master Keys and Escrow Keys; perform synchronization with other HSM’s in the same domain.

•


The HSM shall provide at least the following services and states as defined in Services, section 4.3.2 and Finite State Model, section 4.4 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

The HSM shall provide a Crypto Officer service to perform all CO functions. •

•

The Crypto Officer service shall require strong authentication. All communications between the HSM and the Crypto Officer service’s user interface shall be encrypted.

The HSM shall provide a User service to perform all User functions. •

•

For HSM’s configured as an appliance for supporting a server farm, an industry standard network interface such as Ethernet is acceptable.

The User service shall require strong authentication. All communications between the HSM and the User service’s user interface shall be encrypted.

The HSM shall support the following software and software capabilities: •

Computer Operating systems: Windows NT, 2000, Solaris, Linux

•

Web servers: Apache, iPlanet, Microsoft IIS 5.0, Netscape,

•

PKI: Baltimore, Computer Associates, Entrust, Microsoft, Netscape, RSA, VeriSign

•

SSL version 3.0, or later, for encrypted sessions (HTTPS) and to perform user authentication.

•

API’s: PKCS #11, MS-CAPI


’s InfoSec department shall conduct a pre-acceptance audit of all HSM’s before they are approved for installation in ’s operations network. The acceptance test shall include, but not be limited to, inspection of the shipping box for damage and tamper evidence; inspection of the HSM for damage and tamper evidence; recording the HSM’s serial number, model number and version number; running HSM self test diagnostics; performing an initialization procedure to destroy all previous cryptographic keys, users, passwords/PINS and configuration settings.

•

’s InfoSec department shall conduct a pre-installation configuration procedure for all HSM’s before they are installed in ’s operations network. The configuration procedure shall include, but be not limited to, establishing the Crypto Officers digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the Maintenance



DRAFT 1


and User digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the cryptographic Master Keys and Exchange Key(s). The configuration procedure may include, but not be limited to, establishing cryptographic session keys; establishing the HSM’s friendly name; performing any other configuration tasks or settings. •

’s InfoSec department shall establish a HSM replication policy that will determine the reasons, periodic timeframes, and procedures to perform a key replication to all or selected HSM’s within ’s operations network.

•

’s InfoSec department shall establish a HSM inspection policy that will determine periodic timeframes and procedures for inspecting HSM’s that are deployed in ’s operations network.

•

’s InfoSec department shall establish a policy and procedure to respond to the possibility an HSM should be tampered with or accessed by unauthorized personnel.

•

’s InfoSec department shall establish a policy and procedure for initializing any HSM’s that are taken out of service to prevent Master Keys, Key Exchange Keys, user information, etc., from being compromised.

•




Definitions Hardware Security Module (HSM)

An HSM is a device used to generate, store and utilize cryptographic keys in a secure manner and location. HSM’s contain a feature that performs a zeroization process (a secure erase) if the device is tampered with, thus preventing the keys from being compromised.

Appliance

A standalone and/or turnkey device (a separate box) that provides a specific function. Example, an email server could be implemented as either a set of software loaded onto a generic server that also supports other functions such as print serving, file serving, etc; or it could be implemented as a dedicated box. Appliances are typically considered easier to implement and manage compared to server-based products.

Server Farm

A group of servers in a single location, typically providing the same service for capacity, performance and redundancy reasons.



DRAFT 1


References FIPS Publication 140-2 Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm

Revision History



DRAFT 1


Model D User Authentication and Encryption Token Policy (Only applies to companies using this hardware)

Purpose The purpose of this policy is to provide guidelines for the selection for purchase and operational procedures associated with a user authentication and encryption token (user token). This model policy applies only to those companies opting to use user tokens and will not appear in the policies of other companies.

Scope This policy applies to all operations networks owned, leased, shared or operated by , its subsidiaries or partners that employ cryptographic security requiring strong user authentication and secure encryption capabilities.

Policy General •

Only user tokens conforming to at least one of the following standards will be accepted by this policy. •

FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 2 or higher.

•

Common Criteria evaluation against the Smart Card Security Users Group Smart Card Protection Profile version 3.0 or later, with an overall rating of EAL 4 or higher.

•

Only user tokens conforming to applicable cryptographic algorithms as defined in ’s Cryptography Policy shall be accepted by this policy.

•

Only user tokens conforming to cryptographic key generation, storage, usage, and exchange practices for non-repudiation and encryption as defined in ’s Cryptography Policy shall be accepted by this policy.


Physical form factor: •

The user token may be implemented as an ISO 7816 compliant smart card. •

•

Requires an ISO 7816 compliant reader. •

May be implemented as imbedded or external device (serial, parallel, keyboard, PCMCIA, or USB).

•

USB readers shall be USB 1.1 or 2.0 and Plug and Play compliant.

•

Shall be WHQL certified (if applicable).

Smart cards do not require a trusted PIN path.



DRAFT 1


•

•

•

Shall be USB 1.1 or 2.0 compliant.

•

Shall be Plug and Play compliant.

•

Shall be WHQL certified.

•

USB tokens do not require a trusted PIN path.

The user token shall provide at least the following roles as defined in Roles, section 4.3.1 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

•

•

•

The user token may be implemented as a USB cryptographic token.

User Role •

The User Role shall only perform user functions such as generating signing and encryption keys, unlocking the private key for signing or encryption and decryption operations, or changing the user PIN.

•

The User Role shall require authentication.


The Crypto Officer Role shall only perform security configuration functions such as complete token initialization, configure security settings, adding Maintenance users, generating of or injecting exchange keys, or run diagnostics.

•

The Crypto Officer Role shall require authentication.


The Maintenance Role shall only perform maintenance functions such as user initialization, unblocking, or run diagnostics.

•

The Maintenance Role shall require authentication.

The user token shall provide at least the following services and states as defined in Services, section 4.3.2 and Finite State Model, section 4.4 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

The user token shall provide a Crypto Officer service to perform all CO functions. •

•

The user token shall provide a Maintenance service to perform all Maintenance functions. •

•

The Crypto Officer service shall require authentication.

The Maintenance service shall require authentication.

The user token shall provide a User service to perform all User functions. The User service shall require authentication.

•

The user token shall support the following software and software capabilities: •

Computer Operating systems: Windows XP, 98, ME, 2000, .NET, Unix, Linux, Mac

•

Cryptographic service providers: MS-CAPI, PKCS #11

•

Reader drivers shall be PC/SC compliant (includes USB token implementations)

•

Digital Certificates: X.509 v3; PKCS #1, 7, 10, 12 key/cert generation and injection

•

Web browsers: Microsoft IE 4.0 or later, Netscape 4.0 or later

•

Email clients: Netscape Communicator and Microsoft Outlook (98, 2000, Express)

•

PKI: Baltimore, Computer Associates, Entrust, Microsoft, Netscape, RSA, VeriSign



DRAFT 1



’s InfoSec department shall conduct a pre-acceptance audit of all user tokens before they are approved for use in ’s operations network. The acceptance test shall include, but not limited to, inspection of the shipping box for damage and tamper evidence; inspection of the user token for damage and tamper evidence; performing an initialization procedure to destroy all previous cryptographic keys, passwords/PINS and configuration settings.

•

’s InfoSec department shall conduct a pre-use configuration procedure for all user tokens before they are used in ’s operations network. The configuration procedure shall include, but not limited to, establishing the Crypto Officers digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the Maintenance digital identity (via password, PIN, shared secret, digital certificate, etc); establishing the cryptographic key exchange key(s). The configuration procedure may include, but not limited to, establishing the user token’s friendly name; performing any other configuration tasks or settings.

•

’s InfoSec department shall establish a policy and procedure for issuing user tokens to authorized users and establishing users credentials on the user token.

•

’s InfoSec department shall establish a policy and procedure for unblocking user tokens.

•

’s InfoSec department shall establish a policy and procedure for replacing lost or damaged user tokens, including related encryption key mitigation issues.

•

’s InfoSec department shall establish a policy and procedure for reporting tamper evidence or unauthorized access of user tokens.

•

’s InfoSec department shall establish a policy and procedure for initializing any user token that is taken out of service to prevent password/PIN, key exchange keys, etc., from being compromised.

•




Definitions ’s InfoSec department shall include any definitions required to clarify points or terms of this policy.



DRAFT 1




DRAFT 1


Tamper Evidence

A minimal physical security feature of FIPS Publications 140-1 and 140-2. If an adversary attempts to attack (open) a cryptographic device, the device must show evidence that it has been opened. Evidence could be manifested as a torn warranty sticker, deformed or damaged plastic housing, leakage of a liquid material, etc.

Digital Certificate

A file or document implemented in Public Key Infrastructure used to provide identity of an individual and a copy of their public key. The Digital Certificate is digitally signed by a trusted third-party that guarantees the identity of the individual. Digital Certificates are defined in ANSI publication X.509.

Shared Secret

Any type of information or value shared secretly by two entities to prove identity, such as a PIN, a password, a secret handshake, a symmetric encryption key, etc.

References FIPS Publication 140-2 Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm SCSUG Protection Profile

Smart Card Protection Profile Smart Card Security Users Group http://www.scsug.org/

Revision History



DRAFT 1


Model E Access Control Policy Overview ’s management team's intentions for publishing an Access Control Policy are not to impose restrictions that are contrary to established culture of openness, trust and integrity. Management is committed to protecting 's employees, partners, customer, shareholders and the company from illegal or damaging actions by individuals, either knowingly or unknowingly. Effectively protecting a business is a team effort involving the participation and support of ’s employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, who are authorized to access information, information systems, process control and networks. It is the responsibility of these users to know these guidelines, and to conduct their activities and protect company information accordingly.

Purpose The purpose of this policy is to provide guidelines for the selection and daily operational policy and procedures associated with Access Control. Access Control is the front line to securing a system. Without proper Access Control, it is impossible to determine who may or may not access a system, or what functions users or devices are authorized to perform.

Scope This policy applies to all employees, contractors, consultants, temporaries, and other workers, including all personnel affiliated with third parties accessing ’s business or operational networks or systems. This policy also applies to automated processes that are authorized to conduct approved business or operational functions for , and devices that are part of ’s business or operational networks.

Policy User accounts, passwords, PINs, identity tokens, etc (collectively referred to as credentials) are the property of . These credentials shall only be used for approved business purposes in serving the interests of the company in the course of normal business operations. Employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, shall protect their credentials at all times and shall not knowingly share or grant access to their credentials to any other individual for any purpose. This includes the prohibition of sharing of your credentials with your family, supervisor, co-workers, or ’s helpdesk. User credentials shall have the appropriate characteristics to meet the security requirements dictated by their usage in accordance to ’ Information Sensitivity Policy and this policy. User



DRAFT 1


credentials shall be manufactured or generated, employed, managed and destroyed in accordance to the Practices and Procedures of this policy.

Practices Managers and Supervisors shall grant authorization to employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, to access information, information systems, process control systems, networks and facilities at the appropriate level to meet their business functions. ’s InfoSec department shall manage the user roles and privileges as directed by department Managers and Supervisors. ’s InfoSec department shall manage user credentials as directed by this policy. Single-factor Access Control credentials (including usernames, passwords and PINs) shall not be guessable via any means, including system knowledge, domain knowledge, personal knowledge, or dictionary attacks. Multi-factor Access Control credentials (including smart cards and USB tokens) shall conform to ’s User Authentication and Encryption Token Policy.

Procedures ’s InfoSec department shall create a Practice and Procedure for Single-factor Access Control credentials, including but not limited to: generation techniques; minimum length; mix of character types and cases; periodic renewal; steps to be taken if a credential is compromised or forgotten; and acceptable use based upon Information Sensitivity level as defined by ’s Information Sensitivity Policy. ’s InfoSec department shall create a Practice and Procedure for Multi-factor Access Control credentials, including but not limited to: credential and token technologies; provisioning techniques; periodic renewal; periodic inspection of tokens; steps to be taken if a token’s PIN or passphrase is forgotten or blocked; steps to be taken if a token is compromised; acceptable use based upon Information Sensitivity level as defined by ’s Information Sensitivity Policy. Management shall authorize the creation of an Access Control Awareness program, and the periodic implementation of the awareness program for all employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties. Management shall authorize the creation of an audit plan for the Access Control Policy and the periodic implementation of the audit plan. ’s InfoSec department shall modify this policy as directed by ’s management team to meet their corporate goals for Access Control.


Checklist - –G-25 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1




Revision History



DRAFT 1


Model F Acceptable Use Policy Overview ’s management team's intentions for publishing an Acceptable Use Policy are not to impose restrictions that are contrary to established culture of openness, trust and integrity. Management is committed to protecting 's employees, partners, customer, shareholders and the company from illegal or damaging actions by individuals, either knowingly or unknowingly. Effective security is a team effort involving the participation and support of ’s employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, who are authorized to access information, information systems, process control systems and networks. It is the responsibility of these users to know these guidelines, and to conduct their activities accordingly.

Purpose The purpose of this policy is to outline the acceptable use of information, information systems and networks owned or operated by . These rules are in place to protect the employee and . Inappropriate use exposes to risks including virus attacks, compromise of information systems and services, potential loss of revenue, exposure of confidential information, and legal actions.

Scope This policy applies to employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties. This policy applies to all information, documentation, reports, systems, networks, equipment, software and user accounts that are owned or operated by .

Policy Information, information systems, process control systems, networks, and user accounts (collectively referred to as resources) are the property of . These resources are to be used for business purposes in serving the interests of the company in the course of normal business operations. While 's management desires to provide a reasonable level of privacy, users should be aware that the information they create on the corporate systems remains the property of . For security and maintenance purposes, authorized individuals within may monitor information, equipment, software, systems and network traffic at any time, per ’s Audit Policy. reserves the right to audit information, equipment, software, systems and network traffic on a periodic basis to ensure compliance with this policy. If there is any uncertainty about this policy, individuals should consult their supervisor or manager.



DRAFT 1


Practices owned and/or operated resources are to be used for business purposes in serving the interests of the company in the course of normal business operations. Managers and Supervisors shall grant authorization to employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, to access information, information systems, process control systems, and networks at the appropriate level to meet their business functions. ’s InfoSec department shall manage the user roles and privileges as directed by department Managers and Supervisors. Under no circumstances are employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties authorized to: •

Engage in any activity that is illegal under local, state, federal or international law while utilizing -owned, leased, or operated resources.

•

Violate the rights of any person or company protected by copyright, trade secret, patent or other intellectual property, or similar laws or regulations, including, but not limited to, the installation or distribution of "pirated" or other software products that are not appropriately licensed for use by .

•

Effect security breaches or disruptions of information, information systems, process control systems or network communications. Security breaches include, but are not limited to, monitoring network traffic or accessing data of which the employee is not an intended recipient, or logging into a system or account that the employee is not expressly authorized to access, unless these duties are within the scope of regular duties. For purposes of this section, "disruption" includes, but is not limited to, introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, e-mail bombs), network sniffing, pinged floods, packet spoofing, denial of service, and forged routing information for malicious purposes.

•

Make fraudulent offers of products, items, or services.

•

Make statements about pricing, services, availability, warranty, expressly or implied, unless it is a part of normal job duties.

Management shall authorize the creation of Acceptable Use Awareness program, and the periodic implementation of the awareness program for all employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties. Management shall authorize the creation of an audit plan for the Acceptable Use policy and the periodic implementation of the audit plan.

Procedures ’s InfoSec department shall modify this policy as directed by ’s management team to meet their corporate goals for Acceptable Use. ’s InfoSec department shall create the procedural steps required to meet the Policy and Practices goals of this policy as defined by ’s management team.



DRAFT 1





Revision History



DRAFT 1


Model G Information Sensitivity Policy Overview ’s management team's intentions for publishing an Information Sensitivity Policy are not to impose restrictions that are contrary to established culture of openness, trust and integrity. Management is committed to protecting 's employees, partners, customer, shareholders and the company from illegal or damaging actions by individuals, either knowingly or unknowingly. Effectively protecting a business is a team effort involving the participation and support of ’s employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, who are authorized to access information, information systems, process control and networks. It is the responsibility of these users to know these guidelines, and to conduct their activities and protect company information accordingly.

Purpose The purpose of this policy is to establish guidelines regarding the classification of information, what information can be disclosed to other employees and non-employees, as well as the relative sensitivity of information that should not be disclosed without proper authorization. Inappropriate disclosure of information may expose to risks including, potential loss of revenue, fines, sanctions, and legal actions.

Scope The information covered in these guidelines includes, but is not limited to, information owned by or in the course of normal business activities provided to that is either stored or shared via any means, such as electronic information, information on paper, and information shared orally or visually (such as telephone and video conferencing).

Policy All information owned by or provided to in the course of normal business activities, shall be classified according to its level of sensitivity by the data owner or custodian in accordance to the Practices and Procedures of this policy. All information, once classified, shall be stored, backed-up, accessed, utilized, and destroyed in accordance to the Practices and Procedures of this policy. Management shall authorize the creation of an Information Sensitivity Awareness program, and the periodic implementation of the awareness program for all employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties. Management shall authorize the creation of an audit plan for the Information Sensitivity policy and the periodic implementation of the audit plan.



DRAFT 1


Practices All information owned by or provided to in the course of normal business activities is to be used for business purposes in serving the interests of the company in the course of normal business operations. Managers and Supervisors shall grant authorization to employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties, to access information at the appropriate level to meet their business functions. ’s InfoSec department shall manage the user roles and privileges as directed by department Managers and Supervisors. Information owners and/or custodians shall determine the sensitivity level of all information in their control, and classify it appropriately. Once classified, the information shall be managed, including stored, backed-up, accessed, utilized, and destroyed in accordance to the Practices and Procedures of this policy.

Procedures ’s management team shall create and maintain a list of sensitivity levels for all information owned by or provided to in the course of normal business activities. ’s InfoSec department shall modify this policy as directed by ’s management team to meet their corporate goals for Information Sensitivity. ’s InfoSec department shall create the procedural steps required to meet the Policy and Practices goals of this policy as defined by ’s management team.




Revision History



DRAFT 1


AGA 12-1 ANNEX H SYMMETRIC KEY MANAGEMENT METHOD REVISION 0.7

Submitted by Clay Weston Weston Technology

- – H-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1




DRAFT 1


TABLE OF CONTENTS 1

INTRODUCTION..............................................................................................................................................4

2

SCOPE ................................................................................................................................................................4

3

TERMS AND ABBREVIATIONS ...................................................................................................................4

4

ARCHITECTURE .............................................................................................................................................5

5

MASTER KEY...................................................................................................................................................5

6

KEY COMPONENTS .......................................................................................................................................6

7

SESSION ESTABLISHMENT KEY................................................................................................................6

8

DATA KEY.........................................................................................................................................................7

9

REMOTE KE ESTABLISHMENT PROTOCOL..........................................................................................7



DRAFT 1


INTRODUCTION This document describes a cryptographic key management method for use with SCADA and similar asynchronous serial communications link encryption devices. The method uses only symmetric (shared secret) keys. The primary goals of this method are: •

To establish and maintain an acceptable level of security throughout the life of the cryptographic system.

•

To minimize the burden imposed by key management on the SCADA communications links.

•

To minimize the inconvenience and complexity imposed on the user.

In a number of places this document refers to a user security policy. Refer to Annex G of AGA 12-1 for a model security policy.

SCOPE This document applies to SCADA and similar asynchronous serial links. This method is designed for communications links and systems with the following characteristics: •

Limited bandwidth. SCADA links operate at speeds as low as 300 baud. Common methods (for example, TLS) add overhead and delays that are likely to be unacceptable in many SCADA systems.

•

Limited scope of domain. This method relies on a degree of central control and authority that is not present in some applications, where many if not most users on a network may be independent agents.

•

Limited connections. This method is suited for the master/slave topology common to SCADA systems. It is also suited to “static peer-to-peer” topologies where relationships between peers are manually established. It is not suited to “dynamic peer-to-peer” topologies where any member of the network is able to establish a link with any other member.

TERMS AND ABBREVIATIONS The following table lists key terms and abbreviations used in this document. CM

Cryptographic Module

CMID

Cryptographic Module Identifier – a unique number contained in every AGA 12-1 compliant CM. The number can be read locally or remotely but it cannot be altered.

Data Key

An ephemeral key used to encrypt data.

DKT

see Key Transport Device

KD

see Data Key

KE

see Session Establishment Key

Key Component

One of two secret random numbers that are combined to produce a Master Key using split knowledge procedures

Key Escrow System

A system used to generate, store, and retrieve cryptographic keys and key materials securely for the purposes of installation, maintenance, and backup.



DRAFT 1


Key Transport Device

A special CM used to transport keys and key materials

KM

see Master Key

Master Key

A permanent key unique to each CM, used to establish Session Establishment Keys

Session

A period during which two Cryptographic Modules use a particular Data Key

Session Establishment Key

A long-lasting key used to establish secure sessions

ARCHITECTURE Systems using this key management method include three components. Cryptographic Modules (CMs) reside between a protected device (central computer, remote device, etc.) and a communications device such as a modem or radio. The CMs convert plaintext received from a protected device to ciphertext for transmission over the communications medium, and convert the received ciphertext back into plaintext for transmission to the protected device. A Key Escrow System is a central repository for cryptographic keys and key components. It should be kept in a secure location with closely guarded access. Every time a new CM is commissioned or a new link is established between two CMs, users must interact with the Key Escrow System to generate key components and/or Session Establishment Keys. The Key Transport Device (DKT) can be used to manually transport key components and Session Establishment Keys from Key Escrow System to a CM.

MASTER KEY Every CM contains a Master Key (KM). The method used to generate KM ensures a high probability that every KM is unique. KM shall: 1. Be used only to encrypt a KE. 2. Never be exposed in plaintext form. 3. Be generated by a Key Escrow System 4. Be transferred to a CM using a split knowledge procedure. 5. Be known only to one CM and to the Key Escrow System. 6. Be associated with the CMID of its CM for storage and transport 7. Remain valid until any of the following occur: a. The CM containing KM is lost, stolen, or otherwise compromised or suspected of compromise. b. The Key Escrow System is compromised or suspected of compromise. c. Any DKT or set of DKTs containing both components of KM is lost, stolen, or otherwise compromised or suspected of compromise. d. Reason arises to suspect that both components used to establish KM may have been revealed or stored in violation of the relevant security policy.



DRAFT 1


User security policy should address both the circumstances under which KM is revoked and the actions that are taken as a result. If KM becomes invalid for any CM, the following actions are recommended: 1. Purge the KM or permanently identify it as compromised in the Key Escrow System. 2. Replace the compromised CM or its KM. Remove the compromised CM from service until its KM is replaced. 3. Regard all KEs that were held by that CM as compromised. Follow the procedures described in Section 0 below for all compromised KEs.

KEY COMPONENTS Two Key Components are combined (by exclusive-or) in a CM and a Key Escrow System to produce a Master Key. Every Key Component shall: 1. Include a random number equal in length to the key for which it is a component, followed by a CCITT CRC-16 value computed over that number, with a seed value of FFFFH. 2. Be associated with a specific CMID. 3. Be accessible only to authorized entities. No single entity shall have access to both Key Components. Each random number shall be generated by a Key Escrow System in accordance with FIPS 140-2 Section 4.7.1.

SESSION ESTABLISHMENT KEY A Session Establishment Key (KE) is used to establish secure sessions. Every pair of communicating CMs shares a KE. KE shall: 1. Be used only to establish secure sessions. 2. Never be exposed in plaintext form. 3. Be generated by a Key Escrow System in accordance with FIPS 140-2 Section 4.7.2. 4. Be encrypted by the Key Escrow System using the KM of each CM into which it will be loaded. 5. Be established locally, or remotely using the procedure specified in Section 0 below. 6. Remain valid until any of the following occur: a. A preset number of KDs have been exchanged using the KE (optional). Expiration is not equivalent to compromise. b. A preset time has elapsed since the KE was first established (optional). Expiration is not equivalent to compromise. c. Any CM using the KE is lost, stolen, or otherwise compromised or suspected of compromise. User security policy should address both the circumstances under which KE is revoked and the actions that are taken as a result. If any KE is compromised, the following actions are recommended: 1. Purge the KE or permanently identify it as compromised in the Key Escrow System. 2. Replace the KE in every CM where it resides. 3. Immediately close all sessions whose KD was exchanged using the KE.



DRAFT 1


DATA KEY A Data Key (KD) is used to encrypt encapsulated data and protocol information exchanged between two CMs. A new KD is established for every communications session. KD shall: 1. Be used for all data encryption within a session. 2. Never be exposed in plaintext form. 3. Be generated by a CM in accordance with FIPS 140-2 Section 4.7.2. 4. Be encrypted by the CM using a KE for session establishment. 4. Be established locally or remotely. A procedure for remotely establishing KD is described in AGA 12-1 Annex K; SCADA Link Security Protocol Specification. 5. KD shall remain valid until any of the following occur: a. A preset number of messages have been exchanged using one KD. Expiration is not equivalent to compromise. b. A preset time has elapsed since KD was established. Expiration is not equivalent to compromise. c. Any CM using KD is lost, stolen, or otherwise compromised or suspected of compromise. d. KD is suspected to be compromised for any reason. User security policy should address both the circumstances under which KD is revoked and the actions that are taken as a result. If any KD is compromised, all sessions using that KD should be terminated.

REMOTE KE ESTABLISHMENT PROTOCOL This section describes a cryptographic protocol allowing one CM (CM_A) to establish a Session Establishment Key (KE) in another CM (CM_B). Conventions: •

KM_n is the Master Key of CM_n

•

EKM_n [ x ] means “encrypt x using key KM_n”

•

HASH is computed over the entire message, including the plaintext part (if any).

•

NONCE_X and NONCE_Y are 8-byte random numbers used only to introduce a difference when KE is encrypted with two different KMs.

•

NONCE_A and NONCE_B are 8-byte random numbers exchanged to ensure that messages are fresh (not replayed).

1. CM_A is supplied with: EKM_A [ KE , NONCE_X ] and ( CMIDCM_B , EKM_B [ KE , NONCE_Y ] ) 2. CM_A => CM_B: CMIDCM_B , EKM_B [ KE , NONCE_Y ] , EKE [ NONCE_A , CMIDCM_A , HASH ] 3. CM_B => CM_A: CMIDCM_A , EKE [ NONCE_A , NONCE_B, CMIDCM_B , HASH ]



DRAFT 1


4. CM_A => CM_B: CMIDCM_B , EKE [ NONCE_B , CMIDCM_A , HASH]

-



DRAFT 1


AGA 12-1 ANNEX I CRYPTOGRAPHIC SYSTEM TEST PLAN (Normative) REVISION 0.5


- – I-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


Introduction The purpose, scope, objectives, intended use, and maintenance of this test plan are described.

Purpose The purpose of the cryptographic system test plan (CSTP) is to define test and evaluation requirements to measure performance characteristics introduced by integrating cryptographic modules (CM) for SCADA communications security, and to evaluate design compliance to the cryptographic module functional requirements specified in AGA Report 12. The recommendations may also apply to certain Distributed Control Systems (DCS).

Scope The scope of the CSTP includes test and evaluation plans for all configurations of cryptographic modules designed to meet the requirements specified in AGA Report 12.

Test and evaluation objectives The primary test and evaluation objectives are: 1. Measure and evaluate the performance characteristics introduced by integrating cryptographic modules into communication paths. 2. Measure and evaluate the CM application features/functions required to implement various levels of SCADA communication protection. 3. Perform regression tests and reliability tests to evaluate performance and to evaluate potential bottlenecks introduced by the cryptographic modules. 4. Evaluate the interoperability of cryptographic modules provided by different manufacturers or different versions of cryptographic modules provided by the same manufacturer.

Intended use for the cryptographic system test plan Primary and other uses of this test plan are described.

Primary use The primary use of the CSTP is to support development and configuration of facilities, and detailed procedures that will be used to perform the tests. Detailed test procedures for each facility (manufacturer, independent test and evaluation, certification, user) and test configuration will include a compliance table to the requirements specified in this test plan.

Other uses An intended use of this test plan is to provide input to other AGA/GTI subcommittees about the most common test and evaluation requirements for configurations and capabilities of existing field computers and SCADA systems used in the gas, water/waste water, pipeline, and electric



DRAFT 1


industries. Users and manufacturers will use these test and evaluation guidelines to help them determine whether encryption can be embedded in their field systems. The test plan also may be used to help establish platform product independent test and evaluation procedures for evaluating encryption implementations in existing systems.

Maintenance of this document AGA Report 12 will evolve to include lessons learned from test and evaluation, as well as user experience with deployed cryptographic solutions. Commensurate with changes in AGA Report 12, this test plan will be updated.

References 1. AGA Report 12 “Cryptographic Protection of SCADA Equipment”, to be published. 2. IEEE C37.115 “Standard Test Method for Evaluation of Message Communications between IEDs in Substations”, to be published. 3. American National Standard for Financial Services X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation." American Bankers Association, Washington, D.C., July 29, 1998. 4. FIPS Publication 46-3, "Data Encryption Standard (DES)." U.S. DOC/NIST, October 25, 1999. 5. FIPS Publication 81, "DES Modes of Operation." U.S. DOC/NIST, December 1980. 6. FIPS Publication 180-1, "Secure Hash Standard." U.S. DOC/NIST, April 17, 1995. 7. FIPS Publication 186-2, "Digital Signal Standard (DSS)." U.S. DOC/NIST, January 27, 2000. 8. FIPS Publication 197, "Advanced Encryption Standard (AES)." U.S. DOC/NIST, November 26, 2001. 9. FIPS Publication 198, "The Keyed-Hash Message Authentication Code (HMAC)." U.S. DOC/NIST, March 6, 2002. 10. NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques," 2001 Edition. 11. Description of Known Answer Tests and Monte Carlo Tests for Advanced Encryption Standard (AES) Candidate Algorithm Submissions, January 7, 1998. 12. Gould Modicon Modbus Protocol Reference Guide – PI-MBUS-300 Rev A, November 1983. 13. Modicon Modbus Protocol Reference Guide - PI-MBUS-300 Rev. J, June 1996 14. DNP V3.00 Data Link Layer Protocol Description, P009-0PD.DL, September 1991. 15. DNP V3.00 Application Layer Protocol Description, P009-0PD.APP, August 7, 1991. 16. DNP V3:00 Data Object Library, P009-OBL, October 8, 1992. 17. DNP V3.00 Application Layer Protocol Description, P009-0PD.APP, August 7, 1991. 18. Federal Standard 1037C, Telecommunications: Glossary of Telecommunications Terms.



DRAFT 1


19. ANS T1.523-2001, Telecom Glossary 2000 (replaces Federal Standard 1037C)



DRAFT 1


Test requirements and evaluation criteria Test requirements and evaluation criteria are defined for functional tests, performance tests and operability tests. Functional and performance requirements Functional and performance requirements are described to evaluate compliance with the cryptographic module design requirements, to describe CM application/functional testing, synchronization testing, and requirements to measure performance characteristics.

Evaluation of compliance with cryptographic module design requirements As a minimum, a CM manufacturer shall perform Known Answer Tests (KATs) and Monte Carlo Tests (MCTs). KATs are designed for Electronic Code Book (ECB) mode implementation. MCTs are designed for ECB and Cipher Block Chaining (CBC) mode implementations15. •

Encryption tests shall include the serial input of plaintext, serial output of cipher text, and validation and independent verification of the encryption using some accepted source such as a trusted third-party program or NIST test vectors [3,4,5,6,7,8,9,10].

•

Decryption tests shall include the serial input of cipher text, serial output of plaintext, and validation and independent verification of the decryption using some accepted source such as a trusted third-party program or NIST test vectors [3,4,5,6,7,8,9,10].

Supplying known plaintext to the plaintext interface of the DUT and comparing the ciphertext shall evaluate the encryption function. Validation of encryption and decryption requires that the cryptographic protocol be well understood.

Application feature/functional testing Features of the cryptographic module applications and underlying communication protocol that may be affected by network load; traffic patterns (e.g., polling sequence), or data volume should be included in functional testing. The testing process should install on the server applicable background messages, and specific test scripts to exercise CM functions under test.

Test measurements The objective of the tests is to verify that the operation of the CM feature under test completed successfully. Before starting each test there must be a defined procedure for accomplishing test verification. When a single CM performs an operation, it should be easy to determine that it completed successfully by verifying presence of output. When two or more CMs operate over a communication network, data volume and timing issues often make verification more difficult and may require automated data reduction and analysis. In addition to checking that a specific CM function happened, it is also important to validate that other functions, specifically, the process used to create the message load on the CM, also functioned properly.

15

Test values are described in the file rijndael-vals.zip, which is available from http://csrc.nist.gov/encryption/aes/rijndael/rijndael-vals.zip.



DRAFT 1


Test configurations All test configurations are emulated. The test configuration should include communication speed between the application processor (RTU, field device, or SCADA master) and at least two CMs that represent the target field installation. A target field installation may have the capability to send messages from the application processor to the CM at a higher speed than the communication speed between CMs. In a network configuration, a sufficient number of application processors should be included to create a heavy load on the receiving CM.

Load model Functional testing requires that the test be conducted with a heavy credible loading16 against the CMs. Test scripts that exercise the CM feature-under-test and its converse operation (encryption versus decryption) are needed. The functional test scripts typically run for one iteration, and it may be easier or required to start all test scripts concurrently. In this case, the functional test scripts must run long enough to ensure that the CM is heavily loaded when the actual test occurs. This can be accomplished by having a delay in the start of the functional test script, or by performing “dummy” commands for the first few seconds while the background test scripts create a heavy credible CM load.

Synchronization testing Synchronization testing is described in terms of clock synchronization test, CM jitter test, and CM protocol synchronization test.

Clock synchronization test Clock synchronization test should first be performed without cryptographic modules. The accuracy of clock synchronization should be measured. The test should be repeated with cryptographic modules in place, and the differences measured.

CM jitter test When multiple field devices that share common data, automated and reliable data distribution serve a SCADA Master or updates are critical to application data integrity and system operation. The test should measure the elapsed time between the exits of the first bit from the sending protected device to arrival of the last bit at the receiving protected device. This test should be repeated with and without the cryptographic modules, and standard deviation compared.

CM protocol synchronization test If the CM permits recognition and/or negotiation between CMs to allow the addition of new or alternate CMs to an established pair, the time to bring the new or alternate CM on line should be measured.

Requirements to measure performance characteristics Timing measurements, block length probing, throughput testing, throughput measurements, performance test configurations, and load model are described to measure performance characteristics. 16

This will include at least a test of operation under continuous polling. For multidrop applications a sufficient number of remote units should be included in the test to evaluate scaling (incremental effect on bandwidth and robustness).



DRAFT 1


Timing measurements Any timing reported by the module firmware or vendor software shall be independently checked for reasonableness. For example, the time required to encrypt a block of data in ECB mode can be checked by measuring the time from the start of plaintext transmission to the module until the completion of cipher text transmission from the module. After subtracting the transmission times, the result should be equal to the encryption time plus any internal overhead of the module. Block length probing

Cryptographic modules using block algorithms distribute encapsulated data (hereafter referred to as payload) into blocks. The amount of payload that will fit into a block is equal to the block size minus the CM overhead for that block. The CM overhead may vary depending on the location of the block within a message. Typically, four cases characterize the cryptographic system. • A single-block message • The first block of a multi-block message • The last block of a multi-block message • The middle block(s) of a message spanning three or more blocks For messages spanning from one to a few blocks, performance of the cryptographic system is strongly dependent on how the payload fits within the block structure. For example, if the cryptographic system can fit a maximum payload of 12 bytes into a single-block message, a payload of 12 bytes can be transmitted in approximately half the time required for a payload of 13 bytes. It is important that the testing entity recognize these block boundaries to assess their impact on testing and/or operation with the cryptographic system. A method for identifying the block boundaries is outlined below. This method assumes a block length of sixteen bytes. It can be modified for other block lengths. Send a sequence of messages with monotonically increasing length, from one byte to 48 bytes. For each message, record the total time from the exit of the first bit from the data source until the arrival of the last bit at the data sink. Calculate the delta for each step change in the message length. The step change should be virtually identical within a block boundary. When the message length crosses a block boundary, the step change will dramatically increase. Subsequent step changes should be virtually identical until the next block boundary is reached. Block boundaries should occur as the payload size approaches multiples of the block size. The boundaries should be identified for messages spanning one, two, and three blocks. This information can be extrapolated to longer messages by adding middle blocks as required.

Effect of message content on latency For a given message length, comparing the average and standard deviation of various data patterns should reveal any variation due to message content. Calculate latency averages and standard deviations for each data pattern and message length. Test patterns can be used in place of actual native protocol messages. Following are example test patterns with bytes containing: •

All zeros

•

All 1’s

•

Alternating 1’s and zeros with bit zero =1



DRAFT 1


•

Alternating 1’s and zeros with bit zero =0

•

Ascending binary count

•

Descending binary count

•

Random values.

Throughput testing Throughput testing is used to measure the maximum sustainable rate of SCADA messages per hour (MPH). A large number of transaction requests will stress the CM’s ability to buffer the incoming messages, encrypt the message, and buffer the encrypted message to be sent to the receiving CM.

Throughput measurements Throughput in payload bits per second is expected to be dependent on message length, due to block padding and other overhead. Since it is desirable to treat the CM as a black box, ideally the throughput would be measured for every realistic message length. Measurements should be made at expected bauds to be used. If throughput testing cannot be automated, and the size of the largest block is known, it should be sufficient to measure throughput for messages up to three blocks long, with extrapolations based on the throughput of the middle block (since the first and last blocks may have special overheads). The delta time between a two and a threeblock message (because the two block message has first and last blocks) should be measured. Units for reporting throughput should be bits per second and messages per second. Alternatively, reporting the inverse of the throughput (seconds per message) makes it easier to compute polling intervals, and also coincides with the definition of latency used here. Performance test configurations All test configurations are emulated. The same configuration should be used for response time and throughput. If field devices are distributed across different segments and interconnecting paths include slow speed links that could affect performance, these are included in the test configuration to measure their impact on throughput. If errors are detected during the test, they have to be investigated. If a problem is found, the tests must be rerun to get relevant response time measurements. Baseline configuration The baseline test configuration should not include CMs or any loading other than that introduced from application processors. This configuration establishes the maximum MPH over the communication path. Baseline with CMs Test configurations that include CMs will be used to measure the realized MPH over the same communication path. Baseline with CMs and other loads Test configurations that include CMs and other loading will be used to measure the realized MPH over the same communication path. Degradation Degradation shall be reported as the realized MPH divided by the maximum MPH.



DRAFT 1


Load model Load models can be created to measure CM throughput. All CM transactions (poll request and response) should be handled from cached data. Reading the same record over and over across all application processors in the test can do this. This allows maximum transaction load to be achieved with minimal hardware. Evaluation of the effect of noise on CM performance CMs should be tested to determine the effect of message corruption on performance: 1. On the bench, replace the null modem connecting the CMs with a device that digitally modifies the serial data passing through it. This device simulates errors resulting from communication channel noise that the modem could not ignore or correct. 2. Under appropriate traffic conditions, determine how message delivery is affected (additional latency, or non delivery altogether) by manipulation of message bits. The tests could include the introduction of a single bit error per message, multiple bit errors per message, and the introduction of an extra byte. If the message was not delivered during step 2, determine if there is a dead period during which messages are ignored or buffered for later transmission. The dead period should be measured by sending an additional message delayed a variable amount after the corrupted message. Susceptibility to adverse conditions If appropriate, the CM should be tested to determine its ability to withstand (and perhaps even function despite) specific environmental conditions, such as transients, discharges, RF radiation, or extremes of humidity or temperature. IEEE P1613 describes some such tests. Operability tests Operability tests should be designed to perform regression testing, reliability testing, and provide the capability to identify and isolate bottleneck problems. Regression testing Regression testing is not one test, but a series of tests that measure critical aspects of the CM under test. For each new release of CM software and hardware, regression testing ensures that the upgrade will function properly prior to deployment. A regression test plan identifies which new basic test objectives should be run against each new CM product release. CM regression testing can verify that a hardware or software upgrade does not impact performance, reliability, or functionality of the cryptographic system. Regression testing does not measure new features or capabilities. Such tests fall under functional testing discussed in Sections 0. Use test data from past regression test as a baseline for the current regression test. If no current data exists, first run test against the current cryptographic system before testing the upgrade. Without a baseline against which to compare the CM upgrade, it cannot be determined that the cryptographic system has been improved or regressed. Reliability testing



DRAFT 1


Reliability testing forces the CM, or the cryptographic system, under test to handle in a compressed time the activity it would normally experience over weeks, months, or years in operation. The testing may use accelerated loading techniques to apply and maintain high load on the CM for prolonged periods of time (30 hours or more). Reliability testing attempts to accelerate failure of the CM or cryptographic system caused by: Cumulative errors: These are the result of repeating an operation multiple times in a fashion that results in an error. Timing errors: These errors are caused by two time-dependent operations that occur out of sequence or without proper delay. Statistical errors: It is virtually impossible to test and verify every possible path through the CM’s code. However, statistically, over time, every path will be traversed, either because of an error condition or a seldom-invoked sequence of events. Reliability testing increased the probability that a statistical error will occur. Cryptographic system reliability testing measures how well the CMs maintain operation under various loads and feature configurations. Test measurements Reliability testing provides three key measurements: Operational reliability: Cryptographic system operation under maximum sustained load. Stressed reliability: Cryptographic system operation under peak load. Reliable recovery: Time to reestablish normal cryptographic system operation after non-fatal faults (e.g., adverse environmental conditions or loss of power supply). The first measurement determines how reliable the cryptographic system is under a sustainable load where virtually all received messages are correctly forwarded to the destination. The second measurement determines how stable the cryptographic system is under peak loads. Operational reliability requires the cryptographic system to be stable for a long time at medium to heavy loads. Under stressed reliability, cryptographic systems can almost always be forced to fail; it is the mode of failure and recovery (e.g., fail-safe) that are important. Typical results could show: •

The cryptographic system cannot maintain the sustained load for long periods.

•

The cryptographic system can maintain sustained loads, but fails under peak loads.

•

The cryptographic system can maintain both sustained and peak loads.

•

The cryptographic system encounters noncritical or recoverable errors under one or both loads.

•

The cryptographic system encounters fatal errors under sustained loads.

Test configurations All test configurations are emulated. The test configurations must represent the most critical or typical operational communication network configurations. Testing should be divided into two configurations:

- –I-10 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


•

Unidirectional testing consists of a continuous stream of messages applied to one CM. In the diagram below, DATA SOURCE is configured to send one message after another without intervening delay beyond the minimum inherent in the test system. DATA SINK is configured to collect statistics, but not to respond to the messages. DATA SOURCE

•

CM1

CM2

DATA SINK

Bi-directional testing consists of a continuous sequence of message pairs, where a message from DATA SOURCE 1 is immediately followed by a message from DATA SOURCE 2, without intervening delay. The cycle is repeated when DATA SOURCE 1 sends its message again (or a different message) immediately after receiving the message from DATA SOURCE 2, again without intervening delay. DATA SOURCE 1

CM1

CM2

DATA SOURCE 2

Load model The reliability test load model can be developed from either the operational communication network baseline, or from throughput test results. Throughput load model If one use uses the throughput load model, reliability testing measures the cryptographic system relative to the sustained and maximum throughput based on throughput test results. It is a more conservative measurement than used for the baseline load model, and automatically factors in communication network traffic growth. As throughput tests measure cryptographic system capacity, this test effectively measures “stress capacity.” Operational and peak loads are from the baseline load model results. Sustained and maximum are from the throughput model results. The difference indicates the capacity of the cryptographic system to reliably handle additional load. This is the preferred method of reliability testing. If the cryptographic system fails this test, it can be re-tested using the baseline load model to determine if it can handle existing communication network traffic. This testing provides a margin of comfort that the baseline modeling does not. Another advantage of using this model is that the load scripts can be reused from throughput testing. Load modeling bursty traffic During a reliability test, the loading should not be constant, but bursty, as is typical of most communication network transmissions. This can be done using two techniques: •

Create a load script that varies the number of messages forwarded from the source to the destination.

•

Vary the messages per second (MPS) rate or number of load generators concurrently running.

Make sure that when using bursty traffic, the average MPS rate measured over a specified time increment is equal to the load model average and peak MPS rates for operational and stressed reliability, respectively. Baseline load model



DRAFT 1


If one uses the baseline load model, reliability testing measures the reliability of the cryptographic system under test relative to the current operational system loading. It tells how the cryptographic system will work, if there are no changes in the operational communication network traffic or load. If throughput testing hasn’t been conducted on the cryptographic system, this is the best load model to use. Bottleneck identification and problem isolation The addition of cryptographic protection has the potential for creating a bottleneck in SCADA communications. To determine whether a bottleneck may exist, refer to the manufacturer’s specification of the maximum sustained throughput for each component through which the data must travel. It may be necessary to convert or interpret the specifications to derive a common measure (such as bits per second) for all of the components. If the full data stream must pass through a CM and it has the lowest rated throughput, it represents a theoretical bottleneck. In reality, a component is only a bottleneck if it impedes operation. A component may be capable of operating at a peak rate adequate to meet the requirements of the SCADA system, or the SCADA system may not exercise the full system throughput capability. For the cryptographic system, operating the SCADA system under worst-case conditions both with and without the cryptographic system, and comparing the results can determine this. In some cases, when the cryptographic system creates a bottleneck, the problem can be alleviated using configuration options. For example, the interface between a CM and its associated computer (the plaintext port) may be capable of operating at a substantially higher speed than the communication link (on the ciphertext port). This type of asymmetric operation can dramatically reduce delays associated with filling and emptying the CM buffers.

Interoperability testing Interoperability testing requires a test configuration with CMs from different vendors, or different CM versions from the same vendor. Application feature/functional testing described in Section 0 should be run with this configuration.

Special test setup requirements Test setup to determine appropriate values for SCADA communication parameters affected by the addition of cryptographic protection is described in general, and in terms of unique requirements for specific native protocols. Communication channel parameter considerations Communication channel parameters are described in terms of general considerations and key channel characteristics. General considerations In order to test the effects of CM security on communications channels it may be necessary to adjust some of the channel timing parameters in either the sender, receiver or both. SCADA channel parameters are often customized to suit the specific requirements of the channel. Changes could be required affecting time-out, channel turn-on, turn-off, turn around and squelch times. Timing changes to accommodate CM security may significantly alter channel characteristics. Changes should be recorded as part of the test documents. Key channel characteristics



DRAFT 1


Some field devices respond to requests faster than others. Typical RTUs are ready to begin a response within a few milliseconds. However, communication channel equipment may introduce addition delay. For example, it is common practice to key up a radio transmitter or wire line, wait for the receiver to open, and wait for the path to settle down before the response begins. This is sometimes referred to as the pre-transmission (PT) mark. The receiver, to synchronize to the serial channel, also uses the PT mark. PT marks are often set at 8 ms, but can be as long as 50 ms, maybe longer when a Multiple Address System (MAS) repeater is used for example on a 900mHz radio channel. At the end of the message there is often a need to hold the channel at mark for a short period of time so the receiver can decide the message has ended. This is sometimes referred to as the post mark. Post marks typically have delays based on the time to send two bytes of data, some even longer. Radios (MAS17 and spread spectrum) need long PT marks and post marks. They also need time for the slave radio to go from transmit to receive and back again. Modbus time-out parameter assignment Modbus is a poll-response data communications protocol that defines “no response” as a valid response. Therefore, time-out is an issue relevant to Modbus. [12] One master on a channel polls one or more remote devices on that channel. If the protocol requires a response to a particular poll, at most one remote will send the required response back to the master. If a remote detects a master poll that has been corrupted, the remote will not respond. Therefore, the master must be configured to assume that an error has occurred if an expected response is not received within a predetermined time. This time will depend on a number of factors, including channel baud rate, type of poll, and the processor speed of the remotes. A single master time-out parameter is often set based on the longest response delay that the master will encounter on the channel. If this parameter is set too short, the master will stop listening too soon and some remote responses will be missed. If it is set too long, the master will be forced to wait longer than necessary every time noise corrupts a poll, reducing the channel scan rate. A simple trial-and-error approach can be used to find the smallest master time-out parameter that avoids missed remote responses on a channel. During a bench test of maximum throughput in a noiseless environment, there should be a onefor-one poll-response relationship. Therefore, the master time-out parameter can simply be set to a large value for the duration of the test. If a cryptographic system is inserted between the master and the remotes on a channel, the poll-response delay characteristics may change. Accordingly, a new master time-out parameter should be determined after insertion. The time-out parameter used during a test should be documented as part of the test environment.

Test reports 17

These are usually 900-mHz radio, which are very common on electric power distribution feeder applications and water distribution systems. But, they are being replaced with spread spectrum radios that do not require FCC licensing.



DRAFT 1


Test reports are described to clearly state who has ownership of the test and evaluation results, and to describe the template for a standard report format. Ownership of test results Test and evaluation results of proof-of-concept and prototype cryptographic modules are owned by the manufacturer. These results will not be published in any form without the express written permission of the manufacturer. The sponsor of the test owns test and evaluation results of production cryptographic modules. These results may be published without written permission of the manufacturer. Standard report format Feature/functionality test results related to a specific test procedure will be reported as not supported, not applicable, pass, or fail with optional qualifying remarks. Performance and operability test results related to a specific test procedure will be reported in terms of measured results, statistical significance measures, and optional qualifying remarks.

Test architecture and environment Test architecture that identifies clearly those components classified as the device under test (DUT) or system under test (SUT), and those components classified as the test environment shall be specified in the test procedures. Test environment describes equipment, software, and documentation will be provided by the vendor and by the test facility. Engineering test platforms for test management and IED emulation needed to support the tests will also be described.



DRAFT 1


AGA 12-1 ANNEX J SAMPLE PURCHASE ORDERS AND DISCUSSION OF THE IMPLICATIONS (Informative) REVISION 0.1


- – L-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


1. Purpose The purpose of this discussion is to help the technical person who will be responsible for specifying cryptographic protection for DCS or SCADA systems to select appropriate equipment. This discussion is based on the assumption that the reader has a reasonable understanding of entire AGA 12-1 report. On finishing this annex, the reader should be able to choose among different options within AGA 12-1 and specify a system that meets the objectives of the cryptographic protection. 2. General Comments This standard has been developed with great effort to achiever consistency and correctness and to balance cryptographic protection with the constraints of the SCADA and DCS environments. However, it was not possible to find existing protocols that met the constraints imposed by existing systems. This necessitated developing a new protocol and a new key management protocol. While these were patterned as closely as practical on existing and well-tested protocols, they differ from the established methods to make operations less demanding on small processors and slower communication links. Experience suggests that such new protocols may have security holes that will be uncovered as they are tested in the field and subject to scrutiny by the cryptographic community. 3. AGA 12-1 Users' Group An AGA 12-1 Users' Group is being formed so that users of this document have an opportunity to exchange experiences and lessons learned. This information will also be made available to manufacturers and the standard developers so that they can provide better quality products, conform more carefully to AGA 12-1, and modify the standard to enhance security and performance. Companies that use cryptographic modules that conform to AGA 12-1 may wish to consider participating in the Users' Group. The group is also developing a web site at @@ list web address @@ to provide current information on the AGA 12-1 standard. Selecting products that incorporate approaches that are being reviewed by the AGA 12-1 Users' Group and are to be submitted as possible open standards help assure that potential flaws will be detected during the review period and that the capability will be more widely supported and interoperable after adoption as an open standard. During the period between the initial adoption of AGA 12-1 and finalization of a compliance certification process, the AGA 12-1 Users' Group web site will list results of various tests of CMs that are stated by their manufacturer to be designed to comply with AGA 12-1. 4. Purchasing Specification Consideration AGA 12-1 does not specify all possible approaches to cryptographic protection of SCADA communication links. Those approaches, which are required and/or recommended, are believed - – L-2 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


to represent sound cryptographic practice. The fact that a particular approach is not included by AGA 12-1 does not necessarily indicate that it is not a secure approach. However, if a supplier offers a particular option that is not addressed within this report, potential purchasers may wish to consider that the supplier request that the approach be reviewed by the AGA 12-1 User's Group. If suppliers suggest specific approaches to cryptographic feature or capabilities, these approaches will 1) be reviewed by the community of AGA 12-1 users and developers and the approach can be either approved or improved and 2) will become a candidate for future incorporation into AGA 12-1, increasing the interoperability of AGA 12-1 compliant modules. While AGA 12-1 does not require the ability to upgrade software, purchasers should consider this to be a desirable feature. It is likely that AGA 12-1 will evolve as subsequent standards are developed for use in embedded systems and to incorporate new features and higher levels of interoperability. If it is not possible to upgrade CM software, it will be necessary to replace the CMs if the upgrades are desired. It is the ultimate intent of this Annex to provide examples of purchasing specification language that experience has shown adequately describes secure products that meet the cryptographic requirements of SCADA and DCS operators and that complies with AGA 12-1. Because this is the first draft of this standard, this is not yet possible. However, this information will be made available on the AGA 12-1 Users' Group web site as members share their experiences. 4. Operational Considerations It should be a part of your corporate security policy to maintain a secure room. This is not included as a part of the model security policy, but should at least include a facility with access restricted only to those who are authorized to perform specific cryptographic roles. Secure system operation and policy will require audits of the forensic counters to search for evidence of possible cyber-attacks. System operators should identify the conditions under which various kinds of attacks are likely to manifest themselves with these counters. These results might be shared with other system operators or through the Users' Group. Note that "mixed mode" operation (cases in which the same communication link simultaneously carries both ciphertext and plaintext) may be both convenient and risky. The convenience arises during the period when CMs are being installed and some are cryptographically protected while others are not. This is also convenient in situations in which it is economically justified to protect some points, but not all. However, the fact that both plain and cipher text can possibly travel through the same port is a clear security risk because there is always a possibility that cleartext will be transmitted unintentionally. This cannot happen if cleartext is never allowed on this port. Those system owners who opt for the mixed mode should carefully weigh the risks against the benefits.

- – L-3 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


AGA 12-1 ANNEX K SCADA LINK SECURITY PROTOCOL SPECIFICATION REVISION 0.6

- – K-1 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


TABLE OF CONTENTS 1

INTRODUCTION..............................................................................................................................................4

2

CONVENTIONS................................................................................................................................................4

3

REFERENCES...................................................................................................................................................4

4

TERMS AND ABBREVIATIONS ...................................................................................................................4

5

PROCEDURES ..................................................................................................................................................5 5.1 5.2 5.3

6

SESSION ESTABLISHMENT ..................................................................................................................5 SECURE DATA TRANSFER ...................................................................................................................6 SESSION TERMINATION .......................................................................................................................7

MESSAGE ENCRYPTION ..............................................................................................................................7 6.1 KEYS..........................................................................................................................................................7 6.2 INITIAL VECTOR ....................................................................................................................................7 6.3 PADDING ..................................................................................................................................................7 6.3.1 CRC IN LAST BLOCK...........................................................................................................................8 6.3.2 HASH IN LAST BLOCK ........................................................................................................................8

7

MESSAGE ACKNOWLEDGEMENT ............................................................................................................8

8

ERROR DETECTION ......................................................................................................................................9

9

MESSAGE INTEGRITY ..................................................................................................................................9 9.1 9.2

10

TRUNCATION ........................................................................................................................................10 HOLDBACK............................................................................................................................................10

MESSAGE STRUCTURES ............................................................................................................................10 10.1 OPN MESSAGE STRUCTURE ..............................................................................................................10 10.2 ACK MESSAGE STRUCTURE..............................................................................................................11 10.2.1 ACK MESSAGE STRUCTURE FOR SESSION ESTABLISHMENT...............................................11 10.2.2 ACK MESSAGE STRUCTURE FOR DTA AND CLS MESSAGES.................................................11 10.3 CLS MESSAGE STRUCTURE ...............................................................................................................12 10.4 DTA MESSAGE STRUCTURE ..............................................................................................................12

11

MESSAGE FIELDS.........................................................................................................................................13 11.1 CONTROL ...............................................................................................................................................13 11.1.1 (M)ORE FIELD ..............................................................................................................................13 11.1.2 (R)ESULT FIELD ...........................................................................................................................13 11.1.3 ID FIELD ........................................................................................................................................14 11.1.4 OPN MESSAGE CONTROL BYTE .................................................................................................14 11.1.5 ACK MESSAGE CONTROL BYTE .................................................................................................14 11.1.6 CLS MESSAGE CONTROL BYTE ..................................................................................................14 11.1.7 DTA MESSAGE CONTROL BYTE .................................................................................................14 11.2 CMID........................................................................................................................................................14 11.3 SESSION_INFO.......................................................................................................................................14 11.3.1 DATA TRANSFER SESSION TYPE ................................................................................................16 11.3.2 MANAGEMENT SESSION TYPE ...................................................................................................16 11.3.3 FORENSIC SESSION TYPE ...........................................................................................................16 11.3.4 VENDOR-SPECIFIED SESSION TYPE .........................................................................................16 11.4 SESSION_ID............................................................................................................................................16



DRAFT 1


11.5 11.6 11.7 11.8 11.9 11.10 11.11

PASSWORD ............................................................................................................................................16 VENDOR_DATA ....................................................................................................................................17 ERROR_CODE........................................................................................................................................17 ERROR_DATA........................................................................................................................................17 NONCE_A ...............................................................................................................................................17 KD ............................................................................................................................................................17 USER_DATA...........................................................................................................................................17



DRAFT 1


1

INTRODUCTION

This document describes the SCADA Link Security (SLS) protocol. SLS is designed to efficiently encapsulate data on SCADA and similar asynchronous serial links, and to support the exchange of management information between cryptographic modules.

2

CONVENTIONS

For the purposes of this document, session refers to an SLS secure session. When more general reference is made to an exchange of messages that may or may not be an SLS secure session the term communications session is used. For explanatory purposes two hypothetical cryptographic modules designated CM_A and CM_B are used as examples throughout this document. Generally, CM_A is the originator of the process being described, but the designations do not imply any actual difference between the two CMs. Multi-byte variables used with SLS shall be represented in big-endian format. Items enclosed in {} are optional.

3

REFERENCES 1. American Gas Association Report 12-1 “Cryptographic Protection for SCADA Communications” Annex M: “Symmetric Key Management Method” 2. National Institute of Standards and Technology FIPS 140-2 “Security Requirements for Cryptographic Modules” 3. National Institute of Standards and Technology FIPS 180-2 “Secure Hash Standard” 4. National Institute of Standards and Technology FIPS 197 “Advanced Encryption Standard” 5. National Institute of Standards and Technology SP 800-38A “Recommendation for Block Cipher Modes of Operation”

4

TERMS AND ABBREVIATIONS

The following table lists key terms and abbreviations used in this document. AES

see Advanced Encryption Standard

Advanced Encryption Standard

The algorithm used by SLS for data encryption. See Reference 4.

CBC

see Cipher Block Chaining

Cipher Block Chaining

A method of linking successive encryption operations

CM

Cryptographic Module

CMID

Cryptographic Module Identifier – a unique number contained in every AGA 12-1 compliant CM. The number can be read locally or remotely but it cannot be altered.

Data Key

An ephemeral key used to encrypt data.

E_Kn

Encrypted using key Kn

Initial Vector

A 16-byte value used to begin some encryption processes, including CBC



DRAFT 1


IV

see Initial Vector

KD

see Data Key

KE

see Session Establishment Key

Nonce

A value used no more than once for the same purpose. For SLS, a sufficiently large random number (8 bytes or longer) is considered adequate.

Secure Hash Algorithm

A method of creating a “fingerprint” of a message, known as a hash, used to detect alteration of the message. See reference 3.

SHA-1

see Secure Hash Algorithm

Session

A period during which two Cryptographic Modules use a particular Data Key

Session Establishment Key

A long-lasting key used to establish secure sessions

5

PROCEDURES

The primary function of SLS is to securely exchange encapsulated data. In order to accomplish this, secure sessions must be opened and closed. This section describes the procedures used by SLS to perform these functions.

5.1

SESSION ESTABLISHMENT

All SLS communications are within the context of sessions. The SLS session establishment procedure accomplishes the following in a single exchange of messages: •

Verifies that the two CMs establishing the session are authorized to communicate with each other

•

Establishes a data key

•

Verifies the data key

•

Establishes an Initial Vector (IV)

•

Prevents session replay (where one side of an entire session is recorded and later played back)

The table below summarizes the session establishment procedure. STEP

DESCRIPTION

REFERENCE

1

CM_A generates NONCE_A

Section 11.9

2

CM_A encrypts ciphertext part of OPN message E_KE [ NONCE_A, CMID_A, OTHER DATA, HASH ] using IV = 0

Section 6 Section 10.1

3

CM_A transmits OPN message to CM-B

4

CM_B decrypts ciphertext part of OPN message

Section 6

5

CM_B checks HASH

Section 9



DRAFT 1


If hash is invalid, CM_B does not respond to OPN message; this procedure is terminated 6

CM_B generates KD

Section 11.10

7

CM_B computes HASH of ACK message including NONCE_A, then deletes NONCE_A from ACK

Section 10.2.1

8

CM_B encrypts ciphertext part of ACK message

Section 6

E_KE [ KD, CMID_B, OTHER DATA, HASH ] using IV = 0 9

CM_B transmits ACK message to CM-A

Section 10.2.1

10

CM_A decrypts ciphertext part of ACK message

11

CM_A inserts NONCE_A in ACK message to compute HASH

12

CM_A verifies CMID_B, NONCE_A, and HASH

Section 6 Section 10.2.1

CM_A considers session established if step 12 above is successfully completed 13

CM_B expects a valid message from CM-A using the new KD within a preset time (not to exceed 60 seconds).

CM_B considers the session established if step 13 above is successfully completed. CM_B closes the session if step 13 is not completed within the preset time. Table 1: Session Establishment Procedure

If CM_A and CM_B send OPN messages approximately simultaneously, both CMs will recognize the situation by having received an OPN message when an ACK was expected. In that case, the CM whose CMID value is greater shall disregard the received OPN message and assume the role of CM_A. The CM whose CMID value is lesser shall terminate its attempt to originate a session and shall instead assume the role of CM_B.

5.2

SECURE DATA TRANSFER

After a session is established between two CMs, DTA messages may be securely exchanged between them. DTA messages can carry encapsulated data as well as management information. Table 2 below provides references to the procedures and structures used for secure data transfer. DESCRIPTION

REFERENCE

Data encryption

Section 6

Message acknowledgement

Section 7

Error detection

Section 8

Message integrity

Section 9

Structure of the DTA message

Section 10.4

Table 2: Data Transfer References



DRAFT 1


5.3

SESSION TERMINATION

Either CM may terminate a session by sending a CLS message. The CLS message structure is described in Section 10.3. Upon receiving a CLS message, a CM transmits an ACK message (Section 10.2) and closes the session. The CM that sent the CLS message closes the session when either an ACK is received for the CLS message or after a timeout expires, whichever occurs first. After a session is closed, the KD, IVs, and NONCE_A associated with that session shall not intentionally be reused.

6

MESSAGE ENCRYPTION

All SLS messages include a plaintext part and a ciphertext part. This section describes the manner in which the ciphertext part is encrypted. 6.1

KEYS

Keys and key management are described in Reference 1; AGA 12-1 Annex H, “Symmetric Key Management Method”. A summary of key usage follows. A Session Establishment Key (KE) is established prior to the first use of SLS for every pair of CMs that must communicate with each other. KE is used to encrypt OPN and ACK messages that establish a Data Key (KD). KD is used to encrypt all subsequent messages exchanged in a session. The length for all keys is 16, 24, or 32 bytes, as specified by KLEN, a subfield of SESSION_INFO (refer to Section 11.3).

6.2

INITIAL VECTOR

The ciphertext part of all messages is encrypted using the Advanced Encryption Standard (AES)18 in Cipher Block Chaining (CBC) mode19. The CBC mode of AES requires an Initial Vector (IV) for each encrypted block. With the exception of the OPN and its associated ACK messages (as specified below), the last encrypted block of the last valid message serves as the IV for the first encrypted block of each message. Within a message, each encrypted block serves as the IV for the next encrypted block. For the purposes of determining the IV, a message is assumed to have been successfully transmitted until either acknowledgement fails or an acknowledgement indicates that one or more messages were not accepted (refer to Section 7). The OPN and ACK messages use an IV of 0 (refer to Section 5.1). Even though the IV itself is predictable for these messages, the first block of each of these messages contains either NONCE_A (an 8byte random number) or KD (a 16-byte random number). When a message is not acknowledged (see Section 7) its IV is reused. To counter a potential attack based on causing repeated reuse of an IV, CMs shall implement a parameter designated MAX_IV_REUSE. This parameter shall be configurable via a management session. Each time an IV is used, a counter increments. The counter is initialized when a session is established. When the counter value exceeds the value of MAX_IV_REUSE, the CM shall close the current session.

6.3

PADDING

AES requires the organization of data into 16-byte blocks. If the ciphertext part of a message (excluding a hash, if used) is less than 16 bytes, bytes must be added to bring the total size to 16 bytes. This process is called padding, and the added bytes are called pad bytes. If the length of the ciphertext part exceeds 16 bytes, it is divided into 16-byte segments called blocks. Each block is encrypted separately. If the length 18

Reference 4

19

Reference 5



DRAFT 1


of the ciphertext part is not an even multiple of 16 bytes, pad bytes are added to the last block. Padding may consist of random bytes or hash bytes, as specified below.

6.3.1 CRC IN LAST BLOCK The last block of every message includes either a CRC or a hash. If a CRC is specified, it occupies the last two bytes of the block (refer to Section 8). The last byte before the CRC is the byte count. The byte count specifies how many characters of data are in the last block, where data is everything except padding, byte count, and CRC. The count can range from 0 to 13 random pad bytes. A byte count of 0 indicates that the last block includes 13 random pad bytes. A byte count of 13 indicates the last block includes no pad bytes.

6.3.2 HASH IN LAST BLOCK When a hash is used, the hash value is appended to the plaintext before encryption. The last block includes at a minimum the number of hash bytes specified by HLEN. The last byte of the last block in a message using a hash is called HBYTE. HBYTE indicates the total number of hash bytes plus random pad bytes included in the message. When the specified hash length is less than 20, additional hash bytes are used for padding. When the hash bytes are used up, random pad bytes are used. Thus, if the last byte is 20 or less, all of the padding consists of hash bytes. If HBYTE is greater than 20, there are HBYTE – 20 random pad bytes appended to 20 hash bytes.

7

MESSAGE ACKNOWLEDGEMENT

SLS uses a handshaking method for acknowledging the receipt of messages and detecting missing messages. It is called a windowing method because a sending device does not have to wait for acknowledgement of one message before sending another. This method is adopted from the X.25 protocol family. Because message acknowledgement is embedded in normal traffic, this method is particularly well suited to poll/response systems. Windowing relies on two counters maintained by each communicating partner. The send state variable (VS) is the sequence number of the next message to be sent. The receive state variable (VR) is the expected sequence number of the next message to be received. Both VS and VR are initialized to zero when a session is established. VS and VR count using a modulus ranging from 2 to 8. The variable WINDOW_SIZE represents (modulus –1). The allowable values for WINDOW_SIZE are 2 through 7. The default value is 7. A value of 2 places a device in a special half-duplex mode, described later in this Section. VS and VR increment from 0 to WINDOW_SIZE. On the next count, the VS or VR value returns to 0. Every SLS DTA message includes in its CONTROL byte (see Section 11.1) two variables designated PS and PR. PS and PR reflect the values of VS and VR respectively as they existed in the sending device at the time a message was sent. Only PR is used with OPN, CLS, and ACK messages since there is no possibility of queuing these messages. For the following discussion, consider two cryptographic modules designated CM-A and CM-B. After sending a message, CM-A increments its VS value. CM-B expects the PS value of a DTA message to equal its own VR value, indicating that it has not missed any messages. If the two values match, the CMB accepts the message and increments its VR value. Every accepted message (except the last message in a session) must ultimately be acknowledged, although up to WINDOW_SIZE messages can be accepted before CM-B is forced to send an acknowledgement. CM_B can also be forced to send an acknowledgement after a configurable timeout



DRAFT 1


period elapses. A forced acknowledgement is only necessary if normal traffic does not cause CM-B to send a message before one of the above conditions occur. CM-A counts a message as acknowledged when it receives a message from CM-B whose PR value is equal to the VS of CM-A at the time that message was sent. A PR value equal to the current VS of CM-A acknowledges all outstanding messages. A configurable timeout parameter specifies how long CM-A will wait for acknowledgement of outstanding messages. If the timer expires, CM-A resets its VS to the value of the last PR it accepted. If no PR has been received since the session was established, VS becomes 0. A WINDOW_SIZE value of 2 forces a half-duplex mode of operation. In half-duplex mode, timeouts are disabled. If CM-A receives data causing it to send a second message before the first message has been acknowledged, it resets VS before sending the message. CM-B will not accept a second message until it has responded to the previous message

8

ERROR DETECTION

SLS can use either a cyclic redundancy check (CCITT CRC-16) or a secure hash (SHA-1), or both, to detect alterations to messages. The CRC is generally considered to be strictly for error detection, while the secure hash can more reliably detect both errors and intentional alteration (refer to Section 9). SLS allows the user to disable the secure hash function on data messages and rely strictly on CRC. This mode of operation is considered vulnerable to intentional modification of ciphertext messages. A sophisticated attacker may be able to manipulate the ciphertext in such a way that the CRC value still indicates a valid message. Without knowing KD, the attacker is unlikely to forge a valid SCADA message in this manner, but SLS is not likely to be considered “cryptographically secure” without using a hash on every message. The options for CRC usage are specified in SESSION_INFO (refer to Section 11.3). Each CRC value is computed over all preceding bytes of the message, including the plaintext part. If a CRC error is detected at any point in a message, processing stops and the message is rejected. If a message is rejected, it is not used for IV update (refer to Section 6.2). If an error-correcting link layer is in use, a CRC error may indicate intentional alteration of the message. In this case, the CM receiving the error shall respond to a CRC error by terminating the session.

9

MESSAGE INTEGRITY

SLS uses the Secure Hash Algorithm 1 (SHA-1)20 to verify that messages have not been altered. The output of SHA-1 is a 20-byte digest (the hash). The hash is computed over the entire message (before encryption), including HBYTE (refer to Section 6.3.2). A hash is always used with OPN and ACK messages used to establish sessions. For maximum security, a complete 20-byte hash should be included with every SLS message, and no plaintext should be passed to a protected device until the hash is verified. It is anticipated that the resulting latency and overhead will be undesirable or unacceptable in some cases. For those cases, SLS supports a balance between reduced security and increased performance with the following options:

20

•

The hash can be truncated to less than 20 bytes (refer to Section 9.1)

•

Only a portion of the plaintext can be withheld until the hash is verified (refer to Section 9.2).

•

The hash can be replaced with a CRC on data messages (refer to Section 8)

Reference 3



DRAFT 1


9.1

TRUNCATION

The sub-field HLEN of SESSION_INFO (refer to Section 11.3) specifies four options for hash truncation. The hash is truncated by using only the HLEN leftmost bytes. Four bytes is considered the absolute minimum acceptable length, and then only when it is impractical for an attacker to make numerous attempts at forging messages. Truncation to ten or fifteen bytes is also supported. In general, security is enhanced by the use of additional bytes. An HLEN value of 15 guarantees that a hash will at most add one block to a message.

9.2

HOLDBACK

Last-block holdback mode is a means of reducing the latency resulting from use of a hash. It only applies to DTA messages. When last-block holdback mode is specified, the receiving CM withholds decrypted bytes until the hash is received and compared. The number of bytes withheld ensures that all of the plaintext is not passed on until the hash is verified. The minimum number of withheld bytes shall be the greater of 16 or HLEN + 1. The withheld plaintext bytes are transmitted after the hash is verified. If the hash is not valid, the withheld plaintext bytes are discarded. Last block holdback is only permitted when CHECK = 010 (refer to Section 11.3). When full holdback mode is specified, the CM buffers the entire message and verifies the hash before outputting any plaintext. This is the most secure mode of operation.

10 MESSAGE STRUCTURES The message structures used by SLS procedures are defined below. For information about error detection and message integrity fields, refer to Sections 8 and 9 respectively.

10.1

OPN MESSAGE STRUCTURE

The OPN message is used to open a secure session. The fields included in this message vary depending on the value of SESSION_INFO. The OPN message is used to establish all session types. FIELD NAME

BYTES

DESCRIPTION

REFERENCE

The following fields are not encrypted CONTROL

1

Bit-map with multiple functions

Section 11.1

CMID_B

5

Identity of the CM to whom the OPN message is directed.

Section 11.2

SESSION_INFO

2


Section 11.3

{SESSION_ID}

*

Optional. Allows a CM to distinguish between multiple open sessions.

Section 11.3.4

The following fields are encrypted using KE with an IV of 0 NONCE_A

8

A random number generated by the CM sending the OPN message.

Section 11.9

CMID_A

5

Identity of the CM sending the OPN message.

Section 11.2

{PASSWORD}

4

Hash of the password required to establish a session of the requested type. Password is not required for a session type of DATA.

Section 11.5

VENDOR_DATA

*

Available for vendor or product-specific information related to the session establishment

Section 11.6

- –K-10

AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


information related to the session establishment. HASH

*

A secure hash computed over the entire message.

Section 9

Table 3: OPN Message Structure

10.2 ACK MESSAGE STRUCTURE ACK messages provide either a positive or negative acknowledgement for all other message types. 10.2.1 ACK MESSAGE STRUCTURE FOR SESSION ESTABLISHMENT This form of the ACK message completes the handshake required to establish a session. FIELD NAME

BYTES

DESCRIPTION

REFERENCE


1


Section 11.1

CMID_B

5

Identity of the CM to which the OPN message is directed.

Section 11.2

{SESSION_ID}

*

Echo of OPN value or alternate value if rejected.

Section 11.3.4

The following fields are encrypted using KE with an IV of 0 KD

*

The data key to be used in the session being established.

Section 6.1

NONCE_A

8

This value is not transmitted. It is included in the ACK message only for the purpose of computing HASH, then removed before the ACK is transmitted.

CMID_A

5

Identity of the CM sending the ACK message.

Section 11.2

ERROR_CODE

1

Enumeration specifying what type of error was detected in an OPN message.

Section 11.7

ERROR_DATA

*

Data associated with ERROR_CODE.

Section 11.8

VENDOR_DATA

*

Available for vendor or product-specific information related to the session establishment.

Section 11.6

HASH

*

A secure hash computed over the entire message.

Section 9

Table 4: ACK Message Structure for Session Establishment

10.2.2 ACK MESSAGE STRUCTURE FOR DTA AND CLS MESSAGES This form of the ACK message is sent in response to a CLS message or when DTA messages are not acknowledged as a result of normal message traffic. Either a secure hash or a CRC is calculated over the entire message as specified in Sections 8 and 9.

- –K-11 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


FIELD NAME

BYTES

DESCRIPTION

REFERENCE


1


{SESSION_ID}

*

Echo of OPN value or alternate value if rejected.

Section 11.1 Section 11.3.4

The following fields are encrypted using KD with the last encrypted block of the last valid message as the IV ERROR_CODE

1

Enumeration specifying what type of error was detected, if any

Section 11.7

ERROR_DATA

*


Section 11.8

CMID_B

5

Identity of the CM sending the ACK message.

Section 11.2

VENDOR_DATA

*

Available for vendor or product-specific information related to the session establishment.

Section 11.6

Table 5: ACK Message Structure for DTA and CLS Messages

10.3

CLS MESSAGE STRUCTURE

This message is sent by a CM under normal or fault conditions to terminate a session. Either a secure hash or a CRC is calculated over the entire message as specified in Sections 8 and 9. FIELD NAME

BYTES

DESCRIPTION

REFERENCE


1


{SESSION_ID}

*

Optional. Allows a CM to distinguish between multiple open sessions


The following fields are encrypted using KD with the last encrypted block of the last valid message as the IV ERROR_CODE

1

Enumeration specifying what triggered the CLS message.

Section 11.7

ERROR_DATA

*


Section 11.8

CMID_A

5

Identity of the CM sending the CLS message.

Section 11.2

VENDOR_DATA

*

Available for vendor or product-specific information related to the session closure.

Section 11.6

Table 6: CLS Message Structure

10.4

DTA MESSAGE STRUCTURE

DTA messages can carry management and forensic information or encapsulated SCADA protocol messages. Either a secure hash or a CRC is calculated over the entire message as specified in Sections 8 and 9.



DRAFT 1


FIELD NAME

BYTES

DESCRIPTION

REFERENCE


1


{SESSION_ID}

*

Optional. Allows a CM to distinguish between multiple open sessions


The following field is encrypted using KD with the last encrypted block of the last valid message as the IV USER_DATA

*

Depending on TYPE subfield of SESSION_INFO, can contain encapsulated SCADA data, management data, etc.

Section 11.9

Table 7: DTA Message Structure

11 MESSAGE FIELDS The following sections describe the fields used in each of the message structures.

11.1

CONTROL

The CONTROL field is a bit-mapped byte containing one or more of the following sub-fields: SUB-FIELD NAME

BITS

DESCRIPTION

REFERENCE

PR

3

Receive sequence count

Section 7

PS

3

Send sequence count

Section 7

M

1

More (next message is a continuation)

Section 11.1.1

R

1

Result (0 = negative, 1 = positive ACK)

Section 11.1.2

ID

*

Message type identifier

Section 11.1.3

Table 8: CONTROL Byte Structure

11.1.1 (M)ORE FIELD If set to a value of one, this single-bit field indicates the next message is a logical continuation of the data in the current message. This field is most useful at the application level where several messages may constitute a single logical structure. It has no procedural function within the protocol. 11.1.2 (R)ESULT FIELD This single-bit field is used only with the ACK message. A value of 1 indicates a positive acknowledgement; 0 indicates a negative acknowledgement. When the ACK is in response to an OPN message, 1 means the session has been successfully opened, 0 means the session was not opened. When the ACK is in response to a CLS message, 1 means the session was successfully closed with no unacknowledged messages. A 0 could have several meanings, chief of which would be an attempt to close a session that was not open or the session had unacknowledged messages. When the value is 0 error information is included in the body of the ACK message. - –K-13 AGA Report 12, Version 0.88 March 19, 2003


DRAFT 1


11.1.3 ID FIELD This variable-length field identifies the message type. The ID field value for each message type is specified in subsequent sections. Note that all message types except DTA have a value of 1 in the rightmost bit. 11.1.4 OPN MESSAGE CONTROL BYTE The CONTROL byte for the OPN message has a single field as shown below:

ID = 00000001B (8 bits) 11.1.5 ACK MESSAGE CONTROL BYTE The CONTROL byte for the ACK message has three fields as shown below:

PR

R

ID = 0011B (4 bits)

11.1.6 CLS MESSAGE CONTROL BYTE The CONTROL byte for the CLS message has a two fields as shown below:

PR

ID = 00101B (5 bits)

11.1.7 DTA MESSAGE CONTROL BYTE The CONTROL byte for the OPN message has four fields as shown below:

PR 11.2

M

PS

0 (1 bit)

CMID

The Cryptographic Module Identifier is a permanent five-byte code unique to every CM. For convenience in this document, the CMID of the CM originating an exchange is designated CMID_A. The CMID of the responding CM is designated CMID_B.

11.3 SESSION_INFO This field provides the information necessary to interpret an OPN message and all subsequent messages of that session. Each sub-field of SESSION_INFO is defined below. TYPE2 BIT 15

TYPE1 BIT 14

TYPE0 BIT 13

KLEN1 BIT 12

KLEN0 BIT 11

CHECK2 BIT 10

CHECK1 BIT 9

CHECK0 BIT 8

not used BIT 1

not used BIT 0

Table 9: SESSION_INFO MSB Structure

HL_S1 BIT 7

HL_S0 BIT 6

HL_D1 BIT 5

HL_D0 BIT 4

HOLD BIT 3

SID BIT 2

Table 10: SESSION_INFO LSB Structure



DRAFT 1


BITS 15-13

BITS 12-11

BITS 10-8

BITS 7-6

BITS 5-4

BIT 3

BIT 2

BITS 1-0

TYPE: Session type definition This field identifies the purpose of the session, defines the structure of the OPN and ACK messages, and identifies the key used to encrypt the OPN message. 000: not used 001: Data transfer (Section 0) 010: Management (Section 11.3.2) 011: Forensic (Section 11.3.3) 100: Vendor-specified (Section 11.3.4) 101: not used 110: not used 111: not used KLEN: AES key length Refer to Section 6.1 00: 16 bytes 01: 24 bytes 10: 32 bytes 11: not used CHECK: CRC and/or secure hash usage This field specifies how data messages are checked for errors and/or integrity. Refer to Sections 8 and 9. 000: Use hash always, CRC never 001: Use hash always, CRC on first ciphertext block 010: Use hash always, CRC on all but last ciphertext block 011: Use hash only for session establishment, CRC on first and last ciphertext block 100: Use hash only for session establishment, CRC on all ciphertext blocks 101: not used 110: not used 111: not used HL_S: Secure hash length for session establishment Minimum length of secure hash (Refer to Section 9) 00: 4 bytes 01: 10 bytes 10: 15 bytes 11: 20 bytes HL_D: Secure hash length for data messages Minimum length of secure hash (Refer to Section 9) 00: 4 bytes 01: 10 bytes 10: 15 bytes 11: 20 bytes HOLD: Holdback mode Refer to Section 9.2 Implementation method for secure hash 0: Last block holdback 1: Full holdback SID: Use Session ID Refer to Section 11.4 0: Do not use Session ID 1: Use Session ID not used Table 11: SESSION_INFO Subfield Definitions



DRAFT 1


11.3.1 DATA TRANSFER SESSION TYPE Data transfer is the most common session type used by SLS. This is the session type used to transparently encapsulate data and transfer it from one protected device to another. No password field is included in the OPN message for this session type. 11.3.2 MANAGEMENT SESSION TYPE A management session is a special case of the Data Transfer session used to communicate with a remote CM. A password field is added to the OPN message. 11.3.3 FORENSIC SESSION TYPE A forensic session is a subset of the management session allowing the user only to read audit and forensic information. A password field is added to the OPN message. 11.3.4 VENDOR-SPECIFIED SESSION TYPE This session type is reserved for vendors to implement special functions such as firmware download. A password field is added to the OPN message. CMs must read the first two bytes of the CMID_A field in the OPN message to identify the vendor and product in order to interpret this session type. 11.4

SESSION_ID

Use of the SESSION_ID field is a global option. If selected, it shall be included in every message, and by every CM in a network. This field allows a CM to distinguish between multiple open sessions, and it allows message routing in a multipoint network. The SESSION_ID field is not required in a point-topoint configuration (e.g., dialup or leased-line) if an active session will always be closed before a new session is opened with the same or another partner. The use of SESSION_ID is controlled by a CM configuration variable specifying whether SESSION IDs are used and their length (one or two bytes). To produce a SESSION_ID value for a new session, CM-A increments the last SESSION_ID value it used or the highest SESSION_ID value of its open sessions. It includes this value in the SESSION_ID field of the OPN message. If CM-B does not have an open session with the same SESSION_ID value, it accepts the value from CM-A and echoes it in the SESSION_ID field of the ACK message. Otherwise, CM-B increments the highest SESSION_ID value of its open sessions and places the new value in the SESSION_ID field of the ACK message. Both CM-A and CM-B use the SESSION_ID value from the ACK message.

11.5

PASSWORD

This field contains a four-byte hash of the password required to access a CM function. The PASSWORD field is present in the OPN message for Management and Forensic session types, and is not present in the OPN message for Data Transfer session types. SLS does not create the hash or use the password in any way.



DRAFT 1


11.6

VENDOR_DATA

This field consists of at least one byte, interpreted as follows: VALUE

MEANING

0

No vendor data is present

1-254

Byte count for vendor data immediately following (count includes byte-count byte)

255

Byte count is in the second and third bytes following (count includes all three byte-count bytes) Table 12: Vendor Data Byte Count Definition

Vendor data has no meaning to SLS. It is simply transported as data.

11.7

ERROR_CODE

This field consists of a single byte. A nonzero value indicates what triggered a CLS message or the type of error detected by a CM responding to an OPN message. Error codes are defined as follows: VALUE

0 1-127 128-255

MEANING

ERROR_DATA

No error/trigger not specified

not present

Reserved for AGA 12

Error-dependent

Vendor specified

Error-dependent Table 13: Error Code Enumeration

AGA 12 error code values and associated error data are to be defined. If multiple errors are detected, the choice of which error to report is a local matter.

11.8

ERROR_DATA

If ERROR_CODE is nonzero, the first byte of this field is a byte count for this field, including the byte count byte. The contents of this field are defined by the error code.

11.9

NONCE_A

A random number generated by a CM in compliance with FIPS 140-2 Section 4.7.1. NONCE_A introduces randomness into the OPN message and protects against replay. The length is 8 bytes.

11.10 KD The Data Key (KD) is a cryptographic key used to encrypt and decrypt data messages. KD is generated by a CM in compliance with FIPS 140-2 Section 4.7.2. See also Reference 1 and Section 6.1. The length is 16, 24, or 32 bytes, as specified by the KLEN subfield of SESSION_INFO (Section 11.3). KD is used for the duration of a single session.

11.11 USER_DATA This field contains the actual data being transferred. It may contain encapsulated SCADA protocol data or CM management/forensic data. The length is variable.



DRAFT 1


AGA 12-1 ANNEX L FIPS PUB 140-2 (Normative) REVISION 0.5



DRAFT 1


Reprint of Document prepared by National Institute of Standards and Technology May 25, 2001



DRAFT 1


@@ This should be an exact reprint of FIPS PUB 140-2. This will not be a copyright problem, since I checked with NIST and their documents may be reproduced in this standard. However, it is not included here because 1) we don't want to edit it anyhow and 2) it is long and this document is already long enough. When we do paste it in, however, this has to be done so as to preserve the formatting on indents, etc. @@



DRAFT 1


AGA 12-1 Annex M Device Manufacturers Security Policy (Informative)


- –M-1 AGA Report 12, Version 0.89 March 19, 2003


DRAFT 1


Purpose The purpose of this policy is to provide guidelines for manufacturers that will develop Cryptographic Modules (CM) to protect Supervisory Control and Data Acquisition (SCADA) field communications.

Scope This policy applies to all Cryptographic Modules designed to be in compliance with AGA Report #12-1 for the protection of SCADA communications that employ serial asynchronous RS232 technology as part of its communications channel in or between the control center (SCADA Master), its extensions and/or remote field devices (RTU, relay, sensor or other Intelligent Electronic Device (IED)).

Policy SCADA Cryptographic Modules (CMs), to be in compliance with AGA Report #12-1, must be designed, manufactured, and have the ability to be operated in such a way, as to be approved by a recognized national cryptography standards organization.

Practices and Procedures to Implement the Policy Practices Device certification •

For the United States, CMs shall be certified to conform to FIPS Publication 140-2 by an approved National Voluntary Laboratory Accreditation Program testing facility. •

For the United States, CMs shall conform to FIPS Publication 140-2 with an overall security rating of Level 2.

•

For the United States, CMs shall conform to FIPS Publication 140-2 Level 3 requirements for Cryptographic Module Ports and Interfaces.

•

For the United States, CMs shall conform to FIPS Publication 140-2 Level 3 requirements for Key Entry and Output.

Cryptographic algorithms •

For the United States, algorithms employed by the CM shall be approved by the National Institute for Standards and Technology (NIST), as listed in FIPS Publication 140-2 Annex A. •

For encryption, AES is approved. •

Note: Link encryption shall be implemented in a mode that is not subject to replay attacks. CBC mode is approved.

•

For hashing or file integrity checking, SHA-1, HAMC and CCITT CRC-16 are approved.

•

For digital signatures, RSA and ECDSA are approved.



DRAFT 1


Cryptographic key materials •

All cryptographic keys shall be generated, employed and managed in a secure manner based on their intended use. •

For the United States, key generation and key establishment shall conform to FIPS Publication 140-2 Annex C

•

Keys used for authentication:

•

•

•

Only asymmetric keys (a public and private key pair cryptographic technique) shall be used for authentication; symmetric keys (a single key cryptographic technique) shall not be used for authentication.

•

Public and private keys used for authentication shall be generated within the security boundary of the CM.

•

Private keys used for authentication shall never be exposed outside of the security boundary of the CM.

•

Public and private key pairs used for RSA-based authentication shall be at least 1024-bits in length.

•

Public and private key pairs used for ECDSA-based authentication shall be at least 160-bits in length.

Keys used for domain identity: •

Both asymmetric keys (a public and private key pair cryptographic technique) and symmetric keys (a single key cryptographic technique) may be used for domain identity.

•

Cryptographic keys used for domain identity may be generated within the security boundary of the CM or generated within the security boundary of a Hardware Security Module (HSM) that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher.

•

Cryptographic keys used for domain identity shall never be exposed outside of the security boundary of the CM in plaintext.

•

Public and private key pairs used for RSA-based domain identity shall be at least 1024-bits in length.

•

Public and private key pairs used for ECDSA-based domain identity shall be at least 160-bits in length.

•

Symmetric keys used for AES-based domain identity must be at least 128-bits in length.

Keys used for data blob (document, file, volume, cryptographic key, etc.) encryption: •

Both asymmetric keys (a public and private key pair cryptographic technique) and symmetric keys (a single key cryptographic technique) may be used for data blob encryption.

•

Cryptographic keys used for data blob encryption shall be generated within the security boundary of a Hardware Security Module (HSM) that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher.

•

Cryptographic keys used for data blob encryption shall never be exposed in plaintext outside of the security boundary of a hardware device that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 2 or higher.

•

Public and private key pairs used for RSA-based data blob encryption shall be at least 1024bits in length.



DRAFT 1


•

•

•

Public and private key pairs used for ECDSA-based data blob encryption shall be at least 160-bits in length.

•

Symmetric keys used for AES-based data blob encryption shall be at least 128-bits in length.

Keys used for session encryption •

Both asymmetric keys (a public and private key pair cryptographic technique) and symmetric keys (a single key cryptographic technique) may be used for session encryption.

•

Cryptographic keys used for session encryption shall be generated within the security boundary of the CM or generated within the security boundary of a Hardware Security Module that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher.

•

Cryptographic keys used for session encryption shall never be exposed in plaintext outside of the security boundary of a hardware device that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 2 or higher.

•

Public and private key pairs used for RSA-based session encryption shall be at least 1024bits in length.

•

Public and private key pairs used for ECDSA-based session encryption shall be at least 160bits in length.

•

Symmetric keys used for AES-based session encryption must be at least 128-bits in length.

Key and digital certificates used within the CM by manufacturers •

Only asymmetric keys (a public and private key pair cryptographic technique) shall be used for CM or manufacturer authentication; symmetric keys (a single key cryptographic technique) shall not be used for CM or manufacturer authentication.

•

Cryptographic keys used for CM authentication shall be generated within the security boundary of the CM.

•

Private keys used for CM authentication shall never be exposed outside of the security boundary of the CM.

•

Cryptographic keys used for manufacturer authentication shall be generated within the security boundary of a Hardware Security Module (HSM) that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher.

•

Private keys used for manufacturer authentication shall never be exposed outside of the security boundary of the HSM.

•

Both asymmetric keys (a public and private key pair cryptographic technique) and symmetric keys (a single key cryptographic technique) may be used for manufacturer’s data blob encryption.

•

Cryptographic keys used for data manufacturer blob encryption shall be generated within the security boundary of a Hardware Security Module (HSM) that conforms to FIPS Publication 140-2 (or FIPS PUB 140-1) with an overall security rating of Level 3 or higher.

•

Private keys used for manufacturer data blob encryption shall never be exposed outside of the security boundary of the HSM in plaintext.

•

Symmetric keys used for manufacturer data blob encryption shall never be exposed outside of the security boundary of the CM or HSM in plaintext.

•

Public and private key pairs used for RSA-based manufacturer authentication and/or manufacturer’s data blob encryption shall be at least 1024-bits in length.



DRAFT 1


•

Public and private key pairs used for ECDSA-based manufacturer authentication and/or manufacturer’s data blob encryption shall be at least 160-bits in length.

•

Symmetric keys used for AES-based manufacturer’s data blob encryption shall be at least 128-bits in length.

•

Manufacturer’s cryptographic keys and digital certificates embedded within the CM, including the CM’s authentication public and private key pair and digital certificate, and the manufacturer’s digital certificates and certificate chains for their Software Department and Technical Support Department, shall be persistent – they shall be generated or securely loaded at time of manufacturing and shall not be changeable for the life of the product. •

The only access the CM manufacturer shall have to the CM after delivery to a customer shall be via the Vendor’s Technical Support Role described below.

User roles, authentication and authorization •

Roles •

For the United States, the CM shall provide at least the following roles as defined in Roles, section 4.3.1 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

•

•

•

User Role •

The CM is intended to be an autonomous non-intrusive appliance used to encrypt data that passes through it (i.e.; a link encryptor). As such, it does not have a user as implied by the FIPS documentation. It is possible to imply that in normal operation the data stream passing through the CM is the “user”.

•

The User Role does not require authentication.


The Crypto Officer Role shall only perform cryptographic functions (including key generation, key exchange, establishing and maintaining domain identity) and authorization functions (including maintain operator credentials and certificate chains).

•



The Maintenance Role shall only perform maintenance functions (including set device and communication configurations, and run diagnostics).

•

The Maintenance Role shall require strong authentication.

For the United States, the CM may provide the following role as defined in Roles, section 4.3.1 of FIPS Publication 140-2 (or FIPS PUB 140-1). •

Vendor Technical Support Role •

The Vendor Technical Support Role shall only perform technical support functions (including device and communication configurations, download firmware updates, and run diagnostics).

•

The Vendor Technical Support Role shall not be able to perform any Crypto Officer, Maintenance Officer, or User functions. The Vendor Technical Support Role shall not be able to access any device or domain security settings or data.

•

The Vendor Technical Support Role shall require strong authentication



DRAFT 1


•

•

•

The Vendor Technical Support Role may be disabled by the Crypto Officer Role. The Crypto Officer Role shall manage the PIN associated with the Vendor Technical Support Role.

Strong authentication •

All authentication shall be performed using Public Key Cryptography.

•

All operator’s private keys used for authentication shall be generated in, stored in, and utilized from a secure container such as a smart card or USB token conforming to FIPS Publication 140-2 (or FIPS PUB 140-1) Level 2 or higher.

Authorization •

All operations requiring authorization shall use strong authentication techniques to identify the operator and/or data blob being executed.

•

All software updates shall be authenticated using Public Key Cryptography-based Digital Signature techniques. Manufacturer’s software departments shall digitally sign all software updates using private keys generated in, stored in, and utilized from a Hardware Security Module (HSM) conforming to FIPS Publication 140-2 (or FIPS PUB 140-1) Level 3 or higher.

Management •

The CM shall provide a secure management capability. •

Only authenticated operators authorized as a Crypto Officer and/or Maintenance Officer shall perform Management functions.

•

The CM shall provide Local Out-of-band Management, and/or Remote In-band Management capabilities. •

•

Local Out-of-band Management •

The CM shall employ a physical data port (trusted path) for maintenance purposes. The trusted path shall be physically different from those ports used for mission data.

•

Cryptographic key materials and firmware updates traveling over the trusted path shall be encrypted, all other data blobs traveling over the trusted path may be transmitted as plaintext.

Remote in-band Management •

The CM may employ the same ports used for mission data, for Remote In-band Management.

•

All Remote In-band Management data, including cryptographic key materials, firmware updates, and configuration settings shall be encrypted.

Procedures Companies that design and manufacture Cryptographic Modules (CMs) intended to be in compliance with AGA Report #12-1, shall: •

•

Create their own product’s Security Policy detailing: •

How they shall meet the Policy and Practices for CM security as outlined by AGA Report #12-1.

•

How they shall meet FIPS Publication 140-2 with an overall security rating of Level 2 or higher.

Submit their products to a recognized national cryptography standards organization’s testing facilities for certification.



DRAFT 1


•

Once the product is certified, the manufacturer shall: •

List their compliance approval information (including agency name, approval number, approval title, approval date) by a recognized national cryptography standards organization in their product’s technical and marketing documentation.

•

Provide AGA with a copy of their compliance approval information (including agency name, approval number, approval title, approval date) by a recognized national cryptography standards organization.

Enforcement The AGA reserves the right to list on its web site, electronic and printed documentation and presentations the names of companies and their products that meet the security requirements of AGA Report #12-1.

References FIPS Publication 140-2 Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm FIPS PUB 140-2 Annex A

Approved Security Functions Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm

FIPS PUB 140-2 Annex C

Approved Random Number Generators Security Requirements for Cryptographic Modules National Institute of Standards and Technology, US Department of Commerce http://csrc.nist.gov/cryptval/140-2.htm

Revision History


AGA Report No - Working Group - IEEE

AGA Report No - Working Group - IEEE

Suggest Documents

P1888.1 - Working Group - IEEE

P1888.3 - Working Group - IEEE

Electroweak Working Group Report

Working Group Report

PAK-Z+ - Working Group - IEEE

Report of the Standards Working Group - IEEE Computer Society

Sea Lice Working Group Report

Sea Lice Working Group Report

Compensation Technical Working Group Report

1 Working group report: QCD

Sustainability report 2012 - Aga-reports.com

Report 2014 - Aga Khan University

Report 2014 - Aga Khan University

Child Protection Working Group - No Lost Generation

IEEE 802.3ae 5 Criteria - Working Group

IEEE P1888.4 Ubiquitous Green Community ... - Working Group

Ieee 1366 & regulatory implications - Working Group

Rbridges and Bridges - Working Group - IEEE

Child Protection Working Group - No Lost Generation

IEEE Distribution Reliability Working Group - EIA

The ieee GRss Working Group on Remote sensing ... - IEEE Xplore

Summary Report from a PT Working Group

1 Top quark working group report - arXiv

The Higgs Working Group: Summary Report 2003