The F-35's Greatest Vulnerability Isn't Enemy Weapons. It's Being Hacked. (popularmechanics.com)
schwit1 shares a report: Every F-35 squadron, no matter the country, has a 13-server ALIS package that is connected to the worldwide ALIS network. Individual jets send logistical data back to their nation's Central Point of Entry, which then passes it on to Lockheed's central server hub in Fort Worth, Texas. In fact, ALIS sends back so much data that some countries are worried it could give away too much information about their F-35 operations. Another networking system is the Joint Reprogramming Enterprise, or JRE. The JRE maintains a shared library of potential adversary sensors and weapon systems that is distributed to the worldwide F-35 fleet. For example, the JRE will seek out and share information on enemy radar and electronic warfare signals so that individual air forces will not have to track down the information themselves. This allows countries with the F-35 to tailor the mission around anticipated threats -- and fly one step ahead of them.
Although the networks have serious cybersecurity protections, they will undoubtedly be targets for hackers in times of peace, and war. Hackers might try to bring down the networks entirely, snarling the worldwide logistics system and even endangering the ability of individual aircraft to get much-needed spare parts. Alternately, it might be possible to compromise the integrity of the ALIS data -- by, say, reporting a worldwide shortage of F-35 engines. Hackers could conceivably introduce bad data in the JRE that could compromise the safety of a mission, shortening the range of a weapon system so that a pilot thinks she is safely outside the engagement zone when she is most certainly not. Even the F-35 simulators that train pilots could conceivably leak data to an adversary. Flight simulators are programmed to mirror flying a real aircraft as much as possible, so data retrieved from a simulator will closely follow the data from a real F-35.
Although the networks have serious cybersecurity protections, they will undoubtedly be targets for hackers in times of peace, and war. Hackers might try to bring down the networks entirely, snarling the worldwide logistics system and even endangering the ability of individual aircraft to get much-needed spare parts. Alternately, it might be possible to compromise the integrity of the ALIS data -- by, say, reporting a worldwide shortage of F-35 engines. Hackers could conceivably introduce bad data in the JRE that could compromise the safety of a mission, shortening the range of a weapon system so that a pilot thinks she is safely outside the engagement zone when she is most certainly not. Even the F-35 simulators that train pilots could conceivably leak data to an adversary. Flight simulators are programmed to mirror flying a real aircraft as much as possible, so data retrieved from a simulator will closely follow the data from a real F-35.
Lockheed takes the security of this system, and all of their weapons systems, pretty darn seriously.
Although we should not discount the danger of such hacks, I doubt, it is the greatest vulnerability of the weapon.
TFA goes to great length explaining the potential dangers, but offers no justification for using "the greatest" in the title... Seems like a cheap sensationalism...
In Soviet Washington the swamp drains you.
TFA reads like FUD. If I were trying to sell my services as a cybersecurity contractor, this is the kind of crap I'd write. Essentially, it boils down to "complexity is bad", and "wireless is scary".
I've worked defense contracts. They're always trying to "shore up vulnerabilities", and always making a big deal about every tiny detail that isn't perfectly in compliance with a rule written for an entirely-different scenario. Exceptions are the norm. That doesn't mean the system is actually vulnerable to any attack, or even that a possible attack would be successful.
Now, I'm not suggesting that anyone stop looking at security, especially in such important systems... I'm just saying that shouting about generic insecurity doesn't improve anything, and in fact makes things worse by encouraging a checklist-based approach to compliance.
You do not have a moral or legal right to do absolutely anything you want.
in C/C++?
Neither of those. Care to try again?
COBOL?
It must have been something you assimilated. . . .
I wonder if I can use Shodan to find F-35s?
Considering the size of the program, I'd be more surprised if any language wasn't involved somewhere.
When I worked in defense, the only rules on languages for one component (a sub-contract to a sub-contract) was that it had to be more than 10 years old, with compilers still supported. I suggested INTERCAL. The engineers laughed, and my boss was pissed, but he couldn't object. I suggested Java. He was happier, but the engineers weren't. I think we settled on Perl for that component...
You do not have a moral or legal right to do absolutely anything you want.
I'm guessing Ada - defense contractors love that
It's more or less a PowerPC G4 right down to the Firewire bus.
Components were billed as "COTS". However those chips were still back when they were Motorola/Freescale
The system departed from the historical use of low speed Mil-Std-1553B busses, using the high speed Fibre Channel-Avionics Environment (FC-AE) serial bus for high speed internal interconnects.
built around PowerPC RISC processors - essentially a bigger and faster cousin to the 6U VME packaged PowerPC processors now being used in F-15E, F/A-18E/F and F-111C Block C-4.
"So we have designed for technology refresh, so at the appropriate time we can stop putting in the 1 GHz processor board and swap out to the 2 GHz board without having to go back and do any redesign. We were once required to use a MIL-STD-1760 processor with Ada or other military languages; now we use commercial PowerPC with C++."
http://www.ausairpower.net/APA...
https://www.militaryaerospace....
It's greatest vulnerability? Its own cost.
At $85 million per plane, that probably resulted in several hundred aircraft that were supposed to be purchased, never being bought - far more than will ever be brought down in combat.
The only comparable Fighter is the Advanced Super Hornet F/A-18F and Boeing is pricing it at $80 million. Not exactly tremendous savings
I find it impossible to believe that this is the first time any of these concerns have been brought up. Lockheed has a lot of very savvy and security-conscious engineers. Yes, the networks might be vulnerable to hacks. The question is whether that risk downside is worth the upside of these highly networked machines (say, avoiding friendly fire). I don't know what those tradeoffs are, but this article lacks any analysis of why these security risks were considered acceptable and what is done to mitigate them. Without that balancing content, this is just FUD and useless blather.
The f15 was programmed using Java?????
Not constantly. This is a ground maintenance function. But if it can be monitored, an enemy can gain some valuable information about the status of your forces. And if it can be hacked, that enemy could effectively ground all your planes pending unneeded maintenance*.
*"I've just picked up a fault in the AE-35 unit. It is going to go 100 percent failure within 72 hours."
Have gnu, will travel.
"It Just Works"
Mulitple languages... Ada for sure, and also C++, and probably others.
C++ coding standards for JSF. http://www.stroustrup.com/JSF-AV-rules.pdf
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
The F-35 has nothing to do with "defense".
You are welcome on my lawn.
There's C++ in there, they bill it as such.
We were once required to use a MIL-STD-1760 processor with Ada or other military languages; now we use commercial PowerPC with C++."
source
Here's their toolchain: https://www.ghs.com/AerospaceD...
From RTOS to IDE to Compiler, GHS the only name in this space.
I think were developing stuff that is over teched to a point of being fragile in a way. Especially in military environments you have to wonder how these incredibly technical machines can ever survive a war?
Our military has traditionally accepted "ahead of the curve" jet designs, expecting that manufacturing and technology will eventually catch up. The theory is that you have to stay at least one step ahead of the enemy, otherwise your kill ratio will be close to 1-to-1.
While this philosophy has mostly worked, it has hippucced from time to time. The F-35 may be one of these hiccups.
For example, our planes had difficulty during the early phases of the Vietnam war because it was felt that air-to-air missiles would render dogfights obsolete, and our planes were designed with this assumption in mind. However, the missiles proved buggy, and the Soviet planes used their maneuverability against our planes and the missiles.
A combination of better missiles and improved training in "team based" tactics eventually overcame most of these problems, but we took a beating for a good while.
It could be argued the philosophy pays off more than it doesn't such that we should stick with it. However, we will get occasional expensive duds and/or whippings along the way.
Table-ized A.I.
I'm guessing Ada - defense contractors love that
People who want to fly and stay alive love Ada.
I am sure that there are many other solipsists out there.
I figure management sets the overall tone and priorities, the culture. Management values security.
Their people have the ability and interest to deliver security.
So there is a pretty good chance that they do a good job. Lockheed isn't a customer of ours, so I haven't done a security audit of them. I do have enough information to make an educated prediction or hypothesis.
Of course that's relative to other companies. We do have banks as customers, so I know how bad / good some banks are regarding security. Overall, the software industry sucks at security and reliability. We need about four times as many *engineers* in the roles that have job titles like "senior software engineer". Engineering means designing things to meet known requirements based on proven design methods. Software is often built with little or no engineering involved.