DOC

AMI System Security Requirements - v0_92 - Draft for Review

By Daniel Ward,2014-09-14 10:00
9 views 0
UtiltyAMI_20081022_Face-to-Face_Meeting_Minutes

    UCAIUG: AMI-SEC-ASAP

    AMI System Security

    Requirements

    Specification

    V0.92 Draft for Review

    ASAP

    11/19/2008

1 Executive Summary

    2 This document provides the utility industry and vendors with a set of security requirements for 3 Advanced Metering Infrastructure (AMI). These requirements are intended to be used in the 4 procurement process, and represent a superset of requirements gathered from current cross-5 industry accepted security standards and best practice guidance documents.

    6

    7 This document provides substantial supporting information for the use of these requirements 8 including scope, context, constraints, objectives, user characteristics, assumptions, and 9 dependencies. This document also introduces the concept of requirements for security states and 10 modes, with requirements delineated for security states.

    11

    12 These requirements are categorized into three areas: 1) Primary Security Services, 2) Supporting 13 Security Services and 3) Assurance Services. The requirements will change over time 14 corresponding with current security threats and countermeasures they represent. The AMI-SEC 15 Task Force presents the current set as a benchmark, and the authors expect utilities and vendors 16 to tailor the set to individual environments and deployments.

    17

    18 While these requirements are capable of standing on their own, this document is intended to be 19 used in conjunction with other 2008 deliverables from the AMI-SEC Task Force, specifically the 20 Risk Assessment, the Architectural Description, the Component Catalog (in development as of 21 this writing), and the Implementation Guide (to be developed late 2008). This document also 22 discusses the overall process for usage of this suite.

    23

    AMI System Security Specification Page i

24 Acknowledgements

    25 The AMI-SEC Task Force would like to acknowledge the work of the primary authors, 26 contributing authors, editors, reviewers, and supporting organizations. Specifically, the Task 27 Force would like to thank:

    28

    29 ; The AMI Security Acceleration Project (ASAP)

    30 o The Architectural Team including resources from Consumers Energy, 31 EnerNex Corporation, InGuardians, The Software Engineering Institute at 32 Carnegie Mellon University, and Southern California Edison

    33 o Supporting organizations including The Electric Power Research Institute and 34 The United States Department of Energy

    35 o Participating utilities, including American Electric Power, Austin Energy, BC 36 Hydro, Consumers Energy, Duke Energy, Kansas City Power & Light, Oncor, 37 Pacific Gas & Electric, San Diego Gas & Electric, Southern California Edison 38 ; The utilities, vendors, consultants, national laboratories, higher education institutions, 39 governmental entities, and other organizations that have actively contributed to and 40 participated in the activities of the AMI-SEC Task Force

    41

    42 Authors

    43 Bobby Brown

    44 Brad Singletary

    45 Bradford Willke

    46 Coalton Bennett

    47 Darren Highfill

    48 Howard Lipson

    49 James Ivers

    50 Jeff Gooding

    51 Jeremy McDonald

    52 Neil Greenfield

    53

    AMI System Security Specification Page ii

54

    55 Table of Contents 56 Executive Summary .................................................................................................................... i 57 Acknowledgements .................................................................................................................... ii 58 1. Introduction .............................................................................................................................1 59 1.1. Purpose .........................................................................................................................1 60 1.1.1 Strategic Importance ...................................................................................................1 61 1.1.2 Problem Domain .........................................................................................................2 62 1.1.3 Intended Audience ......................................................................................................3

    1.2.63 Scope ............................................................................................................................3 64 1.3. Document Overview .....................................................................................................4 65 1.4. Definitions, acronyms, and abbreviations ......................................................................6 66 1.5. References ....................................................................................................................6 67 2. General system description ..................................................................................................7 68 2.1. Use Cases .....................................................................................................................7 69 2.1.1. Billing ....................................................................................................................8 70 2.1.2. Customer ............................................................................................................. 10 71 2.1.3. Distribution System ............................................................................................. 11 72 2.1.4. Installation ........................................................................................................... 12 73 2.1.5. System ................................................................................................................. 14 74 2.2. System Context ........................................................................................................... 14

    2.3.75 System Constraints ...................................................................................................... 17 76 2.4. Security States and Modes .......................................................................................... 18

    2.4.1. System States ........................................................................................................... 1977 78 2.4.2. System Modes ......................................................................................................... 20 79 2.5. Security Objectives ..................................................................................................... 21 80 2.4.1. Holistic Security ...................................................................................................... 23

    2.6.81 User Characteristics .................................................................................................... 23

    2.7.82 Assumptions and Dependencies .................................................................................. 24 83 3. System Security Requirements .......................................................................................... 24

    3.1. Primary Security Services ............................................................................................... 2484 85 3.1.1. Confidentiality and Privacy (FCP) ........................................................................... 24 86 3.1.2. Integrity (FIN) ......................................................................................................... 25 87 3.1.3. Availability (FAV)................................................................................................... 28 88 3.1.4. Identification (FID) .................................................................................................. 29 89 3.1.5. Authentication (FAT)............................................................................................... 29 90 3.1.6. Authorization (FAZ) ................................................................................................ 32 91 3.1.7. Non-Repudiation (FNR) .......................................................................................... 33 92 3.1.8. Accounting (FAC) ................................................................................................... 34 93 3.2. Supporting Security Services .......................................................................................... 37

    3.2.1. Anomaly Detection Services (FAS) ......................................................................... 3794 95 3.2.2. Boundary Services (FBS) ......................................................................................... 38

    3.2.3. Cryptographic Services (FCS) .................................................................................. 4096 97 3.2.4. Notification and Signaling Services (FNS) ............................................................... 41 98 3.2.5. Resource Management Services (FRS) .................................................................... 41 99 3.2.6. Trust and Certificate Services (FTS) ........................................................................ 44

    AMI System Security Specification Page iii

