Yes. The security profile for IEC 60870-6 TASE.2 (a.k.a. ICCP) are published in IEC 62351-4. The DNP security profile is published under IEC 62351-5 albeit they are for IEC 60870-5 in this spec. But it is my understanding that it is essentially the same as the DNP3 specs. IEC 62351-6 includes the profile for IEC 61850, which I admit is not widely implemented yet. The ICCP specs have been implemented in products since the mid 2000s I think it was.
I should add that none of these profiles are really widely deployed as many users are still hesitant to disrupt data flow for any reason including having certificates expire or fail to validate. Access to the systems is more important than secured access to the systems in many cases.
These security profiles do not address the fundamental coding vulnerabilities that fuzzing detects. All they do is prevent access to the vulnerability by only allowing trusted parties to get access to the protocol. If your trusted communicating partner runs a fuzzer at you it won't prevent exploitation unless proper coding methods have been used.
And, these authentication mechanisms really need to get connected into the internal processing of the device through role based access control to provide authentication on specific control actions versus more benign actions like reading values. That is addressed in IEC 62351-7.
My point was intended to say that the ability to evaluate code as to it's ability to avoid penetration by determined hackers is far beyond the ability to create even excellent code that works perfectly. A lot like the difference between being able to raise the dead versus the ability to apply makeup perfectly. Possibly that adequately describes the differences in skill levels, as I see it. It certainly would explain the steady stream of updayes that I see for security issues.
Defficiencies become much more obvious after somebody breaks through because of them.
N. L. It would seem that the ability to accurately evaluate software as hacker proof or even just hacker resistant would be an incredibly valuable skill. I doubt that there will be many of those masters around.
Thanks so much for the comment, Jacob. It's great to receive further background and claification on a story like this. As the chair of the DNP User's group, I'd love to quizz you about the state of security in SCADA systems. Send me your contact info, and let's have a conversation we can share with Design News readers.
As Chairman of the DNP Users Group, I have a strong interest to encourage our membership to secure their SCADA systems.
1. Vendors should react reasonably to these discoveries
2. End Users should take thes issues seriously and patch
3. Consultants and Integrators should test the products they recommend/install
I also need to point out that the DNP3 protocol is sound. Though the Aegis Fuzzer found many problems in many vendor's products, there were a few vendors who were not affected by these discoveries. They had made the effort to carefully validate the DNP3 messages, and they sailed through the tests without problems.
Crain and Sistrunk worked with the Users Group to study the failure modes and to help us make recommendations to vendors on writing more robust software. These recommendations are available on the DNP Users Group web site.
DNP3 is the only open SCADA protocol available today with secure authentication features. As such we have a strong interest in staying ahead of these security issues. We are encouraging our members to stay abreast of these issues and to help each other build better, more secure SCADA systems.
Rob, one of the items highlighted in your article is the problems with the code itself. With industrial control and SCADA systems increasingly on standard networks, they are exposed to more and more frequent attacks. This year, the IEEE and state licensing boards are instituting a Professional Engineer certification for Software Engineers. The main target of such a certification is avionics, medical and control software, especially embedded. The PE, as in other fields, will certify a product in terms of the relevant standards. These should include safety and security standards.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.