At this year's SANS SCADA Summit I was posed the question of how we fix the points of attack my talks identified in the AMI system.
Because answering the question in 10-20 seconds is exceptionally difficult I wanted to respond in writing.  If you came to my breakout session soon after the keynote you will have already heard much of this.

First off, there is no way to "fix" the ability to interact with systems which are physically available in the field.

How to "fix it" begins with the following (broken into responsible parties):
Vendors and Utilities:
* Understanding Appropriate Trust (see below)
* Limit attack surface
* Security Training for developers and implementers
* Internal "attack" penetration testing
* Third Party "attack" penetration testing
* Sanity-checks/Thresholding/Rate-limiting of Control Commands (see below)
* Layered Defenses to slow an attacker getting to the "gold"
* Visibility and Alerting to effectively identify attacks
* Forensic tracking information

Vendors:
* Secure Development Practices and Standards
* Peer Code Validation (security minded)
* Periodic Design and Code Review
* Openness in protocol specifications (see below)
* Transparency of handling vulnerabilities and patches

Utilities:
* Prepared Incident Response procedures and policies

Three items of key interest:
    Appropriate Trust pertains to understanding the likelihood of compromise and layering defenses accordingly.  For instance, because of the physical accessability of power meters, they have inherent risk of compromise.  Therefore, in the overall system, they must be segregated and only trusted as much as they must be.  Should we trust meters for meter-reading information?  Well, we have to... and the impact of the data being wrong is a matter of money.  Should we trust meters unfettered access to the utility network and the Internet?  Unfortunately the impact of compromised meters becomes much greater as we allow them to interact with systems which directly control the power grid.  The rule of thumb for validating protections is to pick a system or group of systems and assume compromise

    Openness in protocol specifications does not necessarily refer to "Open Standards" per se.  Vendors can continue to use proprietary protocols if they see business value in doing so.  Rather, official protocol specifications need to be available for utilities and third-parties who can then create better intrusion-detection products as well as other protection products... Because meters and collectors inherently provide a platform to attack the head-end, proxy systems which validate protocols may then be developed and placed between these differing security domains.  leading us to the third point.

    Sanity-checks and limiting control commands means that each component of the AMI system should include sanity checks and restrictions to ensure that, for example, 400,000 meters are not disconnected within the same hour.  Thresholding sends alerts and possibly stops such actions from being carried out without authorized approval.  Rate-limiting allows for protection within a general state of operation.  Because rapid firmware-updates may be necessary at times, such rate-limits should include the ability to create a timed-exception, which automatically reverts to standard rate-limiting within X minutes or hours.  These exceptions represent a risk, allowing the patient attacker, willing to wait for or *force* a utility into such an exception before launching his attack... however, managing opposing risk is what defense-in-depth is all about.


Any questions, comments, or business inquiries can be directed to me at
matt@inguardians.com

Thank you,
Matthew Carpenter