100 3.3. Performance/Non-Functional .......................................................................................... 44

    101 3.4. Assurance ....................................................................................................................... 44 102 3.4.1. Development Rigor (ADR) ...................................................................................... 44 103 3.4.2. Organizational Rigor (AOR) .................................................................................... 48 104 3.4.3. Handling/Operating Rigor (AHR) ............................................................................ 57 105 3.4.4. Accountability (AAY) ............................................................................................. 61 106 3.4.5. Access Control (AAC) ............................................................................................. 64 107 Appendix A: Normative Information ......................................................................................... 66

    A.1. Scope ................................................................................................................................ 66108 109 A.2. Mission ............................................................................................................................. 67 110 A.4. Stakeholders & Concerns................................................................................................... 68 111 A.5. Security Analysis Approach............................................................................................... 69 112 A.6. Architecture Description Approach .................................................................................... 69 113 A.6.1. Viewpoints ................................................................................................................. 70 114 A.6.2. Views ......................................................................................................................... 71

    A.7 Contextual View ................................................................................................................. 71115

    A.8 Top Level Model ................................................................................................................ 71116 117 A.8.1. Customer Model ......................................................................................................... 72

    A.8.2. Third Party Model....................................................................................................... 74118 119 A.8.3. Utility Model .............................................................................................................. 75

    A.9 Security Domains View ...................................................................................................... 79120 121 A.9.1. Utility Edge Services Domain ..................................................................................... 81 122 A.9.2 Premise Edge Services Domain.................................................................................... 81

    A.9.3. Communication Services Domain ............................................................................... 81123 124 A.9.4. Managed Network Services Domain ........................................................................... 82

    A.9.5. Automated Network Services Domain ........................................................................ 82125 126 A.9.6. Utility Enterprise Services Domain ............................................................................. 82 127

    AMI System Security Specification Page iv

128 1. Introduction

    129 As a key element in the evolution of the Smart Grid, the Advanced Metering Infrastructure (AMI) 130 is the convergence of the power grid, the communications infrastructure, and the supporting 131 information infrastructure. AMI security must exist in the real world with many interested parties 132 and overlapping responsibilities. This document focuses on the security services that are 133 important to secure the power grid, communications infrastructure and supporting information 134 infrastructure.

    135 1.1. Purpose

    136 The purpose of the AMI Security Specification is to provide the utility industry along with 137 supporting vendor communities and other stakeholders a set of security requirements that should 138 be applied to AMI implementations to ensure the high level of information assurance, 139 availability and security necessary to maintain a reliable system and consumer confidence. 140 While this specification focuses on AMI, the security requirements contained in the document 141 may be extended to other network-centric, Smart Grid solutions.

    142 1.1.1 Strategic Importance

    143 Utility companies of the future will deliver energy and information to customers through a 144 ―smart‖ energy supply chain created by the convergence of electric, communication and 145 information technologies that are highly automated for responding to the changing environment, 146 electricity demands and customer needs. The building blocks of this Smart Grid include AMI, 147 advanced transmission and distribution automation, distributed generation, electric vehicle 148 refueling infrastructure and renewable energy generation projects of today. 149

    150 The emergence of this new class of Smart Grid systems holds tremendous promise and requires 151 innovation and deployment of new technologies, processes and policies. Composed of many 152 independent systems, the Smart Grid will evolve by integrating existing islands of automation to 153 achieve value through the delivery of information to customers, grid operators, utility companies 154 and other stakeholders. A reliable and secure Smart Grid holds the promise of reducing green 155 house gas emissions and dependence on fossil fuels by enabling automated demand response, 156 providing customers a myriad of options to manage their energy costs through technology 157 enabled programs along with limiting outages with a self-healing resilient transmission and 158 distribution network and other strategically important functions.

    159

    160 The challenge of providing both a reliable and secure AMI solution lies in the diversity of 161 technologies, processes and approaches used to realize this vision. Managing change rising from 162 the complexity of diverse solutions with an effective and efficient systems integration process 163 will enable the AMI system. This requires a commitment to standards, best practices and a high 164 degree of architectural discipline. This document serves as an ad hoc standard supporting a 165 reliable and secure AMI solution as part of a robust Smart Grid solution. Specifically, this 166 document specifies platform independent security requirements, services and guidance required 167 to implement secure, resilient AMI solutions.

    AMI System Security Specification Page 1

