Join us on Wednesday, July 14 at noon Pacific for the SCADA Security Hack Chat with Éireann Leverett!
As a society, we’ve learned a lot of hard lessons over the last year and a half or so. But one of the strongest lessons we’ve faced is the true fragility of our infrastructure. The crumbling buildings and bridges and their tragic consequences are one thing, but along with attacks on the food and energy supply chains, it’s clear that our systems are at the most vulnerable as their complexity increases.
And boy are we good at making complex systems. In the United States alone, millions of miles of cables and pipelines stitch the country together from one coast to the other, much of it installed in remote and rugged places. Such far-flung systems require monitoring and control, which is the job of supervisory control and data acquisition, or SCADA, systems. These networks have grown along with the infrastructure, often in a somewhat ad hoc manner, and given their nature they can be tempting targets for threat actors.
Finding ways to secure such systems is very much on Éireann Leverett’s mind. As a Senior Risk Researcher at the University of Cambridge, he knows about the threats to our infrastructure and works to find ways to mitigate them. His book Solving Cyber Risk lays out a framework for protecting IT infrastructure in general. For this Hack Chat, Éireann will be addressing the special needs of SCADA systems, and how best to protect these networks. Drop by with your questions about infrastructure automation, mitigating cyber risks, and what it takes to protect the endless web of pipes and wires we all need to survive.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, July 14 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.
Wait until someone takes out the GPS…
You can probably spoof or block those signals easily… not legal to do, of course, but the signals coming from those satellites are pretty weak (~ -125 bDm?). I know of a few cases where blocking was done and the results… See this previous article on Hackaday for some fun details: https://hackaday.com/2020/09/08/teardown-mini-gps-jammer/
Yes, but this is about SCADA, and while GPS represents a good timing source it’s not the only one.
https://www.researchgate.net/publication/235144855_Clock_Comparison_Using_Digital_Television_Signals
”Finding ways to secure such systems is very much on Éireann Leverett’s mind”
Sure, but you will never be cleared to deploy these already known solutions.
1. Most environments use primitive systems for long-term maintenance and interoperability reasons
2. These systems are usually designed by engineers and marketing people, not senior software people with risk mitigation in mind
3. vendor tying/racketeering behavior destroyed any credibility software or IT people had in this field. While you may think a solution using kerberos/DoH/x509 certs is keen, no one on the senior staff with experience will believe your pleas over the 10 people they saw before you
4. cost-optimizing with software/IT staff churn-over/outsourcing/clouds means few understand the entire stack after awhile. Divisions end up with great looking fiscal paperwork, and near useless emergency response capabilities
You will encounter a lot of push-back if one dares try to change anything.
It is kind of a Rite of Passage these days ;-)
https://imgs.xkcd.com/comics/standards.png
It would be nice if people just realize sabotaging inf. just might affect them as well as family, it’s a shame some people just don’t have anything better to do than to screw with stuff. I also go along with the possibility that the people that make up all this high tech stuff are getting paid to figure out ways to screw it up so they have more work to do to fix it. I call it job security.
“SCADA Security Hack Chat” Huh? Drop the SCADA and have a “Security Hack Chat” instead. Like most properly designed job-specific protocols, SCADA is not (nor ever was) intended to be “secure”. Security is something you wrap around a protocol like SCADA. It makes zero sense for every working protocol to have its own security layer, that approach will result in myriads of disparate mediocre approaches to security instead of a smaller set of robust, tested, and inter-operable security standards. SCADA has gotten a bad reputation because of some high visibility attacks that were reported on by the uneducated mainstream media who these days are more interested in sensationalism rather than the truth. If you leave a network exposed and unprotected, it will eventually be successfully attacked, regardless of what the underlying working protocols are.
Plain wrong. Good security must be included in the protocol design, not wrapped over an insecure one. Many issues with https were caused by that wrapping. SCADA systems are even harder to secure, and having to keep legacy systems does not help.
The first S in SCADA is for Supervisory. The second S in SCADA is for Security.
(But there isn’t a second S in SCADA…)
Exactly!
Go look up the DNP3 protocol. It has had secure authentication features since 2009.
That said, it is not something I would expose to the wider world. The authentication does help the cause of security a bit. And by the way, authentication was chosen deliberately over encryption because this is a protocol that is used internationally over borders. We wanted the protocol to be open to inspection by any authority without jeopardizing the keys for an encrypted tunnel. We were also concerned that some governments were acting weird about using encryption, escrowing keys, and so on and we didn’t want to get in to that morass.
I can say that with good authority because I was in the standard committee meeting when these decisions were made.
That said, the problem with any SCADA protocol or IoT security is key distribution. The examples most people cite for key distribution presume that there is a human at both ends. Well, in this case, there really isn’t. We have to account for the key provenance, the logistics of getting the initial key to the site, and understanding the device architecture well enough to ensure that there are no other keys or backdoors that someone might use.
It is not simple. This is why remote cryptography has not taken hold for the industrial control system and SCADA world, nor has it happened for IoT or even for SNMP (how many people really use the authentication features of v2c and how do they manage the keys?)
Finally, you don’t actually have to attack most control systems. You can just flood them with a ridiculous number of broadcasts. Most network gear on a plant is not designed to block that sort of traffic because many ICS protocols are actually require broadcasts or multicast to work. With modern gear, we can do better, but it still requires a degree of knowledge and understanding that will be very scarce –especially if it is 2 AM and a flood has just placed the switch in a remote panel under water.
Yes, there are realities and logistics that most people from the outside world just don’t think about. I could go on. But I’d have to write a book. In fact, I did co-author and co-edit a book on the subject –just so that you know I am not kidding.
And by the way, big kudos to Éireann Leverett. He’s been in this endeavor probably as long as I have.
I wouldn’t need to google wtf “Wednesday, July 14 at 12:00 PM Pacific time” is supposed to be if you’d use UTC notation and I assume most non-DSA-ians would agree.
Maybe in brackets after the middle endianness nightmare mix with pm?
like so: “Wednesday, July 14 at 12:00 PM Pacific time (= 2021-07-14 12:00 UTC-7)” assuming DST and 12PM is actually 12:00 and not 24:00.
Or “2021-07-14T12:00-07:00” which is a notation defined in ISO 8601[1] but less readable (i wouldn’t have understood it immediately).
So if I were living in not so GB it would be 19:00 (12+7)?
[1] https://en.wikipedia.org/wiki/ISO_8601
Speaking of cryptic terms, what is that ‘non-DSA-ian’ you mention above?
non-USA-ian
but the Divided States of north America aren’t as united as they should be… (which is also true for most (western) democracies)
The working protocol designers must be focused on getting the work done in an effective and efficient way – the security layer the working protocol is wrapped in should not be a concern. Each designer must be steeped in their own area of expertise – otherwise, you breed mediocre results and effort duplication. We do NOT want our expert podiatrists performing brain surgery – and vice-versa!
The above post was entered in reply to: @NdK: July 13, 2021 at 1:16 am far above. But in typical WordPress Jetpack fashion, it was instead dropped to the very bottom of the discussion thread. When will Hackaday wake up and realize just how bad WP Jetpack is?
@Drone, WP sucks. The best commenting system i have seen is still Slashcode. And yes, it’s open source and free – Soylent News uses it, for example.
I’m not hating on HaD though – it’s where all the cool hardware projects are now, instead of on the green site like they were 20 years ago.
Designing a protocol should be a team effort. And it’s usually a compromise between availability, simplicity, privacy, integrity, speed, power, and many more. That’s why there are so many, each more suitable for a different scenario.
But technology evolves: what was “secure enough” 20y ago might not be a good choice today. And a system exposed to the Internet does have very different requirements than an isolated one… The attack surface is different and the availability cannot be guaranteed for the former (DDoS just to say one).
Just wrapping an insecure protocol in a secure tunnel often leaks metadata (remember the “attack” that can detect if someone is moving in front of a wifi camera just by analyzing the amount of data sent? no need to crack the wifi crypto).
Will there be a video released of this chat?
It’s a text chat, so no. But you can go back and read it!