NERC Security Requirements – What Vendors Should Provide

1. NERC Security Requirements – What Vendors Should Provide James W. Sample, CISSP, CISM Manager of Information Security California ISO

2. 1201 – Cyber Security Policy 1202 – Critical Cyber Assets 1203 – Electronic Security Perimeter 1204 – Electronic Access Controls 1205 – Physical Security Perimeter 1206 – Physical Access Controls 1207 – Personnel 1208 – Monitoring Physical Access 1209 – Monitoring Electronic Access 1210 – Information Protection 1211 – Training 1212 – Systems Management 1213 – Test Procedures 1214 – Electronic Incident Response Actions 1215 – Physical Incident Response Actions 1216 – Recovery Plans NERC 1200 Cyber Security Standard

3. Provide detailed documentation that includes: Detailed data flow diagrams Source/destination systems Required services/ports (protocols) Interconnectivity requirements Access points 1203 – Electronic Security Perimeter

4. Deliver systems: With detailed documentation around access controls That require authentication and authorization using unique user Ids Where access management is simple Where access control exists at all layers (e.g. operations system, database, application) 1204 – Electronic Access Controls

5. Provide detailed documentation that includes: List of all personnel supporting product plus access required, including sub-contractors Promptly notify customer of any changes in support personnel Conduct proper background checks on all personnel provide evidence to customer of background check 1207 – Personnel

6. Deliver systems: With detailed documentation around access monitoring, including error codes That provided auditable logging of events That synchronize with a central time source That log to a remote central repository With tools to analyze audit logs where appropriate 1209 – Monitoring Electronic Access

7. Deliver systems: With detailed documentation that identifies critical configuration settings, processes, libraries, etc. that should be monitored 1210 – Information Protection

8. Provide security training specific to your product Document security features, including configuration and administration procedures, for your product Provide detailed documentation for rebuilding the system securely 1211 – Training

9. Deliver systems: Where access management is simple (e.g. password can be changed easily and periodically) With all unnecessary ports and services disabled That use secure protocols verses insecure protocols Promptly test all released operating systems and third-party patches to allow for proper and timely patch management With remote administration securely configured (e.g. modems, VPN, etc.) 1212 – Systems Management

10. 1213 – Test Procedures Deliver systems: • With a set of test procedures that the customer can use to verify system security

11. Deliver systems: With documents designed specifically for disaster recovery 1216 – Recovery Plans

12. General Recommendations • Design with system security in mind up front • Work with customer to create an integrated solution • Vendors should sponsor annual security user group meetings • Keep it Simple, Stupid (KISS)

13. Characteristics of a Secure System James W. Sample, CISSP, CISM Manager of Information Security California ISO

14. Characteristics of a Secure System Security controls should be applied at the: • Application Level • Operating Level • Network Level Disclaimer: The following slides are security areas that system developers should consider, at a minimum, while developing systems. They are not all inclusive and should not be considered as a comprehensive list or industry best practices.

15. Application Level Security Application should have the following characteristics at a minimum: • Identity Management • Application Cryptography • Session Management • Data Input Validation • Application Patching • Auditing/Logging/Monitoring • Secure Programming/Code Integrity

16. Application Level Security Identity Management • Authentication • Verify the identity of a user (e.g. unique user id) • Access Control • Ensure users are given access to only resources they are entitled to see/use • User Management • Processes & supporting infrastructure the enables creation, maintenance, suspension, deletion, and use of digital identities • Federated Identity Management (where applicable) • Ability to establish trust relationships between differed security domains to enable passing of authentication, authorization, and privacy assertions

17. Application Level Security Application Cryptography (biggest, baddest tool in the application programmer’s arsenal) • Public Key Infrastructure (PKI) • Enable applications to communicate and send information securely • Secret Storage • Stores critical information securely • XML Cryptography • Important part of building a secure web service

18. Application Level Security Session Management Each method below has certain advantages and disadvantages: • Session ID information embedded in the URL • Received by the application through HTTP GET requests when the client clicks on links embedded within a page • Session ID information stored within the fields of a form and submitted to the application • Embedded within the form as a hidden field and submitted with the HTTP POST command • Through the use of cookies

19. Application Level Security Data Input Validation • Check data entered before accepting • Field Level Validation • Occurs at the “key press” event • Form Level Validation • Occurs at the time the user clicks Ok, Save, or Update controls

20. Application Level Security Application Patching About 95 % of hacker attacks occur against known vulnerabilities in software • Patch Identification • Proactively identify vulnerabilities within your software • Proactively track patches released by 3rd party software you use • Patch Release • Release patches for your software in a timely manner • Patch Verification • Verify that 3rd party patches don’t break your software and notify your customer of results

21. Application Level Security Auditing/Logging/Monitoring • Log events in a write-only fashion • Audit/Log the following events at a minimum: • Successful/unsuccessful logon attempts • Logon/logout times • Source of connection • Failed object access events • Successful object access (key objects) • All configuration changes • Actively monitor security events • Setup alert notifications • Actively monitor security controls

22. Application Level Security Secure Programming/Code Integrity • Don’t hardcode passwords • API Definition – define application interfaces • Safe Function Calls • Memory Management • Error Handling – check all function return codes and take appropriate action for error conditions • Use secure protocols • No backdoors • Time sync applications to central time source

23. Operating System Level Security Operating Systems should have the following characteristics at a minimum: • Identity Management • Authentication • Access control • User management • Harden systems • Use secure protocols • Disable unused services • Configure services securely • Patch Management • Keep system patches up to date • Auditing/Logging/Monitoring • Configure operating systems to audit/log security events • Setup alert notifications • Actively monitor security controls • Time sync applications to central time source

24. Network Level Security Network should have the following characteristics at a minimum: • Identity Management • Authentication • Access control • User management • Harden systems • Use secure protocols • Disable unused services • Configure services securely • Patch Management • Keep system patches up to date • Implement network access controls (e.g. firewalls, etc.) • Auditing/Logging/Monitoring • Configure devices to audit/log security events • Setup alert notifications • Actively monitor security controls