168 1.1.2 Problem Domain

    169 As utility industry capabilities increase to serve the needs of a rapidly growing information 170 society, the breadth and sophistication of the threat environment these Smart Grid solutions 171 operate in also increases. By bridging heterogeneous networks capable of exchanging 172 information seamlessly across the AMI older proprietary and often manual methods of securing 173 utility services will disappear as each is replaced by more open, automated and networked 174 solutions. The benefits of this increased connectivity depends upon robust security services and 175 implementations that are necessary to minimize disruption of vital services and provide increased 176 reliability, manageability and survivability of the electric grid.

    177

    178 Recognizing the unique challenges of AMI enabled Smart Grid solutions is imperative to 179 deploying a secure and reliable solution. Unique characteristics of AMI implementations that set 180 them apart from other utility project include the following:

    181 ; AMI touches every consumer

    182 ; AMI is a command and control system

    183 ; AMI has millions of nodes

    184 ; AMI touches almost every enterprise system

    185 ; Many current AMI solutions are narrowband solutions

    186

    187 These network-centric characteristics, coupled with a lack of security standards and 188 implementation guidance, is the primary motivation for the development of this document. The 189 problem domains needing to be addressed within AMI implementations is relatively new to the 190 utility industry, however there is precedence for implementing large scale, network-centric 191 solutions with high information assurance requirements. The defense, cable and 192 telecommunication industries offer a number of examples of requirements, standards and best 193 practices directly applicable to AMI implementations.

    194

    195 The challenge is to secure AMI in a holistic manner, noting that such an approach requires the 196 buy-in of many stakeholders. Stakeholders can be viewed in three groups:

    197 ; Stakeholders within the enterprise who have an interest in generating value from technology 198 investments:

    199 Those who make investment decisions

    200 Those who decide about requirements

    201 Those who use technology services

    202 ; Internal and external stakeholders who provide technology services:

    203 Those who manage the technology organization and processes

    204 Those who develop capabilities

    205 Those who operate the services

    206 ; Internal and external stakeholders who have a control/risk responsibility: 207 Those with security, privacy and/or risk responsibilities

    208 Those performing compliance functions

    209 Those requiring or providing assurance services

    210

    211 To meet the requirements of the stakeholder community, a framework for technology 212 governance and control should:

    213 ; Provide a business focus to enable alignment between business and technology objectives

    AMI System Security Specification Page 2

    214 ; Establish a process orientation to define the scope and extent of coverage, with a defined 215 structure enabling easy navigation of content

    216 ; Be generally acceptable by being consistent with accepted technology good practices and 217 standards and independent of specific technologies

    218 ; Supply a common language with a set of terms and definitions that are generally 219 understandable by all stakeholders

    220 ; Help meet regulatory requirements by being consistent with generally accepted corporate 221 governance standards (e.g., COSO) and technology controls expected by regulators and 222 external auditors.

    223

    224 As such, this document provides security requirements for the purposes of procurement, design 225 input, validation and certification. It is not the intent of this document to describe AMI 226 architecture. The satisfaction of requirements identified in this document implies a need for 227 coherent architecture, policies, procedures, etc… none of which is prescribed in this document.

    228

    229 AMI security involves a system of systems approach in design and operations, and therefore 230 security responsibility must extend to stakeholders and parties outside and in addition to the 231 electric utility. While security requirements for the broader AMI may or may not be within the 232 scope of a single utility’s responsibility, imposing the requirements upon cooperating

    233 interconnecting systems and the corresponding capabilities will meet or support some aspects of 234 AMI security objectives. Moreover, interdependencies among the power grid, the 235 communications infrastructure, and the information infrastructure pose a particularly serious 236 challenge to the design of a secure and survivable AMI.

    237 1.1.3 Intended Audience

    238 The intended audience for this document includes utility companies seeking AMI 239 implementation and policy guidance; vendors seeking product design requirements and input; 240 policy makers seeking to understand the requirements of reliable and secure AMI solutions; and 241 any reader who wishes to find information related to AMI security requirements. While this 242 document is intended for use by security professionals, solution architects and product designers, 243 much of the document is written for a broader audience seeking to understand AMI security 244 challenges, requirements and potential solutions. Lastly, this specification may provide a 245 foundation for security requirements in the procurement and implementation of AMI solutions. 246

    247 This document is intended to be a living specification to be updated as the industry evolves, with 248 a focus on AMI security functionality. As such, one of the benefits of this document is to create 249 a baseline document for the utility industry that provides AMI security requirements and 250 identifies gaps between current requirements and capabilities available in the market. Ideally, 251 the AMI security specification will be referenced and reused throughout the utility industry, 252 providing a common set of semantics for enabling the development and implementation of 253 robust, reliable AMI solutions.

    254 1.2. Scope

    255 AMI Security is simply defined as those means and measures concerned with securing an AMI 256 system. For the purpose of this document, the definition of AMI is:

    AMI System Security Specification Page 3

    257 The communications hardware and software and associated system and data 258 management software that creates a network between advanced meters and utility 259 business systems and which allows collection and distribution of information to 260 customers and other parties such as competitive retail providers, in addition to 261 providing it to the utility itself. AMI is further defined as: 1) The hardware and 262 software residing in, on, or closest to the customer premise for which the utility or 263 its legal proxies are primarily responsible for proper operation; and 2) The 264 hardware and software owned and operated by the utility or its legal proxies 265 which has as its primary purpose the facilitation of Advanced Metering. 266 This document presents security requirements for AMI systems. This document does not address 267 business functional or other non-security related requirements.

    268

    269 A further understanding of the scope requires an understanding of the utility business systems 270 and associated functionality. Section 2.1 of this document discusses Utility Business Systems 271 and services. In general, this specification is a tool that can be applied broadly as defined above 272 and to peripheral systems using AMI communication services. Each individual utility should 273 decide the boundary distinction. The boundary definition and document applicability includes 274 system security maturity of the associated connecting system, organizational responsibility and 275 procurement scope.

    276

    277 The AMI-SEC Task Force considered HAN use cases in the development of this document and it 278 is reasonable to assume utility edge application requirements can be applied to HAN applications 279 (e.g., requirements applied to utility applications can also be applied to consumer applications). 280 Imposing requirements on the HAN requires additional considerations associated with control 281 and ownership that are outside the scope of this document.

    282 1.3. Document Overview

    283 How to use this document - How this relates to AD, Risk Assessment and Component Catalog 284 and Implementation Guide

    285

    286 The path that a particular utility follows through these documents (Risk Assessment, System 287 Security Requirements, Architectural Description, Component Catalog and Implementation 288 Guide) depends upon the level of resources the utility chooses to put toward the effort. In the 289 drawing below, this level of resources tracks the ―Entry Points‖ on the right side of the drawing.

    290 For the descriptions below (Figure 1), the utility will define Architectural Elements, i.e., 291 hardware and software.

    292

    AMI System Security Specification Page 4

