1 / 14

SunSpec Security Recommendations (DRAFT)

SunSpec Security Recommendations (DRAFT). John Nunneley. SunSpec Security Workgroup Contibutors. Aaron Parker, Veris Bill Randle, Advanced Energy Bob Fox, Ferdy Nagy,ß Loggerware John Blair, Power-One (Chair) Lynn Linse , Digi International Martin Beran , Fronius

bertha
Download Presentation

SunSpec Security Recommendations (DRAFT)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SunSpec Security Recommendations(DRAFT) John Nunneley

  2. SunSpec Security Workgroup Contibutors • Aaron Parker, Veris • Bill Randle, Advanced Energy • Bob Fox, FerdyNagy,ßLoggerware • John Blair, Power-One (Chair) • Lynn Linse, Digi International • Martin Beran, Fronius • Nick Jancewicz, Continental Control Systems • Ralf Kaisler, SMA • Richard Duong, Moxa • Stephen Lapointe, PowerDash • Tom Johnson, Solectria

  3. Security Needs • Increasing number and size of PV Plants • Revenue tied to Meters significant • Introduction of Inverter Control raises threat • Requirement to participate as first class grid asset • Generation • Storage • Ancillary Services

  4. Security Requirements • Availability and Safety • Cyber-Physical Systems • Keep the power on, communications up • But don’t kill anybody! • Privacy and Confidentiality of Data • Authentication and Authorization • End-End .vs. In Transit • Data Integrity & Reasonableness • Inability to modify data in transit • Authenticated source of data/control • Alarming data/control • Non-repudiation of Data • Inability to deny an action took place or origin of data

  5. SunSpec Architecture End-to-End Security SunSpec Devices SunSpec Applications Telemetry Bulk Data Exchange Meter Local SCADA Inverter Firewall / VPN Periodic Report String Cloud Internet Grid Operations Module SunSpec Gateway SunSpec Data Store Storage SCADA Environ Regulator SunSpec Field Bus Custom Transport Security Control

  6. SunSpec Field Bus Security Issues • Modbus itself has no security • Relies on physical security of connection • May be layered over TCP with SSL • point-point encryption supports privacy and integrity while in transport • Not typically supported due to limited system resources • But SSL is transport only, Not end-to-end • TCP not practical over RS-485 • No non-repudiation support • Multiple Masters / Man-in-the-Middle • Wireless (Zigbee/WIFI) provides access control and privacy • Opens up proximity attack

  7. Attacks • RTU Man-In-The-Middle • Insecure facility (e.g. residence) • Modify data in transit • TCP Multiple Masters • Tap into switch • Issue erroneous commands • Replay Attack • Supply Chain attack • Consequences of a successful attack

  8. Modbus RTU Daisy Chain Modbus RTU Daisy Chain Meter Inverter Weather Man-in-Middle Attacker SunSpec Gateway Slave Slave Slave Master|Slave Master Internet

  9. End to End Security Meter Local Logger Host Application Digital Signature RTU TCP HTTP POST SSL Transport Security Digital Signature

  10. Security Approach #1 • Examine needs for secure metering using Modbus • Add-on security block(s) to support needed services • Easy to adopt / ignore • Modbus max read limit 125 • Sequence # / Timestamp • Constrained meter model • Digital Signature Security Header Common Model Meter Model Vendor Model Security Trailer End Device Model

  11. Security Approach #2 • Extend Modbus protocol • Private vendor functions • Secure read/write, key management • Symmetric Key(AES) .vs. Public (RSA) • Encryption • Digital Signature • Key management and length • Adoption difficulty / compatibility

  12. Security Approach #3 • Use a trusted (secondary) Gateway to securely report data • Rely on physical security of the connection to the Meter • Use ethernet when possible to eliminate man-in-the-middle, and support multiple masters • Gateway will add the digital signature • Use Logger Upload protocol over HTTPS • Transmit signature as HTTP header

  13. Security Approach # 4 • Do not use Modbus to securely report Meter data • Use SunSpec Upload Protocol • Meter support for HTTPS/TCP/IP • Trend for next generation devices • Include digital signature on XML payload • Transmit signature as HTTP header

  14. Issues List • Number and types of keys • Key Management • Factory installed key • Protection of keys • Challenge – Response (Nonce) • Timestamp (RT Clock?) • Sequence Id • Do we need to be able to handle signing more than 125 registers of data? • We will also need a: • Method to access the public key • Method to set access control • Way to encode the digital signature in the upload • Way to encode the digital signature in the control • Way to allow for bigger keys, newer algorithms, as they become needed

More Related