1. UCAIug: Smart Grid Security OpenSG Face-to-Face (January 2010 – San Francisco, CA)  SG Security Working Group  AMI-SEC Task Force SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

2. SG Security Overview ChairChair –Darren Highfill, SCE Vice ChairVice Chair –Matt Carpenter, Inguardians SecretarySecretary –Bobby Brown, EnerNex Task Forces:Task Forces: –AMI-SEC

3. Agenda DayTimeslotSubjectGroupRoom Monday1500-1700Boot CampSG Sec WGANZA I Tuesday1030-1200 Status updates Review of AMI Security Profile v1.0 comments SG Sec WG AMI-SEC TF ANZA I 1300-1500OpenHANJoint SessionANZA I Wednesday0800-1000 AMI SP: comment classification AMI SP: begin resolution discussion AMI-SEC TFANZA I 1030-1200 AMI SP: comment resolution discussion (cont.) AMI SP: action items forward AMI-SEC TFANZA I 1300-1500OpenADE/OpenADRJoint SessionANZA II & III 1530-1730SG CommunicationsJoint SessionANZA I Thursday1030-1200AMI-ENTJoint SessionANZA I 1300-1500Prioritization of needs Organizational planning SG Sec WGPORTOLA A

5. Status Updates CharterCharter –Review –Call for Vote Security Profile BlueprintSecurity Profile Blueprint AMI Security Profile v2.0AMI Security Profile v2.0 –Overview of Comments –Scheduling –Comment Classification –Negotiation / Discussion –Action Items Third Party Data Access (3PDA)Third Party Data Access (3PDA) –Overview –Q&A –Action Items ASAP-SGASAP-SG –Review of org / participation –Upcoming profiles New Work Areas (?)New Work Areas (?) Joint SessionsJoint Sessions –OpenHAN –OpenADE –OpenADR –AMI-ENT –SG Systems –SG Communications

6. UtiliSec Charter Chartered with developing detailed security and assurance requirements and security best practices guidance for organizations throughout the lifecycle of smart grid technologyChartered with developing detailed security and assurance requirements and security best practices guidance for organizations throughout the lifecycle of smart grid technology Technology-specific, but vendor-agnostic guidanceTechnology-specific, but vendor-agnostic guidance Feed and accelerate SDO work (IEC, IEEE, etc.)Feed and accelerate SDO work (IEC, IEEE, etc.) http://osgug.ucaiug.org/utilisec/Shared Documents/SG Security WG Charter v0.9-20100126.pdfhttp://osgug.ucaiug.org/utilisec/Shared Documents/SG Security WG Charter v0.9-20100126.pdfhttp://osgug.ucaiug.org/utilisec/Shared Documents/SG Security WG Charter v0.9-20100126.pdfhttp://osgug.ucaiug.org/utilisec/Shared Documents/SG Security WG Charter v0.9-20100126.pdf

7. Security Profile Blueprint StatusStatus –Mature draft posted Dec. 2009 http://osgug.ucaiug.org/utilisec/Shared Documents/Security Profile Blueprint/Security Profile Blueprint - v0_20 - 20091214.dochttp://osgug.ucaiug.org/utilisec/Shared Documents/Security Profile Blueprint/Security Profile Blueprint - v0_20 - 20091214.dochttp://osgug.ucaiug.org/utilisec/Shared Documents/Security Profile Blueprint/Security Profile Blueprint - v0_20 - 20091214.dochttp://osgug.ucaiug.org/utilisec/Shared Documents/Security Profile Blueprint/Security Profile Blueprint - v0_20 - 20091214.doc –Revisited after completion of each profile Profile Creation MethodProfile Creation Method –Establish Profile Scope –Define Logical Architecture –Identify Security-Related Constraints –Recommend Security Controls –Validate Profile

