Ransomware attack on California mass transit is a sign of the times
Share on Facebook
Share on Twitter
Share on Google+
Share on Reddit
Share on Email

Photo Credit: Wikipedia (lensovet) / CC BY 3.0

Photo Credit: Wikipedia (lensovet) / CC BY 3.0

There are 3 areas where railroads need to focus their cyber security resources

The San Francisco Municipal Transportation Agency (SFMTA) reports that it lost $50,000 in revenue as a consequence of a ransomware attack on its systems over the Thanksgiving weekend. For an agency the size of the SFMTA, this is basically pennies, but it proved embarrassing and again reiterates the vulnerability of these systems, which make attractive targets because hackers think they will pay out quick to restore service.

Such an attack, a type that is gaining popularity against institutions and businesses, is a problem in and of itself, though not an insurmountable one. What’s less understood, but potentially more serious, is how vulnerable transportation infrastructure is to cyber attacks as more and more parts of these systems are automated and interconnected, including technology meant to keep commuters safe.

A 2015 report from the research group SCADA StrangeLove found that, “railway systems are not difficult to hack, but the task does require specific knowledge in railway automation and a testbed.” Railways also generally aren’t as far along as the airline industry in ICT implementation across their systems, so the prevalence of older systems poses problems until upgrades are made.

There are three distinct threat models to be understood for railroads, according to SCADA StrangeLove. First, the financial, in that a database could be hacked to cause financial losses, like with the SFMTA. Secondly, on communications, which would lead to a slowdown of service and cause massive delays. And lastly, physical, in that signals and controls could be compromised to cause a derailment or other accident.

There is potential for all of these scenarios, and a few of them have occurred. So far, the damage has been limited, though it is not clear if that is because security has gotten better, or there just isn’t that much interest among hackers to test the boundaries.

Financial losses and inconvenienced passengers will increase

The hack probably occurred when an employee or employees of the SFMTA opened an email carrying the HDDCryptor master boot record-killing malware, which then targeted the transit authority’s internal databases. That $50,000 loss was the result of the SFMTA’s emergency response. It shut off metro card readers at stations to ensure people could still access public transportation without having to swipe into a potentially compromised system. Passenger and employee information was, in the final assessment, not stolen or deleted, as had been the case with the San Francisco Bay Area Rapid Transit (BART) in 2011 when an Anonymous collective stole 2,000 people’s data.

(Ironically, the account the attack is thought to have come from was itself hacked shortly after the SFMTA was targeted.)

The threat to release such information appears, then, to have been a bluff. But the threat from the ransomware was and is real. HDDCryptor is bad news for any system that gets infected, and there’s serious demand in the cyber security industry now to find ways to mitigate the damage that these attacks can do. Not only is there the matter of the ransom itself – some entities will pay if the amount is something they can afford – there is the expense of improving data security to prevent recurrences. And yes, there is Ransomware as a Service (RaaS) now since the malware can be easily built and sold on the cheap.

Looking beyond these disruptions to fare collection, though, some experts believe that worse things could happen. It would be difficult to execute such an operation on a large scale, but localized mayhem is a real possibility.

And it’s already happened at least once, in Poland, eight years ago.

Actual accidents happen, but so far are few and far between

The thought of trains being taken control of remotely and steered to disaster, like some deranged real-life reboot of the Speed franchise, isn’t a pleasant one. But in 2008, a hacker was able to do just that with a Polish light rail network, breaching the vehicles’ control protocols to, yes, steer the trams like he was playing with toys.

The scary thing about Polish hack was how relatively low-tech it was. It wasn’t executed by breaching a secure system – there wasn’t one present – but by learning the coding and patterns of the IR signals needed to override the tram drivers’ controls and subsite the hacker’s commands for theirs. At that point, right became left and mayhem ensured. Such a feat could be easily repeated on systems that lack encryption, though encryption is becoming more commonplace for railway systems, especially those implementing positive train control (PTC) to improve safety on the line.

Cyber security is a vital part of that work. In the US, the federal government now sets common standards for cyber security, and the Association of American Railroads does have a Railway Information Security Committee.

And it isn’t just the trains themselves that have to worry about this disruption. Signaling and sensing systems along the line, even the lights and barriers at grade crossings, are targets too. All needed to be protected to ensure there’s no toehold for hackers.

There is concern over how unified these efforts can be when commuter and freight carriers have different standards and are in competition with one another. For all the talk about needing to fix problems before they arise, there is still disinclination to cooperation or share methods. At least the SFMTA hack, and disruptions of other key infrastructure systems, are raising awareness of these issues.

Share on:Share
Share on Facebook
Share on Twitter
Share on Google+
Share on Reddit
Share on Email

More Goodies From Security


4 Network Security Tips Progressive Small Businesses are Implementing

For Retail Startups, Security is Paramount

Russia in talks with US to create cybersecurity working group