P URPOSE
This document addresses security concerns related to Advanced Metering Infrastructure (AMI) and offers guidance and security controls for organizations developing or implementing AMI solutions within the Smart Grid It serves as a valuable reference for utilities during the Request-for-Proposal process and assists vendors in aligning their solutions with utility requirements The document aims to deliver actionable guidance for integrating and implementing security measures in AMI smart grid functionality It presents a customized security profile based on AMI use cases, organizing functions and components into manageable security domains while remaining neutral to specific vendor implementations and architectures.
S COPE
This document offers essential security guidance specifically for Advanced Metering Infrastructure (AMI) systems, focusing on the meter data management system (MDMS) and the Home Area Network (HAN) interface of smart meters It outlines controls tailored to the components and interfaces primarily supporting AMI, detailing the architecture that encompasses communications from the MDMS to the smart meter Notably, this guidance excludes organizational security controls that are deemed unnecessary for the organization.
Informative security guidance may be provided for AMI related components that extend beyond the external interfaces of the MDMS and smart meter.
A PPROACH
The ASAP-SG team outlined essential cyber security controls for Advanced Metering Infrastructure (AMI), detailing the methodology for assessing risks and addressing cyber security issues in the electric power sector.
1 Examination of AMI Use Cases
2 Evaluation of risk for AMI
3 AMI security service domain analysis
4 Modification and enhancement of DHS controls
AMI systems exhibit similarities at the logical level, despite variations among utilities due to differing technology choices and supported features Publicly available resources were reviewed to understand the logical structure of AMI systems, with www.smartgridipedia.org serving as the main source for UML use cases, scenarios, and sequence diagrams Through this analysis, the ASAP-SG team developed a logical architecture and assessed the communication between logical and physical components.
The ASAP-SG team assessed the risks linked to AMI components and interfaces, breaking down components into sub-components when necessary to apply specific security controls Key cybersecurity issues related to current AMI technology, including key management, firmware assurance, and trust among users and objects within and between organizations, were thoroughly considered in this evaluation.
Security controls were chosen based on their relevance to the components and messages of the studied Advanced Metering Infrastructure (AMI) scenarios To enhance the understanding of these components, security service domains were utilized to address additional security considerations The process involved categorizing components into AMI security service domains, analyzing processes, communication, and security aspects, which ultimately guided the selection of specific requirements for each component.
A UDIENCE
This document is intended for organizations engaged in the development or implementation of Advanced Metering Infrastructure (AMI) solutions It is crafted for individuals with a standard level of utility security expertise, including system owners, implementers, and security engineers Users are expected to have experience in assessing information asset risks and possess knowledge in formulating security requirements and guidance.
D ISCLAIMER /S TATUS
This document outlines recommended security controls adapted for AMI security, based on DHS guidelines The DHS control section numbers are included solely for traceability purposes and do not imply that the controls are directly from DHS For controls developed by the ASAP-SG team without a DHS equivalent, the prefix "ASAP-" is utilized instead of "DHS-".
Note: The syntax in this document follows the following conventions
The term "shall" signifies mandatory requirements that must be strictly adhered to in order to comply with the standard, allowing for no deviations.
The word recommended is used to indicate flexibility of choice with a strong preference alternative.
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.
The term "should" signifies a recommendation among various options, highlighting one as especially suitable while not dismissing others It implies a preferred course of action that is advisable but not mandatory In its negative form, "should" indicates a discouraged action without outright prohibiting it.
The word may, equivalent to “is permitted,” is used to indicate a course of action permissible within the limits of this standard.
The word can, equivalent to “is able to,” is used to indicate possibility and capability, whether material or physical.
Security requirements were determined based on the domain analysis detailed in this section Although AMI systems differ among utilities due to varying technology choices and intended features, there are many commonalities at the logical level A comprehensive overview of these features and their logical structure can be found in publicly accessible and peer-reviewed resources.
Our analysis commenced with an examination of use cases and detailed scenarios shared by the AMI Enterprise community, which were contributed by SCE This analysis is elaborated on in section 24.1.
From this analysis, we extracted a logical architecture (presented in section 24.2) summarizing the communications among logical components These logical components are further elaborated in section 24.3.
We utilized security domains to enhance the characterization of components concerning additional security considerations This comprehensive understanding of the AMI domain, its components, and their communication patterns informed the selection of requirements for each logical component.
U SE CASE AND SCENARIO ANALYSIS
The community has developed various collections of use cases; however, we chose to focus on the AMI Enterprise use cases outlined on SmartGridiPedia This choice was influenced by specific criteria that guided our decision-making process.
rich information content (in the form of a collection of detailed scenarios for each use case)
good coverage of AMI features
community review of the use cases and scenarios, reflecting some degree of community consensus in the AMI space
This security profile focuses on specific use cases related to Advanced Metering Infrastructure (AMI) features and business processes, particularly scenarios B1-B4, C1-C4, D4, I1-I3, and S1, which encompass Consolidated Demand Response and Load Control.
While this set of scenarios may not cover all possible aspects, it provides valuable insights into the interactions among typical components of an Advanced Metering Infrastructure (AMI) system We have identified the types of information and control signals exchanged between these components, as well as which components operate independently from one another.
Figure 1: A UML activity diagram for Scenario 2 of use case B2
Figure 1 shows one of the scenarios as an example From diagrams of this kind, we extracted
In the activity diagram of the business flow, each swim lane illustrates a distinct entity, with certain components representing system elements and others denoting human actors For this analysis, we focused specifically on system components, while also excluding certain elements that fall outside the scope of the AMI profile.
Arrows between nodes signify the communication of information or control signals between components, while they may also indicate the sequence of activities This necessitates some interpretation, focusing on the essential aspects of the information and control exchanged among the components.
The analysis of use cases revealed several inconsistencies and oversights, particularly in scenario 9 of use case B1, where a meter communicates directly with the MDMS without involving a Head End This contradicted numerous other scenarios and was deemed an oversight Corrections were implemented in multiple instances to ensure a coherent and consistent logical architecture.
L OGICAL ARCHITECTURE
A logical architectural view illustrates the relationships between conceptual components defined by shared functionalities It focuses on the interactions of these logical components without addressing deployment details, such as the distribution of functions across hosts or network segments Additionally, it does not encompass all the terminology or physical configurations associated with various products.
The logical architectural components have only the meaning defined in this document, regardless of how some other party may define the same terms
Any product that incorporates a logical component must meet all applicable security requirements outlined in Section 53, regardless of whether it uses the component's name or combines functions from multiple components Furthermore, products that utilize functions from several components are required to fulfill all security requirements associated with each respective component.
This perspective is derived from the use cases and scenarios outlined in Section 24.1, with some simplifications made for clarity The figures emphasize the interactions between components that fall within the AMI profile, as well as the communications between in-scope and out-of-scope components.
In this profile, we exclude all communications involving out-of-scope components to maintain focus on relevant elements For instance, while the source material details interactions between the Enterprise Asset Management component and the Workforce Management System, this information is intentionally omitted However, we do include details about interactions among human actors to provide a comprehensive understanding of the in-scope components.
Figure 2: AMI Logical Architectural View (Internal Perspective)
The draft of the logical architecture, illustrated in Figure 2, emphasizes the interactions among components relevant to this profile, with each interaction marked by a numbered line Dashed lines indicate connections between in-scope components and those that are out-of-scope or involve external actors Additionally, Table 1 provides a summary of the communications and commands exchanged among the in-scope components, showcasing a range of interactions without striving for completeness.
After the filtering process, several actors, including the Customer, Customer Representative, DG Evaluation Team, and Third Party Organizations, were left without connections to other actors or relevant components, leading to their removal from the diagram.
Line # Direction Summary of communication
AMI meters facilitate a range of functionalities including meter read requests, on/off commands, pricing data, provisioning requests, firmware updates, and prepayment information They transmit crucial data to the AMI Head End, such as meter read data, various meter events like tampering, outages, and restorations, as well as confirmations for actions like meter activation, load shedding start/end, and provisioning Additionally, they support Home Area Network (HAN) communication and maintain error logs for efficient monitoring and management.
2 to MDMS Meter read data, various meter events and confirmations,
HAN equipment responses, outage and restoration notifications, event logs to AMI Head End Meter read requests, load shed commands, planned outage information, HAN equipment commands
6 to AMI Head End Meter read data to Third Party Meter/Submeter
The Field Tool/Device efficiently stores essential meter data, including meter readings and identification, along with logs for turn on/off confirmations, successful AMI system registrations, and meter test results It facilitates AMI Meter Requests for comprehensive meter data and logs, while also providing credentials for field personnel Additionally, the tool allows for issuing turn on/off commands, accessing meter configuration data, and requesting communication tests and self-test results.
10 to MDMS Stored meter data to Field Tool/Device None identified
Management System Problem meters report, meter service order request, meter read data to MDMS Meter read requests, closed meter order status
The management system efficiently handles various meter events, including intrusion alerts, inversion issues, and detected customer loads It monitors meter status changes, location updates, and network disconnections, while also processing service order requests and confirming firmware update downloads to the AMI Head End Additionally, the system accommodates non-electric meter read requests, meter reconfigurations, firmware updates, and commands for executing firmware updates, alongside handling HAN device ping requests.
Management System Meter events, activity records to AMI Head End Non-electric meter read requests 4
22 to AMI Head End Meter read data, establish connection confirmation, non- electric meter events to Non Electric Meter Meter read requests, establish connection commands, meter event monitoring requests
24 to MDMS Load shed control notification to DRAACS Load shed event end
25 to DRAACS Load control request to Grid Control Center Load shed report
4 This probably shouldn't go from both AMI Management System and AMI Network Management System to Head End.
Line # Direction Summary of communication
37 to AMI Head End Power outage and restoration notifications, meter last gasp messages, collector running on battery messages, collector power restored messages to AMI Communications Network Device None identified
Network Device Meter last gasp messages to AMI Meter None identified
Management System Meter inventory requests to AMI Forecasting System Meter inventory responses
Table 1: Summary of Communication in AMI Logical Architectural View (Internal
Figure 3: AMI Logical Architectural View (Full Perspective)
Figure 3 illustrates an expanded view that incorporates out-of-scope components and actors, with dashed lines replaced by numbered lines for clarity While interactions involving these out-of-scope elements are not depicted, Table 2 provides a summary of communications between in-scope components and out-of-scope actors This summary highlights a range of communications and commands, though it does not aim to be exhaustive.
Line # Direction Summary of communication
3 to MDMS Meter read requests, meter event acknowledgements, data requests to Data Retriever Meter read data, meter events, requested data, service order results
MDMS facilitates various data requests, including meter read data, non-electric meter event monitoring, and customer energy data It also enables commands for customer Home Area Network (HAN) equipment directed to the Third Party Data Portal This comprehensive system ensures efficient management of meter data, non-electric events, and customer responses related to energy consumption.
7 to AMI Head End None identified to AMI Head End Operator Meter reading report (regarding non-responsive meters)
8 to MDMS None identified to Field Person Pickup read requests
Schedule upgrades to AMI Head End
13 to MDMS Billing determinant requests, prepayment requests, DG enrollment information to CIS Billing determinants, prepay meter events (i.e., credit mode), successful meter program confirmations, unexpected/unauthorized DG notifications
The AMI Head End manages a range of commands, including on-demand turn off, scheduled on/off, and load limit adjustments, while also handling meter energized status requests and electric price data It facilitates meter provisioning requests and sends various messages, such as informational updates, prepayment service notifications, and rate changes to the Customer Information System (CIS) Additionally, it confirms successful operations like turn on/off actions, load limit adjustments, meter provisioning requests, and Home Area Network (HAN) communications, along with providing the status of energized meters.
16 to AMI Meter Various confirmations (event notifications, event start/end,
The HAN communication system provides essential updates to the HAN Display Device, including prepayment status receipts, notifications for scheduled turn-offs, load limits, and load control events It also delivers electric price data, energy consumption statistics, and various messages related to informational updates, testing, and both planned and unplanned outages Additionally, it includes details about the prepayment status and prepay meter events, such as credit mode activities.
To ensure successful operations, it is crucial to confirm the Meter ID for field tools and devices, close out work orders, and report any instances of marginal coverage or soft registration Additionally, toggling electric service for field personnel requires confirmation of the turn-on or turn-off status, as well as a match with the Meter ID Accurate meter read data is essential for assessing the success of the AMI system registration, and timely work order alerts play a significant role in maintaining efficiency.
Management System Non-electric meter read requests to Third Party Data
5 A listing of the raw material used to compile these summaries is found in Appendix A.
Line # Direction Summary of communication
23 to MDMS None identified to Non-electric Utility Identification of non-electric meters where no data is received
The AMI Meter facilitates various confirmations, including event start and end notifications, along with the response of customer Home Area Network (HAN) equipment to Load Control Device commands It effectively communicates load control event notifications and provides essential messages regarding event timing, ensuring seamless interaction between customer devices and the grid.
C OMPONENT DEFINITIONS
AMI Communications Network Device
The AMI Communications Network device plays a crucial role in facilitating communication between AMI components in the field and the utility operations center It effectively relays, routes, and aggregates information, ensuring seamless data exchange between the operations center and field devices.
AMI Forecasting System
The AMI Forecasting System tracks the number of meters available for deployment and maps the inventory to anticipated deployment schedule It maintains an appropriate level of meter inventory.
AMI Head End
The AMI Head End facilitates two-way communication with AMI Meters to collect data and execute commands, ensuring efficient load balancing on the communication network during scheduled meter readings It addresses communication failures by retrying meter connections and continuously monitors the health of the advanced metering infrastructure Additionally, it enables remote management for firmware updates, configuration changes, provisioning functions, and diagnostics control.
AMI Meter
An AMI Meter is a sophisticated electric revenue meter that facilitates two-way communication with utility providers, acting as a bridge between the utility, customer premises, and home area network (HAN) devices or load controllers It accurately measures, records, and displays energy consumption and generation data while transmitting this information, along with text messages and event logs, to authorized systems Additionally, some AMI Meters come equipped with a disconnect switch, allowing for remote service connection or disconnection.
AMI Meters are deployed on devices located in the field (e.g., on the side of a customer's home), and as such have limited physical protection.
AMI Meter Management System
An AMI Meter Management System serves as a centralized data repository for all information related to AMI Meters, monitoring their deployment and operational status while facilitating firmware updates Unlike the MDMS, which concentrates on metrology and usage data, the AMI Meter Management System is primarily supply chain oriented.
AMI Network Management System
An AMI Network Management System serves as a centralized data repository, storing vital information about each AMI communication device, their individual configurations, and the overall network setup Additionally, it monitors the operational status of AMI communications, ensuring efficient management and performance.
6 This component was labeled MDMS: AMI Management System in the source scenarios.
7 This component was labeled MDMS: AMI Network Management System in the source scenarios.
Demand Response Analysis and Control System (DRAACS)
A DRAACS facilitates demand response by sending event notifications to meters and load control devices via the AMI system It offers demand response solutions to operators and market traders, utilizing predefined customer groupings and statistical analysis of historical responses.
Field Tool/Device
Field tools and devices are portable computing systems designed for field personnel to connect with various components, enabling them to conduct maintenance, upgrades, and diagnostics These tools utilize wireless connections to utility systems, facilitating seamless communication of essential information required for installations and other services.
Grid Control Center
A Grid Control Center integrates the utility's operations centers with real-time data and software applications, such as Energy Management Systems (EMS) and Supervisory Control and Data Acquisition (SCADA) It includes displays that aid in decision-making and encompasses external applications that interact with grid control systems.
Meter Data Management System (MDMS)
A Meter Data Management System (MDMS) efficiently aggregates, validates, and estimates meter data, including energy usage, generation, and meter logs It temporarily stores this information before transferring it to a data warehouse, ensuring that authorized systems have access to accurate and timely data.
Non-Electric Meter
Non-electric meters are essential devices for measuring services such as gas and water These meters often utilize AMI networking infrastructure to relay data to non-electric utilities Similar to AMI meters, non-electric meters are installed in the field, which means they have limited physical protection.
Third Party Meter/Submeter
A Third Party Meter or Submeter is a metrology device designed to monitor usage within a specific segment of a distribution network, providing more detailed data beyond what a main meter offers Unlike traditional meters, submeters may not be owned by the utility company These devices are installed in various locations, which means they often have limited physical protection against environmental factors.
AMI S ECURITY S ERVICE D OMAINS
Delineation of Domains
The 2009 AMI Security Service Domains diagram closely resembles the original from the AMI System Security Requirements 10, featuring a formatting update and a technical modification Notably, the diagram has been rotated 90 degrees counter-clockwise for improved readability, and the Utility Enterprise domain now directly interfaces with the Managed Network domain.
Figure 4: AMI Security Service Domains
Each of the AMI Security Service Domains represents a comprehensive set of concerns including (but not limited to) ownership, control, physical access, logical access,
9 THE INTEGRATED ENERGY AND COMMUNICATION SYSTEMS ARCHITECTURE, EPRI, Palo Alto, CA and Electricity Innovation Institute, Palo Alto, CA: 2003
10 AMI System Security Requirements v1.0 Revised, UCA International Users Group – AMI-SEC Task
In Knoxville, TN, the 2008 framework emphasizes the importance of information sensitivity and business functionality It highlights that physical assets are fixed within designated areas and are not expected to shift or change domains Additionally, information flows systematically across these areas, transferring between domains without bypassing boundaries, ensuring a structured and secure exchange process.
The drawing assumes other utility enterprise applications beyond AMI such as Outage
Management and Customer Information will integrate via the Utility Enterprise domain, while field applications like the Home Area Network and various utility meters, including gas and water, will connect through the Premise Edge or Utility Edge domains.
Domain Characteristics
A comprehensive analysis of each AMI Security Service Domain equips security analysts with valuable tools for evaluating controls, but detailed discussions are not included here as they are not crucial for implementing the recommendations Below, we offer a succinct overview of each AMI Security Service Domain, which primarily aims to address key questions related to security measures.
Where does it reside in terms of utility facilities and physical environmental controls?
Who is responsible for operating it?
With what (types of) systems does it interface?
The AMI Security Service Domains establish a framework to standardize security requirements across various logical components, effectively preventing unauthorized access from less critical elements, such as print servers, to more sensitive ones, like customer databases Our approach ensures that all components within a security domain are treated equally, as much as practical or applicable This concept aligns with the NERC CIP standards, which also focus on the protection of Critical Cyber Assets.
Cyber Assets within the same Electronic Security Perimeter
We have also included some questions to help the analyst determine whether a component falls into a given domain In examining these questions, we used the following rules:
1 A component should satisfy all the questions posed for a particular domain
2 If a component satisfies all questions for more than one domain, the component should be decomposed further until each sub-component maps to one and only one domain
11 North American Electric Reliability Corporation 2006, June 1 NERC Critical Infrastructure Protection (CIP) Retrieved from http://www.nerc.com/page.php?cid=2|20
3 If a component does not satisfy all the requirements of any domain, something is wrong and we need to either: a re-examine the asset b re-examine our delineation of domains c determine the component is out-of-scope Using this approach, we were able to clarify our understanding of each component and several key characteristics that influenced subsequent control selection
Domain Description Criteria Examples (AMI)
Utility Enterprise Processing and/or storage of business application data, and support of utility enterprise applications
Is the asset centrally located (vs field deployed and distributed)? (Y)
Meter Data Management System (MDMS), Customer Information System (CIS)
The asset plays a crucial role in managing business operations within the Utility Edge domain, focusing on the processing of data rather than communication behavior Additionally, it effectively interfaces with utility enterprise applications and their associated assets, ensuring seamless integration and functionality.
Network Collection, transmission, translation, staging, and associated transformation of field communications
Is the asset centrally located (vs field deployed and distributed)? (Y)
AMI Head End, AMI Network
Does the asset provide an interface for assets in the Utility Enterprise domain to access assets in the Utility Edge or Premise Edge domains? (Y)
Does the asset provide a singular logical point of interface to assets in the Utility Enterprise domain for business data from assets in the Utility Edge or Premise Edge domains?
Network Oversight, administration, and control of Automated Services and
Does the asset provide an interface for monitoring or manipulation of functions performed by assets in the Automated Network or Communications domains?
Communications Relaying, routing, and aggregation of field communications
Is the asset field deployed?
Field Area Network (FAN), Backhaul
Is the asset part of the communications mechanism connecting centralized utility applications with distributed, field deployed assets? (Y)
Utility Edge Support of field deployed utility equipment and devices (i.e., monitoring, measurement, and/or control)
Is the asset field deployed?
Is the asset owned and operated by the utility? (Y) Does the asset perform a function critical or essential to the operations or business of the utility? (Y)
Premise Edge Support of customer equipment and devices (i.e., provisioning, monitoring, measurement, and/or control)
Is the asset field deployed?
(HAN) Interface Does the asset provide an interface for the customer (or their assets)? (Y)
Table 3: AMI Security Service Domain Characteristics
The AMI Security Service Domains establish clear boundaries within the system, yet many devices and applications in AMI systems often overlap multiple domains To address this, we further decomposed these components into distinct sub-components, ensuring each fits into a single domain Recommended controls may apply to these logical components or their sub-components, and ongoing efforts will enhance recommendations, providing more detailed guidance and potentially refining the allocation of controls from components to sub-components.
One particular example of interest is the AMI Meter, which as a whole would span the
The article discusses the decomposition of components within the Communications, Utility Edge, and Premise Edge domains, specifically focusing on the metrology and disconnect switch in the Utility Edge domain, the Field Area Network interface in the Communications domain, and the Home Area Network interface in the Premise Edge domain Each sub-component must meet the security requirements outlined in Section 4.3 relevant to its function Consequently, an AMI Meter inherits security requirements based on the characteristics and constraints of these domains.
Domain Analysis – Significance, Relevance, and Influence
The AMI Security Service Domain effectively facilitates a unified understanding of security constraints and expectations associated with logical components By analyzing these components through various security characteristics as outlined by the AMI Security Service Domains, we gained deeper insights into their relevant attributes, which informed our selection of appropriate security controls.
The controls outlined in this document have been tailored to meet the mission-level requirements identified in the associated AMI system use cases Section 5 presents a comprehensive set of controls recommended for AMI systems and their components However, it's important to note that not all of these controls will be applicable or feasible for every AMI component.
Appendix A bridges this gap by mapping controls to applicable components Decisions regarding applicability were based on the following criteria:
Role of the component in the logical architecture (including its functional role in use cases and its interactions with other components and actors),
AMI Security Service Domain for the component,
Characteristic needs for the AMI Security Service Domain,
Technological capability of the component, and
Security and domain expertise relevant to components of its kind.
The AMI Security Service Domain analysis serves as a valuable tool for enhancing understanding of security constraints and expectations related to identified logical components By evaluating these components through various security characteristics outlined in the AMI Security Service Domains, we identified opportunities for decomposition into sub-components, tailored needs based on relevant attributes, and strengthened the rationale for selecting appropriate controls.
The controls outlined in this document are adapted from the DHS Catalog of Control Systems Security and have been tailored for Advanced Metering Infrastructure (AMI) security The DHS control section numbers are included for reference purposes only and do not imply that these controls are directly from the DHS For controls developed by the ASAP-SG team that lack a DHS equivalent, the prefix "ASAPAMISP-" is utilized instead of "DHS-".
This section outlines the controls relevant to various components of an Advanced Metering Infrastructure (AMI) system, as detailed in Appendix A Many of these controls are applicable to all elements of the logical architecture specified in Section 4, indicating their relevance to all AMI components mentioned in Section 4.3.
DHS-2.8 System and Communication Protection
System and communication protection involves measures to safeguard the AMI components and their communication links from cyber intrusions While it may seem that this protection should encompass both physical and cyber aspects, this section focuses solely on cyber protection, with physical security discussed in Section 2.4 of the DHS controls.
12 Department of Homeland Security, National Cyber Security Division 2008, January Catalog of Control Systems Security: Recommendations for Standards Developers Retrieved from http://www.us- cert.gov/control_systems/
AMI components must shall isolate telemetry/data acquisition services from management services
The AMI system management service needs to be physically or logically separated from telemetry/data acquisition services and information storage and management services
To enhance database management security, separation can be achieved through various methods, including utilizing different computers, central processing units, operating system instances, network addresses, or protocol ports like TCP ports Implementing these strategies minimizes the risk of unauthorized access to data acquisition servers and helps mitigate potential damage from compromised systems.
To enhance security, it is essential to disable configuration and testing ports for AMI components when they are not in use For systems of high criticality, it is recommended to physically disconnect the device to prevent unauthorized access.
Implementing these precautions minimizes the risk of unauthorized access to a data acquisition server and mitigates potential damage from a compromised system It is essential to disable the configuration and testing ports for AMI components when they are not in use.
Depending on the criticality of the system it may be advised that a device be physically disconnected.
The AMI system management service mustshall be physically or logically separated from telemetry/data acquisition services and information storage and management services
(e.g., database management) of the systemNone
The security requirements for access to configuration/management services on a given
AMI components exceed the requirements for accessing telemetry and data acquisition services Without proper isolation, the communication channels for these services can be exploited to gain unauthorized access to management services Such exploitation may arise from implementation vulnerabilities, misconfigurations, or other factors By ensuring a clear separation between services, the potential impact of vulnerabilities in lower-security services is minimized, preventing them from being used to compromise higher-security services.
AMI components must shall isolate security functions from non-security functionsuse segregation of duties for security and non-security functions
AMI components are required to ensure the separation of security functions from non-security functions, often referred to as separation of duties, through the use of partitions and domains This includes controlling access to and maintaining the integrity of the hardware, software, and firmware involved in these functions Each executing process within the AMI system must operate within a distinct execution domain, such as a separate address space However, some AMI components may lack this capability In such cases, the organization must outline its risk acceptance and mitigation strategies in the AMI system security plan.
The AMI system must employ the following underlying hardware separation mechanisms to facilitate security function isolation:
1 Each AMI component isolates critical security functions (i.e., functions enforcing access and information flow control) from both non-security functions and from other security functions;
2 Each AMI component minimizes the number of non – security functions included within the isolation boundary containing security functions;
3 AMI security functions are implemented as largely independent modules that avoid unnecessary interactions between modules;
4 In each AMI component, security functions are implemented as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers
5 Passwords and/or security keys should be of limited value, avoiding significant reuse of keys or passwords between different components and users For example, compromising one key must not allow compromise of an entire network
The AMI system shall employ the following underlying hardware separation mechanisms to facilitate security function isolation:
6 Each AMI component isolates critical security functions (i.e., functions enforcing access and information flow control) from both non-security functions and from other security functions;
7 Each AMI component minimizes the number of non – security functions included within the isolation boundary containing security functions;
8 AMI security functions are implemented as largely independent modules that avoid unnecessary interactions between modules;
9 In each AMI component, security functions are implemented as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers
To enhance security, passwords and security keys should have limited value and should not be reused extensively across different components and users This approach ensures that if one key is compromised, it does not jeopardize the integrity of the entire network.