8. AMI Security Profile Comments Discussion Points: 1.The use of "must", "shall", and "should" and corresponding definitions, then a group to review the consistency in the document. 2.No collaborative computing capabilities should be use in an AMI as it is a dedicated system for one function. 3.AMI is a dedicated system and should not support VoIP capabilities. 4.Should we add a glossary and acronym section - for example "reasonable", "strongly", "alert", "flaw". 5.Should "Smart Grid Application" be part of the Smart Grid components? 6.Should the security profile document be formatted to be used in RFPs?

10. Project Description:Project Description: –Utility-driven, public-private collaborative project to develop system-level security requirements for smart grid technology Needs Addressed:Needs Addressed: –Utilities: specification in RFP –Vendors: reference in build process –Government: assurance of infrastructure security –Commissions: protection of public interests Approach:Approach: –Architectural team  produce material –Usability Analysis team  assess effectiveness –NIST, UtiliSec  review, approve Deliverables:Deliverables: –Strategy & Guiding Principles white paper –Security Profile Blueprint –3 Security Profiles: AMI, ADE, Communications –Usability Analysis ASAP-SG: Summary Schedule: Jun09 – Dec09 Budget: $3M ( $1.5M Utilities + $1.5M DOE) Performers: Utilities, EnerNex, Inguardians, SEI, ORNL Partners: DOE Release Path: NIST, UCAIug Contacts: Bobby Brown bobby@enernex.combobby@enernex.com Darren Highfill darren@utilisec.orgdarren@utilisec.org Schedule: Jun09 – Dec09 Budget: $3M ( $1.5M Utilities + $1.5M DOE) Performers: Utilities, EnerNex, Inguardians, SEI, ORNL Partners: DOE Release Path: NIST, UCAIug Contacts: Bobby Brown bobby@enernex.combobby@enernex.com Darren Highfill darren@utilisec.orgdarren@utilisec.org

11. Public-private collaborative projectPublic-private collaborative project –DOE, NIST, & utilities Purposes:Purposes: –Support the activities of the NIST CSCTG –Accelerate the work of the UtiliSec WG Participants:Participants: –Utilities, regulators, vendors, consultants, national laboratories, & academia ASAP-SG

12. Technical Coordination with NIST

13. ASAP-SG: Upcoming Profiles Distribution AutomationDistribution Automation Wide Area Situational Awareness (i.e. Synchrophasors)Wide Area Situational Awareness (i.e. Synchrophasors) Home Area NetworksHome Area Networks Substation AutomationSubstation Automation

14. Joint Session SG Security & SG Systems SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

15. Template Summary of SG Systems group security requirementsSummary of SG Systems group security requirements Relevant Technological IssuesRelevant Technological Issues Artifacts related to above issuesArtifacts related to above issues –SG Security artifacts: existing and/or needed –Business artifacts from requesting group (e.g. use cases) Q&AQ&A Collaboration between SG Security and SG Systems groupCollaboration between SG Security and SG Systems group –Statement of Need –Task assignments

16. SG-Systems Summary of SG-Systems security requirements (Greg Robinson)Summary of SG-Systems security requirements (Greg Robinson) Outstanding Issues (Greg Robinson)Outstanding Issues (Greg Robinson) SG Security artifacts related to above issuesSG Security artifacts related to above issues –Existing –Needed Q&AQ&A Collaboration between SG Security and SG-SystemsCollaboration between SG Security and SG-Systems –SG-Systems Statement of Need –Task assignments

17. OpenHAN Summary of OpenHAN security requirements (Mary Zientara)Summary of OpenHAN security requirements (Mary Zientara) Issues (Robby Simpson)Issues (Robby Simpson) –Privacy –Securing one way communications –HAN network admissions –Application level security –Digital Certificate authority (technology, business, security credentials) SG Security artifacts related to above issuesSG Security artifacts related to above issues –Existing –Needed Q&AQ&A Collaboration between SG Security and OpenHANCollaboration between SG Security and OpenHAN –OpenHAN Statement of Need –Task assignments

18. Joint Session SG Security / OpenADE / OpenADR SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

