July 14, 2004 1

NERC Security Requirements – What Vendors Should Provide

James W. Sample, CISSP, CISMManager of Information SecurityCalifornia ISO

July 14, 2004 2

NERC 1200 Cyber Security Standard

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

July 14, 2004 3

1203 – Electronic Security Perimeter

Provide detailed documentation that includes:

Detailed data flow diagrams Source/destination systems Required services/ports (protocols) Interconnectivity requirements Access points

July 14, 2004 4

1204 – Electronic Access Controls

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)

July 14, 2004 5

1207 – Personnel

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

July 14, 2004 6

1209 – Monitoring Electronic Access

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

July 14, 2004 7

1210 – Information Protection

Deliver systems:

With detailed documentation that identifies critical configuration settings, processes, libraries, etc. that should be monitored

July 14, 2004 8

1211 – Training

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

July 14, 2004 9

1212 – Systems Management

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.)

July 14, 2004 10

1213 – Test Procedures

Deliver systems:

With a set of test procedures that the customer can use to verify system security

July 14, 2004 11

1216 – Recovery Plans

Deliver systems:

With documents designed specifically for disaster recovery

July 14, 2004 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)

July 14, 2004 13

Characteristics of a Secure System

James W. Sample, CISSP, CISMManager of Information SecurityCalifornia ISO

July 14, 2004 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.

July 14, 2004 15

Application Level Security

Identity Management Application Cryptography Session Management Data Input Validation Application Patching Auditing/Logging/Monitoring Secure Programming/Code Integrity

Application should have the following characteristics at a minimum:

July 14, 2004 16

Application Level Security

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

Identity Management

July 14, 2004 17

Application Level Security

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

Application Cryptography(biggest, baddest tool in the application programmer’s arsenal)

July 14, 2004 18

Application Level Security

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

Session ManagementEach method below has certain advantages and disadvantages:

July 14, 2004 19

Application Level Security

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

Data Input Validation

July 14, 2004 20

Application Level Security

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

Application PatchingAbout 95 % of hacker attacks occur against known vulnerabilities in software

July 14, 2004 21

Application Level Security

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

Auditing/Logging/Monitoring

July 14, 2004 22

Application Level Security

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

Secure Programming/Code Integrity

July 14, 2004 23

Operating System Level Security

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

Operating Systems should have the following characteristics at a minimum:

July 14, 2004 24

Network Level Security

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

Network should have the following characteristics at a minimum: