Evolving Standards in Security. Michael Garrison Stuber

Transcription

1 Evolving Standards in Security Michael Garrison Stuber

2 Sad but true... Cartoon courtesy of xkcd.com

3 Trends & Responses Evolution from unsecure to secure Acceptance of ECC Struggling with certificates Demand for external validation Demand for SDL & secure boot

4 Evolution to Secure Historically AMR systems were unsecured Early AMI solutions offered security, but often it was proprietary

5 Evolution to Secure Modern Field Area Network systems provide standardized use of cryptography g, P AES-CCM DLMS/COSEM AES-GCM TLS for WAN tunneling

6 Evolution to Secure Home Area Network protocols are moving the same way Smart Energy Profile 2 (MAC/PHY Agnostic) Network encryption is assumed Application encryption with TLS

7 Evolution to Secure Key management is still a challenge Most standards make key management a put it together yourself exercise Often key management is pushed to the layer above, assuming that the application will take care of it.

8 Acceptance of ECC At 128 bit equivalent strength, Elliptic Curve Cryptography (ECC) is 12x smaller than RSA cryptography Some utilities and vendors were concerned about patents or

9 Acceptance of ECC ECC helps solve the key management issue ECC support is being added to: COSEM (IEC 62056) IEC IEC General trend is to use ECC prime curves

10 Acceptance of ECC Fundamental ECC RFC 6090 ECC defined for TLS RFC 4492 ECC Cipher Suites for TLS RFC 5289 ECC TLS Suites for SHA256 and GMAC TLS-AES-CCM-ECC Draft General support for ECC based x.509 certificates

11 Struggling with Certificates Add cost and complexity Devices may not be internet connected How deep should the certificate chain be? What about certificate revocation? Adds overhead

12 Demand for External Validation Utilities need confidence in the security solution provided This can be obtained several ways Government mandated solution Government vetted primitives & 3rd party evaluation Blind faith Security is a system concern

13 Demand for External Validation How can utilities compare offerings from different vendors?

14 Demand for External Validation IEC is trying to address this issue Originally based on a WIB ( International Instrument Users Association document Began as an effort by a security certification vendor to standardize their work Now has a strong cross section of countries and companies involved

15 Demand for External Validation IEC is crafting a functional specification first IEC is embracing the larger IEC work A conformance assessment may come later Goal is to be clear and testable

16 Demand for External Validation BSI push for Common Criteria / EAL 4+ certified meters Smart Meter Gateway Protection Profile TR 03109

17 Security Development Lifecycle Utilities are asking to see evidence of design processes and artifacts addressing security SDL is currently a voluntary activity Microsoft makes materials available for free ( There are certifications for practioners (CSSLP), and efforts to certify ISMS/IT (IEC 27001), but there is no SDL development process certification yet

18 Secure Boot Utilities are also raising concerns about fraudulent firmware running on Smart Grid devices NEMA AMI-SG-1 provides guidance on smart meter upgradability Forthcoming NISTIR 7823 provides a framework for testing against this standard Most secure boot implementations are either vendor or chip supplier specific

19 Secure Boot NEMA AMI-SG-1 addresses key security concerns: Smart Meter shall validate that the Firmware Image comes from a trusted source. Cryptographic algorithms shall be current, publically vetted, and government approved. AMI system design shall ensure that compromise of a single Smart Meter does not lead to compromise of the AMI system at large.

20 Why is this all important? It s not a merely a question of who accrues the benefits Who accrues the risks? Security is both an operational concern and a public relations concern.

21 Take Aways Consider the use of certificates, but be sure they serve you, and that you don t serve them Favor open, industry standards. IEEE, IEC, and IETF standards allow global sourcing Local specifications may favor local providers, but they don t expand local industry Security must be appropriate to the need