Control Center Protection Profile Made Easy

1. Control Center Protection Profile Made Easy Presented to PCSRF By Dale Peterson, Digital Bond peterson@digitalbond.com

2. What is a Protection Profile (PP)? A set of functional and assurance security requirements for a product Follows the format and methodology of the internationally recognized Common Criteria Industry groups, like PCSRF, can define security requirements for vendors

3. Is This Duplicated Effort? No Most other efforts are not geared at certified products or systems Could feed into ISA 99 Part 4 Could be used as an assurance measure as discussed by Peter Miller for indemnification Needs to be done somewhere

4. Control Center Protection Profile A set of requirements for an Industrial Control System (ICS) Control Center Covers a portion of an ICS Includes control servers, historians, HMI, Control Center network systems, and more May be located in many physical locations Does not include PLC, RTU, and field devices TOE � Target of Evaluation

7. Why A Control Center PP? Strong, secure solutions exist today from multiple vendors, including: Strong, two-factor user authentication Device & message integrity Role and location based access control Encryption and much more Secure field devices may be years away

8. Protection Profile Document Very technical document for certification Designed to specify requirements for engineers Format and language from Common Criteria Very specific to allow for 3rd party evaluation ISA SP99, CIDX, API, NERC, etc. are better for security guidance and best practices

9. Complete Protection Profile All the required sections are complete All the assignments and selections are complete All the rationale are complete Incomplete - NEEDS Peer Review Working group is plowing through the requirement classes

10. Threats T.Transmitted_Data_Modification An attacker may modify part or all of an authorized data stream and thereby attack the integrity of the TOE. T.Credential_Cracking An attacker may repeatedly try to guess authentication credentials in order to gain unauthorized access to the functionality of the TOE.

11. Objectives O.Command_Authentication Individual devices in the TOE must authenticate the integrity of all commands and responses sent from another TOE device prior to acting on or storing the data. O.Subject_Authentication Individual subjects in the TOE must perform mutual authentication prior to communication with another TOE subject or object.

12. Functional Requirements FPT_ITT.3.1 The TSF shall be able to detect modification of data, substitution of data, re-ordering of data, and deletion of data for TSF data transmitted between separate parts of the TOE.

13. Functional Requirements FDP_IFF.1.2 (1) The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [(a) the IP address of the source subject is an authorized IP address in the TOE (b) the transport protocol occurs on the expected port (c) the data integrity of the information is cryptographically proven as identical to the data sent by the source subject (d) the source subject�s identity is cryptographically authenticated.]

14. Assurance Requirements How a product or system proves in meets the requirements 7 Evaluation Assurance Levels (EAL) Very easy to complete in a PP Select an EAL Level Use the specified assurance requirements Initial selection is EAL 3 Methodically tested and checked EAL 4 is methodically designed, tested and checked

15. Assurance Requirements TOE CM Coverage (ACM_SCP.1) Content and presentation of evidence elements: ACM_SCP.1.1C The CM documentation shall show that the CM system as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation. ACM_SCP.1.2C The CM documentation shall describe how configuration items are tracked by the CM system.

16. Security Functional Policy (SFP) Access Control SFP Defines access privileges by role and information type Defines user authentication requirements Information Flow Control SFP Security requirements for data communication This Protection Profile has three Internal, Remote, and Outside

17. Internal SFP Covers all communication within a physical boundary Communication in a physical Control Center Security requirements summary Authorized source address and protocol Crypto authentication of source identity Crypto authentication of data integrity

18. Internal SFP

19. Remote SFP Covers all communication in a logical Control Center but crosses a physical security boundary Main Control Center to Backup Control Center Remote HMI to Control Center Security requirements summary All of the requirements as the Internal SFP Plus encryption to protect confidentiality over a shared or unprotected WAN

20. Remote SFP

21. Outside SFP Covers all communications from systems not covered by this Protection Profile PLC/RTU communication with a control server Historian with an external business server Security requirements summary Authorized source address and protocol Parameters are within reasonableness boundary Message (packet) length is appropriate

22. Outside SFP

23. Access Control SFP Three required roles for access control Administrator Operator Display Different requirements for different roles Example: Strong two-factor authentication

24. What about Field Devices? Industry security standards are required Mutual authentication of identity Data integrity verification Optional encryption for privacy Timing and latency are major issues This may take a while, but . . . Retail banking had a similar many-to-one environment in ATM / POS

25. What about Field Devices? Agree on the requirements Develop a Protection Profile Common Criteria �inter-TSF� Defines how two PPs reference each other The Field Device PP replaces the Outer Information Flow Control SFP We then have a complete, certified control system!

26. How Can You Help? Join the working group We have a good team working on it Could use more vendor participation Tackling a �class� of requirements per call Are the selected requirements correct? Are the selections and assignments correct? Is this in the best format to facilitate evaluation?