P1711 The state of closure

1
P1711 The state of closure

• PES/PSSC Working Group C6
• Dennis K. Holstein, Vice-chairman

2
Purpose and Objectives

• The existing SCADA systems needs a retro-fit
  solution to mitigate cyber security risks
• Focus attention on asynchronous serial SCADA
  communications
• Standard needs to specify requirements that
  minimize changes to SCADA Master and RTU hardware
  and software
• Standard needs to specify requirements that
  provides graceful deployment migration
• AGA 12-1 provides valuable input to requirements
  needed by P1711 Note P1689 has been withdrawn
• Draft AGA 12-2 provides the cryptographic
  protocol known as SCADAsafe
• Vetted by analysis, lab testing and limited field
  testing
• Shortfalls identified by Sandia National Labs
  addressed
• Some improvements needed (Kinast and Wright)

3
WG C6 Team Organization
4
Situation assessment

• Integrated P1689 requirements into P1711
• Draft 3 dated 2008-08-16
• Issues
• PAR Revision needed
• Title of standard may need to be revised
• Technical issues raised by Kinast and Wright
• Scope issues raised by Sciacca, Wright and others
• Question How best to proceed?

5
PAR revision

• Revisions
• Incorporate P1689 requirements
• Limit scope to asynchronous SCADA serial
  communications
• Remove from scope any reference to the need to
  address communication to the maintenance ports
  (MCM)
• Strengthen focus on retrofit solution
• Best to circulate draft PAR revision with first
  ballot
• Collect comments and recommendations
• Include technical and editorial changes to
  harmonize PAR and standard before submitting to
  RevCom
• Final PAR revision must accompany draft to RevCom

6
Title of standard

• Revise title to reflect agreed-to scope of work
• Best to include revised title with first ballot
• Collect comments and recommendations
• Include technical and editorial changes to
  harmonize title and scope before submitting to
  RevCom
• Final title will accompany draft to RevCom

7
Handling technical issues raised by Kinast and
Wright

• Technical issues need to documented in a standard
  comment form
• If technical issues are not resolved for first
  ballot
• Include reference in draft for first ballot to
  specific comment
• Include comment form with draft for first ballot
• Technical issues in ballots need to be resolved
  before submission to RevCom
• No open issues in draft submitted to RevCom
• Comment form and resolution history submitted to
  RevCom
• Must demonstrate a sincere attempt to resolve all
  issues

8
Handling scope issues raised by Sciacca, Wright
and others

• Scope issues raised have merit that is not the
  concern
• MCM requirements (including RBAC?)
• Embedded SCM requirements
• Comprehensive key management requirements
• Protection of data at rest
• Non-serial based networks
• Two approaches considered
• Revise P1711 to address selected issues
• Recognize in a P1711 informative annex the issues
• Short (1 paragraph) description of issue and
  guidelines for specification
• Form new working groups to develop needed
  standards
• If the cryptographic protocol specified in P1711
  is appropriate, include IEEE 1711 as a normative
  reference in new standards

9
Revise current P1711 scope?
10
Continue with P1711 as is?
11
Informal survey to proceed to first ballot (will
not attend Vancouver meeting)
12
Closure plan to finish P1711 as is

• Minor cleanup of Draft 3
• Form ballot pool PSSC, PSRC, PSCC, etc.
• Ballot cleaned version of Draft 3 with open
  comments noted
• First ballot by end of 2008
• Receive comments and resolve issues via BRC
  formed of WG C6 experts additions required
• Second ballot about First Quarter of 2009
• BRC resolves comments
• Additional ballots as needed until all reasonable
  attempts have been made to resolve negative
  comments
• Finalize draft P1711 and submit to RevCom for
  approval