19. OpenADE Summary of OpenADE security requirements (Steve Van Ausdall / Dave Mollerstuen)Summary of OpenADE security requirements (Steve Van Ausdall / Dave Mollerstuen) Third Party Data Access Security Profile (Darren Highfill)Third Party Data Access Security Profile (Darren Highfill) Outstanding Issues (Steve Van Ausdall / Dave Mollerstuen)Outstanding Issues (Steve Van Ausdall / Dave Mollerstuen) SG Security artifacts related to above issuesSG Security artifacts related to above issues –Existing –Needed Q&AQ&A Collaboration between SG Security and OpenADECollaboration between SG Security and OpenADE –OpenADE Statement of Need –Task assignments

20. OpenADR Summary of OpenADR security requirements (Albert Chiu)Summary of OpenADR security requirements (Albert Chiu) Third Party Data Access Security Profile (Darren Highfill)Third Party Data Access Security Profile (Darren Highfill) Outstanding Issues (Albert Chiu)Outstanding Issues (Albert Chiu) –Use of public networks such as the internet –NERC CIP –Voluntary DR programs with pricing, weather, special days, etc. over different communications channels –Security lessons learned in current OpenADR deployments SG Security artifacts related to above issuesSG Security artifacts related to above issues –Existing –Needed Q&AQ&A Collaboration between SG Security and OpenADRCollaboration between SG Security and OpenADR –OpenADR Statement of Need –Task assignments

21. Joint Session SG Security / SG Communications SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

22. SG Communications Summary of SG Communications group security requirementsSummary of SG Communications group security requirements Relevant Technological IssuesRelevant Technological Issues Artifacts related to above issuesArtifacts related to above issues –SG Security artifacts: existing and/or needed –Business artifacts from requesting group (e.g. use cases) Q&AQ&A Collaboration between SG Security and SG Communications groupCollaboration between SG Security and SG Communications group –Statement of Need –Task assignments

23. Joint Session SG Security / AMI-ENT SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

24. AMI-ENT Summary of AMI-ENT security requirements (Mark Ortiz)Summary of AMI-ENT security requirements (Mark Ortiz) Outstanding Issues (Mark Ortiz)Outstanding Issues (Mark Ortiz) –Application level security –XML security considerations & messaging SG Security artifacts related to above issuesSG Security artifacts related to above issues –Existing –Needed Q&AQ&A Collaboration between SG Security and AMI-ENTCollaboration between SG Security and AMI-ENT –AMI-ENT Statement of Need –Task assignments Interested? Send an email to brian@enernex.comInterested? Send an email to brian@enernex.combrian@enernex.com

25. Wrap-up Session AMI Security Profile commentsAMI Security Profile comments Interest Areas / Lists to be FormedInterest Areas / Lists to be Formed Prioritization / Action Items / AssignmentsPrioritization / Action Items / Assignments Call for Presenters / TopicsCall for Presenters / Topics

26. AMI Security Profile The intent of the document is to provide prescriptive, actionable guidance for how to build-in, procure and implement security for AMI smart grid functionalityThe intent of the document is to provide prescriptive, actionable guidance for how to build-in, procure and implement security for AMI smart grid functionality This guidance is neutral to vendor specific implementations and architecturesThis guidance is neutral to vendor specific implementations and architectures Work extends from the meter data management system (MDMS) up to and including the home area network (HAN) interface of the smart meterWork extends from the meter data management system (MDMS) up to and including the home area network (HAN) interface of the smart meter

