Use Case 5: Information Repository Processes New Data Use Case Description: An Information Repository receives new or updated data and responds by sending the data to any Central Application, External Application, or other Information Repository which may be linked to or using said data from the Information Repository. Preconditions: The Information Repository is able to receive data updates (from Sensors, Actuators, Field Applications, Central Applications, External Applications, and other Information Repositories). A valid relationship has been established between an Information Repository and any actor which is attempting to write new data to or update existing data in the Information Repository. A valid relationship has been established between an Information Repository and any actor which is interested in/subscribed to specific data within the Information Repository. Minimal Guarantees: An Information Repository will not accept data from an unauthorized source (Actor). Data which has been written to or updated in an Information Repository will not be altered by the Information Repository. Success Guarantees: Whenever an Information Repository receives authorized data writes or updates, all interested/subscribed Central Applications, External Applications, or other Information Repositories will be notified. An Information Repository will provide information, such as time and/or quality, about the validity of the data being provided to Central Applications, External Applications, or other Information Repositories. Trigger: This use case is triggered whenever data is received by an Information Repository (from Sensors, Actuators, Applications, Central Applications, External Applications, and other Information Repositories). Diagram: Use Case 5 – Information Repository Processes New Data Main Success Scenario: 1: An Information Repository receives new data from a Sensor, Actuator, Field Application, Central Application, External Application, or other Information Repository. The Information Repository then records the data within its associated storage mechanism. 2: The Information Repository determines if there are any Central Applications that are interested in the data. This may be via a pre-existing publish/subscribe mechanism between the Information Repository and Central Application(s).
Impact analysis of all proposed changes to the DM system 2.6.4, 2.10.5 Authorization and documentation of changes, maintenance, and repair to the DM system - The organization shall document each scheduled change to the DM system or its components. At a minimum, this documentation shall include; 1) date and time of proposed change, 2) individual or organization requesting change, 3) detailed description of the change, and 4) approval of the change. Unscheduled changes or repairs to the DM system shall be reviewed on a daily basis for possible impact to other DM system functions and scheduled changes. Furthermore, the organization shall be capable of determining the status of all changes (e.g. planned, in progress, complete) at all times. 2.6.3, 2.10.5, 2.10.6, 2.10.8 Policy.8 Policy – Information, Media, and Document Management The organization develops and documents a DM system security policy, supporting plans, processes, and procedures that address information, media, and document management aspects of the DM system security program including the following areas: Managing control system-related data for both electronic and paper data and access to the data based on formally assigned roles and responsibilities or contractual and confidentiality agreements with external parties 2.9.2, 2.9.3, 2.9.5, 2.9.6, 2.9.7, 2.13.2, 2.14.12, 2.18.8 Classification of information and documentation to indicate the protection required commensurate with its sensitivity and consequence 2.9.4, 2.9.6, 2.9.10, 2.9.11, 2.13.3, 2.13.4 Destruction of written and electronic data 2.9.8 storage, handling, sanitation, and disposal 2.13.5, 2.13.6, 2.13.7 Policy.9 Policy – Auditing and Reporting The organization develops and documents a DM system security policy, supporting plans, processes, and procedures that address auditing and reporting aspects of the DM system security program including the following areas:
for device to device communication. Protection.33 Authenticator Feedback The organization obscure the feedback of authentication information during the authentication process. DHS 2.15.13 Protection.34 Cryptographic Module Authentication The DM system components shall employ cryptographic module authentication for authenticating users and devices. DHS 2.15.14 Protection.35 Information Flow Enforcement The organization enforces the flow of information within the DM system based on applicable policy. Organizations shall place software or hardware firewalls at designated network segment boundaries that serve as choke points for filtering information across field and central devices. DHS 2.15.15 Protection.36 Password Management The system provides the necessary capabilities to enforce the use of strong passwords, in accordance with FIPS 112, and to protect passwords from potential exposure. This includes: 1. Ensuring that passwords never cross component boundaries in the clear. 2. Ensuring that all stored passwords are encrypted in accordance with FIPS 140-2 or hashed using a cryptographic one-way hash function in accordance with FIPS 180-2. 3. Ensuring that passwords are never included in or allowed to be embedded into tools, DHS 2.15.16
smallest number of endpoints, workstations, devices, and services possible. Protection.45 Non-adjacent Network Restrictions Prohibit all direct communication (without additional, appropriate security controls) between devices/systems in network segments. DHS 2.8.7, 2.8.5 Protection.46 Internet and e-mail Restrictions No system, workstation, or device in any DM network should have access to the Internet. This includes workstations in the DM Control Systems User Network. Utility employees primary workstations are in these Internet-restricted network segments should be provided secondary accessible systems for Internet and email access. DHS 2.8.7, 2.8.5 Protection.47 Centralized Authentication Authentication servers for the DM systems shall be separate from authentication servers used for corporate and business systems. The DM authentication system should be placed in the DM Control System Server Network and should not have any trust relationships with other non-DM centralized authentication systems. DHS 2.8.7, 2.8.5 Protection.48 Secure Coding Practices DM software components shall be developed in accordance with secure coding standards (e.g., the CERT C secure coding standard) or avoidance of cataloged coding flaws and weaknesses (e.g., the NIST SAMATE Reference Dataset or the MITRE DHS 2.8.5, 2.5.8