293 294

    295 Figure 1 Deliverables Process Flow

    296

    297 Maximum Level of Resources. For a utility with the ability to apply the maximum level of 298 resources, the process to take is the following:

    Step 1 The utility will tailor the AMI-SEC Risk Assessment to their particular environment,

    constraints, and risk acceptance limits.

    Step 2 The utility selects which requirements apply to their potential solution architecture by

    combing through the AMI-SEC System Security Requirements document and

    assigning priority to the requirements they need in order to adequately mitigate risks.

    Step 3 The utility maps the significant Architectural Elements of potential solutions against

    the defined Security Domains and places selected and prioritized requirements on

    Architectural Elements according to the elements’ placement within the Security

    Domains.

    299

    300 Medium Level of Resources. For a utility with a moderate (―medium‖) level of resources, the

    301 process to undertake is the following:

    Step 1 The utility will review the System Security Requirements document and select which

    requirements apply to their potential solution architecture.

    Step 2 The utility maps the significant Architectural Elements of potential solutions against

    the defined Security Domains.

    Step 3 The utility accepts the AMI-SEC Risk Assessment without any modification or

    customization, but bears the responsibility for combing through the AMI-SEC System

    Security Requirements document

    Step 4 The utility assigns priority to the requirements they need to adequately mitigate risks.

    Step 5 Once the utility has selected and prioritized requirements, the requirements are placed

    on Architectural Elements according to the elements’ placement within the Security

    Domains.

    AMI System Security Specification Page 5

Report this document

For any questions or suggestions please email
cust-service@docsford.com