27. What Should Be Logged? Is there a definition for Security Events, Control Events, System/Device Confirmation changes? (DHS 2.16.2.1)Is there a definition for Security Events, Control Events, System/Device Confirmation changes? (DHS 2.16.2.1) Log all success / all unsuccessful? (DHS 2.14.4.2, DHS 2.15.24.3)Log all success / all unsuccessful? (DHS 2.14.4.2, DHS 2.15.24.3) Message details – (date, time, source, destination, message details)Message details – (date, time, source, destination, message details) Do we need a definition for security events, control events, system/device confirmation changes? (DHS 2.14.4.2, DHS 2.16.2.1)Do we need a definition for security events, control events, system/device confirmation changes? (DHS 2.14.4.2, DHS 2.16.2.1) Do we need to define levels of auditing? (DHS 2.16.4.1)Do we need to define levels of auditing? (DHS 2.16.4.1)

28. AMI SP Comments - Summary Use IEEE definitions for shall, should, etc.Use IEEE definitions for shall, should, etc. Encryption – for supplemental guidance, level of protection needs to be applied to the dataEncryption – for supplemental guidance, level of protection needs to be applied to the data Malicious code protection – use due diligence / care, remove the implementation guidance, general updatesMalicious code protection – use due diligence / care, remove the implementation guidance, general updates Update document for “reasonable period of time”, “strongly authenticated”, “alert”, “alarm”, “flaw”Update document for “reasonable period of time”, “strongly authenticated”, “alert”, “alarm”, “flaw”

29. AMI SP Comments – Summary (cont) Review definition of Grid Control Center (4.3.9)Review definition of Grid Control Center (4.3.9) DHS 2.8.13 – Collaborative Computing requirements and verbiageDHS 2.8.13 – Collaborative Computing requirements and verbiage DHS 2.8.17 – VoIP requirement enhancementsDHS 2.8.17 – VoIP requirement enhancements DHS-2.14.2 – Flaw remediation – better definitionDHS-2.14.2 – Flaw remediation – better definition DHS 2.15.2.1 – Identification and authentication – more clarificationsDHS 2.15.2.1 – Identification and authentication – more clarifications Comment resolution team to send an email to the group about why the document is not suitable for an RFP document.Comment resolution team to send an email to the group about why the document is not suitable for an RFP document.

30. AMI SP Comments Thank you everyone for the comments and contributions, they are greatly appreciated

31. OpenSG Group Mappings – Comm View

32. Closing Plenary SG Security SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

33. Progress This Week Key accomplishmentsKey accomplishments –Approved Charter –Strong technical debate/review of AMI SP comments –Introduction of 3PDA SP Collaborative sessionsCollaborative sessions –OpenHAN, OpenADR: Generate Statement of Need –SG Network, AMI-ENT: Action items defined –OpenADE: Delivered 3PDA SP

34. Interest Areas / New Email Lists Third Party Data AccessThird Party Data Access –Usability Analysis –General Interest (Future Task Force?) OpenHAN SupportOpenHAN Support SG Communications SupportSG Communications Support AMI-ENT SupportAMI-ENT Support Lemnos (Configuration Profiles)Lemnos (Configuration Profiles) Risk AssessmentRisk Assessment Application Security RequirementsApplication Security Requirements

35. Moving Forward Define agendas and action plans for next collaborative sessionsDefine agendas and action plans for next collaborative sessions Facilitate sub-group formation & activityFacilitate sub-group formation & activity Changes to AMI Security ProfileChanges to AMI Security Profile –Resolution of comments –Mapping use cases and/or security domains to control requirements Review / comment / revision of 3PDA SPReview / comment / revision of 3PDA SP

36. SG Communications Email reflector:Email reflector: –UtiliSec-Announce@SmartGridListServ.org UtiliSec-Announce@SmartGridListServ.org –UtiliSec-Technical@SmartGridListServ.org UtiliSec-Technical@SmartGridListServ.org –AMI-SEC@listserv.enernex.com AMI-SEC@listserv.enernex.com Webinar information:Webinar information: –Provided via UtiliSec-Announce list Webinar times:Webinar times: MeetingDayPSTESTUKCET SG-SecurityEvery other Monday11:0014:0019:0020:00

37. Questions? darren@utilisec.org UtiliSec Collaboration Site http://osgug.ucaiug.org/utilisec