Pentagon's New Next-Gen Weapons Systems Are Laughably Easy To Hack (zdnet.com)

An anonymous reader quotes a report from ZDNet: New computerized weapons systems currently under development by the U.S. Department of Defense (DOD) can be easily hacked, according to a new report published today. The report was put together by the U.S. Government Accountability Office (GAO), an agency that provides auditing, evaluation, and investigative services for Congress. The report detailed some of the most eye-catching hacks GAO testers performed during their analysis: "In one case, it took a two-person test team just one hour to gain initial access to a weapon system and one day to gain full control of the system they were testing. Some programs fared better than others. For example, one assessment found that the weapon system satisfactorily prevented unauthorized access by remote users, but not insiders and near-siders. Once they gained initial access, test teams were often able to move throughout a system, escalating their privileges until they had taken full or partial control of a system. In one case, the test team took control of the operators' terminals. They could see, in real-time, what the operators were seeing on their screens and could manipulate the system. They were able to disrupt the system and observe how the operators responded. Another test team reported that they caused a pop-up message to appear on users' terminals instructing them to insert two quarters to continue operating. Multiple test teams reported that they were able to copy, change, or delete system data including one team that downloaded 100 gigabytes, approximately 142 compact discs, of data."

The report claims the DOD documented many of these "mission-critical cyber vulnerabilities," but Pentagon officials who met with GAO testers claimed their systems were secure, and "discounted some test results as unrealistic." GAO said all tests were performed on computerized weapons systems that are still under development. GAO officials highlighted that hackers can't yet take control over current weapons systems and turn them against the U.S. But if these new weapons systems go live, the threat is more than real, GAO said.

Comments

What?

[TimMD909]

This smells like the result of MBAs ignoring engineers...

Re:What?

[ShanghaiBill]

This smells like the result of MBAs ignoring engineers...

It is worse in the military, because communication is inherently unidirectional, and they can go years between real world validations (i.e. wars).

"War games" are setup by the same people that are being tested, so if they fail the test, they can just change the rules and have a do-over. This famously happened during the run up to the 2003 Iraqi invasions, when opfor was repeatedly banned from using unconventional tactics, such as underage bicycle messengers and roadside bombs, because that was "unrealistic".

I had personal experience with this nonsense when I was a young lieutenant. I was part of the Red Team (opfor), and we were hopelessly out numbered and out gunned since we were playing "insurgents". So we decided to go asymmetric ... and cut off the Blue Team's water supply. I was told that wasn't allowed, and to turn it back on immediately. So then we set up road blocks that targeted their chow trucks. Nope, that wasn't allowed either.

But we were permitted to launch a hopeless frontal attack directly into their entrenchments, which we did on the last day of the exercise so we could go home early. In the after-action critique, I can remember the colonel getting up and congratulating everyone on a job well done. That's when I decided a military career was not for me, and I am not surprised that America proceeded to lose several wars.

Semper Fi.

Re:What?

[Anonymous Coward]

"That's because the purpose of wargames is to test systems and get people used to doing their jobs under stress"

Im genuinly curious, why do they call it war games then and not system testing?
Why do they not provide a procedure for the Red team to follow?
If not a procedure, why do they not provide limitations for the Red team?

I mean if the purpose is to test the systems under specific circumstances then why not lay those circumstances out ahead of time? If they do, then yes the previous poster that you replied to is an idiot for not following the rules of the game. If not, then isnt it someone else's fault that they didn't define the rules properly in the first place?

I mean if you go and tell me to perform action X (like attack a base) and then i perform action X, how can anyone call me an IYI if they didn't specify how they want action X done? wouldn't that mean that someone higher up the food-chain is the IYI by assuming that someone else would perform action X in a specific manner? To me it sounds like there were several IYI's in the scenario mentioned.

note: I do not actually know anything about war-games in the us military, so i am curious how these things are supposed to work.

Security as an afterthought

[phantomfive]

GAO said all tests were performed on computerized weapons systems that are still under development.

You can't add security on as an afterthought. It needs to be a core feature.

Rational risk/reward calculations

[Tablizer]

To be fair, managers are more likely to be rewarded for delivering a sufficient product on time than ensuring proper safeguards. A missed deadline will almost surely be noticed and put on them, while slipshod security has roughly a 1 in 10 chance of showing its head during a manager's actual reign. (The marketing people negotiated the contract, not the project manager, and the marketers often under-bid to win.)

They are behaving "rationally" in terms of their OWN risks versus rewards. The managers are following the carrots and sticks which are actually applied to them like donkeys would.

It's kind of like debt and pensions versus politicians: they won't likely be in office anymore if they muck either of those up bad enough for the public to notice, so they give short-term handouts instead, dumping the long term problem onto the future. In the future, you will hear, "I didn't do it, my predecessors did."

unit conversion help

[n3r0.m4dski11z]

"including one team that downloaded 100 gigabytes, approximately 142 compact discs, of data."

Not archaic enough. I'm gonna need that in number of baskets of scrolls please.

Insiders though?

[Gilgaron]

Not that they shouldn't do better, but, say, if someone can only hack a Phalanx system from inside the aircraft carrier from a secure access terminal then it is probably not going to end up exploited, since if you can get a mole in that deep they can probably do more damage throwing a wrench into the right place.

Re: Gee, good thing they didn't open source any of

[Sarten-X]

No, no, fuck you, and no.

This is a horribly bad approach to security. You're making assumptions about the external environment, and using them to excuse system vulnerabilities. That's not realistic or intelligent. It's just lazy.

Lets not forget the anti hacking. A bullet in the head of the traitor.

That's assuming you can find a traitor. If the system logs aren't secure, or if their integrity is questionable, or if they don't uniquely identify an individual, you have no hope of identifying exactly who attacked the system.

Systems in development are not complete

So? Security isn't something to be bolted-on late in the development process. Systems should be secured first, then the functionality is applied on top of that. If that means you have to use more-costly (but more secure) solutions in your design, so be it. When functionality comes before security, management is far too justified in saying "but we've spent too much already developing this insecure system!" and refuse to reimplement it securely.

For a related example in the public sector, we're almost done implementing HTTPS, after only 10 years or so...

Systems are in very high security locations, especially when deployed

At first, maybe... then a truck gets ambushed, or a base is overrun, or we get an impulsive politician who promises an arbitrary date to get out of an unpopular conflict area. Then those systems fall into enemy hands, and you just have to hope that it's a useless pile of hardware by then.

Systems are surrounded by many soldiers

Soldiers are underpaid, overworked, and usually focused on things other than countering highly-technical intelligence techniques. If an attacker walks onto a base, steals classified data (or even whole systems), and tries to leave, they'll be saluted at the gate as long as their paperwork looks right.

There is no valid excuse for leaving a system insecure by design. Every layer of the system should be built securely, with the functionality added afterward.