DOD Just Beginning to Grapple with Scale of Weapon Systems Vulnerabilities
gao.gov
gao.gov
https://www.gao.gov/assets/700/694913.pdf
- Running a port scan caused the weapons system to fail
- One admin password for a system was guessed in nine seconds
- "Nearly all major acquisition programs that were operationally tested between 2012 and 2017 had mission-critical cyber vulnerabilities that adversaries could compromise."
- Taking over systems was pretty much playing on easy mode: "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."
My takeaway impressions (other than that god damn do these people drink and holy shit are they young), especially after talking to the mechanics and network IT folks, is that a ton of their systems are old, the manpower turnover is between 1-2 years as they get cycled between boats (or 4 max as most of these kids are just putting in their 4), and training is extremely specialized. Most parts of the systems (this especially from the mechanics) usually perform to about 10% their pitched lifespan from whoever made them before they fail, repeatedly.
The windshield wipers on all Ospreys (those dank helicopter/plane things, think Ghost in the Shell) have been disabled/removed because their motors would catch fire in inaccessible places near the pilot's feet.
The only thing preventing access to a boat's network is standing orders and the threat of punishment. You can just plug right in.
Every system runs on the same network. This includes radar, weapons systems, anti-air, emergency comms, in-ship cameras...
This on top of the fact that half the people I talked to, the ones actually running these systems, are overworked 19 year olds with circles under their eyes. The only people over 25 seemed to be officers and pilots, maybe those guys know about the systems and can offer expertise? I'm not sure, I didn't get to talk to any of them.
I'm hoping my perception of the military is completely wrong, which is entirely possible because I didn't get to talk to that many people, maybe like 4 or 5 mechanics, a couple marines, and a couple of the network IT people, all relatively low rank. But, as of right now, I have absolutely no confidence in the military to withstand a full on cyberattack from a similarly provisioned military.
What kind of work do you do? You're in the military? What's your rank / job description? That's the kind of information I'm curious about. If the answer is "I can't tell you because it'll expose personal information," well, I'm not the one that outed you lol.
Well, there you go then. Thanks for being honest at least.
So that leaves a number of specific statements which you could each refute, in part or in their entirety. Judging from the title of this article and a number of other anecdotes in this thread (some by other people that served) it seems his anecdote is entirely believable.
That you can't extrapolate to all of the army would be a given.
> The windshield wipers on all Ospreys (those dank helicopter/plane things, think Ghost in the Shell) have been disabled/removed because their motors would catch fire in inaccessible places near the pilot's feet.
Well, this is not related to the main point about cyber security. If true, it's just a piece of equipment that was found to be flawed. It is a non-essential system that was made INOP.
The Osprey is a marvelous piece of engineering that is difficult to replicate by other nations.
> Every system runs on the same network. This includes radar, weapons systems, anti-air, emergency comms, in-ship cameras...
Physical network or logical network?
> The only thing preventing access to a boat's network is standing orders and the threat of punishment. You can just plug right in.
And then do what once you are in? Unless we are assuming there is zero security, this doesn't mean much. Besides, you have to be on the ship already.
I'm not saying that the systems are adequately protected, they may not (as the article states), but there's too much information missing for us to play the role of security auditors.
It's a testament to the attitude and quality control practices of the suppliers who also supply the networked equipment.
Whatever I have heard about the Osprey nobody should want to replicate it. Too expensive, too complex.
https://medium.com/war-is-boring/the-v-22-can-t-spend-even-o...
That's a problem if you just encounter the ship on open sea, but if you anticipate a conflict it shouldn't be hard to turn one of the literally thousand people crewing the ship. Just find one person who you can force/incentivize to plug an LTE enabled network device in and start hacking from a safe distance (bring your own LTE base station for hacking on open sea).
"Running a port scan caused the weapons system to fail"
Security can't be imposed by the system on its users. They have to cooperate.
With modern crypto there are very few systems where it's appropriate to have a user-selected <=12 character password for primary auth, yet unfortunately that continues to be widespread for banks, ecommerce, and (probably) some military systems. High-end security people seem to almost universally hate short user-selected passwords (except when they have to break them..) but old practices die hard and old systems take a long time to be replaced.
When I later also took biology classes (and org. chem., biochem., physiology etc etc) I could not help but see parallels - I say parallels, not transferring the models over! - to how we develop huge systems, be it software, hardware or the combination of both. No single human understands even a significant part of them any more. "Deliberate design" is not the sole force working on those systems any more.
> expose, alter, disable, destroy, steal or gain unauthorized access to or make unauthorized use of an asset
This is the objective of the adversary in a conflict with respect to information and systems security. It doesn't matter if they can control a system, if they can make it less reliable it's still a win (but not as good). If they can get it to feed out false or misleading information to their opponent, it's a win (hacked a radar, can you show an extra blip on the screen or cause them to sometimes shift position and reduce the confidence of the operator?).
But that doesn't mean the enemy can't learn information and be able to predict our next moves in a conflict. Like what we did with the enigma in WWII, we are subject to the same type of listening where someone knows our next move before we make it.
The last thing you want is someone forgetting their password to their tactical system while out at sea and having to sail back into port to get the vendor to reset it for you.
And really, the first case is no worse than the old days with manual controls that just anybody could walk up and fiddle with.
In that case, you could trust physical security to some extent; someone really not intended to be in contact with the device could be prevented from doing so by some dude with a big gun. Now, those devices are networked, so someone could figure out an access method and use it on all the devices in the field at will.
"Do you want to play a game?"
This is some scary bad WarGames like security, password 'joshua' level.
> Program offices were aware of some of the weapon system vulnerabilities that test teams exploited because they had been identified in previous cybersecurity assessments. For example, one test report indicated that only 1 of 20 cyber vulnerabilities identified in a previous assessment had been corrected. The test team exploited the same vulnerabilities to gain control of the system. When asked why vulnerabilities had not been addressed, program officials said they had identified a solution, but for some reason it had not been implemented. They attributed it to contractor error.
Ah, the old blame the 'contractor error' and 'not invented here' syndrome. Looks like engineers aren't in the power structure to change these things, scary if the military is driven like an MBA only led business with no influence from engineering/security.
Having known many people that worked in/around the military and defense industry, this seems like our reality.
The amount we pay for security, it is appalling some of the data in OP's report just to hit some arbitrary number over security and understanding of a defense product.
> The modern DoD is based around the Asst Sec Defs and business processes put in place by Robert McNamara
Robert McNamara, a Harvard Business School MBA, 'epitomizes the hyper-rational executive led astray by numbers' [1]
[1] https://www.technologyreview.com/s/514591/the-dictatorship-o...
> “An interesting question is, ‘Where did the name, dynamic programming, come from?’ The 1950s were not good years for mathematical research. We had a very interesting gentleman in Washington named Wilson. He was Secretary of Defense, and he actually had a pathological fear and hatred of the word, research. I’m not using the term lightly; I’m using it precisely. His face would suffuse, he would turn red, and he would get violent if people used the term, research, in his presence. You can imagine how he felt, then, about the term, mathematical. The RAND Corporation was employed by the Air Force, and the Air Force had Wilson as its boss, essentially. Hence, I felt I had to do something to shield Wilson and the Air Force from the fact that I was really doing mathematics inside the RAND Corporation. What title, what name, could I choose? In the first place I was interested in planning, in decision making, in thinking. But planning, is not a good word for various reasons. I decided therefore to use the word, ‘programming.’ Iwanted to get across the idea that this was dynamic, this was multistage, this was time-varying—I thought, let’s kill two birds with one stone. Let’s take a word that has an absolutely precise meaning, namely dynamic, in the classical physical sense. It also has a very interesting property as an adjective, and that is it’s impossible to use the word, dynamic, in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It’s impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities"
--Richard Bellman on the naming of dynamic programming [1]
MBAs are a zombie fungus disease upon companies
As an MBA holder and avid HN user, I take issue with that statement...
Why try to make this link if it isn’t there? What if I replace MBAs with ‘foreigners’, ‘women’, ‘people who read HN’, etc?
Why do we need this? Does blaming non-technical people for the failures of management make us feel better about ourselves?
The thesis that parties who have negligible expertise in a given area given charge of people with substantial expertise in that area contribute minimal or negative value seems at least arguable.
Maybe we as a society value the idea of teaching people to lead people irrespective of what those people actually do instead of elevating skilled individuals in that area because it allows us to reward all the rich peoples kids that aren't smart enough to do.
This needn't mean you automatically are unintelligent or bad at what you do. You could personally be awesome and contribute greatly to the efforts you work with/lead.
MBAs are used as straw man punching bags on HN. Anything that goes wrong with a company where there’s the perception that the “obvious technical solution” was ignored, is blamed on this nebulous cabal of MBAs, who are apparently hired in droves just to sabotage their employer. For some reason it’s totally ok to vaguely blame the business folks.
I think you're building a bit of a straw man. I think the criticism of MBAs rests on criticism of the idea that good decisions can be made by people that chiefly have "management skill" but lack "domain skill." A lot of people believe domain skill is extremely important, and if you stuff an organization full of empowered people who only have management skill, you'll get more bad decisions. You'll also get a lot of dysfunction as they spend too much time pursing the "management ideas" they're more comfortable with, and neglect "domain ideas."
This comment actually touches on some of these issues in detail: https://news.ycombinator.com/item?id=18179247
Obviously not. I think the critique is about MBAs who don't have domain experience and don't think they need it, because they have a generically-applicable "management skill." That ponderous specification is typically shortened to "MBAs" for brevity, since it apparently has some root in ideology that's common in business schools.
Here's a few concepts that came out of B-Schools/MBA land. at a grossly brief, thus over-simplified level:
* "Shareholder value" as the prime goal of management, justifying the exclusion of all other stakeholders (employees, customers, community supporting the business, country supporting the business, etc.). Few concepts have done more to damage this country and capitalism itself (note the main problem of shrinking middle class able to purchase the goods produced).
* "Manufacturing is fungible & expendable, just outsource it to the lowest-cost country". Massive damage to developed nations' economies, and national security, all to goose short-term profits. Actively destroys massive corporate value of know-how, simultaneously providing both the existing know-how and ability to generate new know-how to new competitors.
While all the MBAs thought we were exploiting the cheap Chinese labor, the Chinese were looking long terms and exploiting our myopic need for short-term profits to gain massive economic & military advantage (note the recent controversies about planted chips, among many other similar security nightmares). This will go down in history as one of the all-time great geostrategic blunders, brought to us by MBAs.
* "Invest in the stars, milk the cash cows, dump the dogs" -- breaking down your business units in this way, guarantees that the business will become a shell of its former self -- the dogs will be sold off with no regard for their potential if invested in (they may be developing key breakthrus, but not yet showing good financials), the cash cows will be starved of all potential and soon become dogs to be sold off, and maybe the stars work out or maybe they don't. Great way to kill a business. GE was financially managed -- where is it now?
* The general concept that I've seen multiple times of focusing on managing to the financials instead of managing to CREATE great value. The financials will ALWAYS look better when investment in building true value and a competitive moat is overlooked to cutting costs and goosing current sales. These numbers will look good and increase for a while, possibly years. Until they don't. At that point, the business has no hope, and is a walking zombie, unrecoverable.
So, yes if MBAs are kept in their suitable container of 1) installing good accounting practices for tracking and security of financial assets, 2) managing the profits that are made to ensure good returns, 3) optimizing operations & taxes (lease vs. buy capital assets?, etc.), then things will work out great.
But putting them in charge without also having serious domain knowledge, both on the customer/market side and on the engineering/manufacturing side -- very bad idea.
Since then, however, there has been the constant desire to deskill workers. That is, they want explicit operating/work instructions that mean even a trained monkey could do the job. This is useful for some things (got a broken down Jeep? Pull out the manual and even your Lt can fix it!), but for development, acquisitions, and sustainment this is actually a horrible idea.
The infection of deskilling spread to the office. They've removed the office managers (among others) and left the work (critical, but time consuming and secondary to the mission) with the highly educated and trained staff. This diminishes their ability to focus on real work (see [0] from yesterday). From there, they continued to try to document precisely how engineering work is done. Believing that the process of the work is the same as the work. So if only my engineers knew how to properly fill out SF-1234 it wouldn't matter how educated they are, magically the work would be done.
Of course, we all know this is bullshit. Knowledge work is called that for a reason. The capacity for work is based on the knowledge of the workers. You cannot deskill computer science or aerospace engineering. You can deskill aspects of it, or really the workflow, but not the science and engineering work itself. I can eliminate or largely reduce the need for a classical configuration manager by establishing a (automated) peer review and version control workflow. But the creative act producing content that enters the workflow will always require skilled, competent, knowledgeable engineers and scientists.
[0] https://news.ycombinator.com/item?id=18157885
EDIT: I will not change the above, but I will make a note. After re-reading the Wikipedia page on Scientific Management [1] I see that some people consider Lean and others to also be extensions of it. So read the above as describing Fordism and Taylorism, not scientific management in general. Any management largely based on, or influenced by, statistics, models, and experimentantion could be argued to be "scientific management", that doesn't mean it's bad. It's when it's taken to an extreme. Like, in Taylor's case, where workers are treated with contempt. The purpose of the management being to make them fully expendable. They had no unique knowledge or skills that could really contribute to the business beyond their physical presence and ability to follow directions. His goal was to disempower workers, whereas other examples (Lean particularly) work to empower workers.
Small teams with skilled people, the startup model, works best even in large companies. Closer to the customer and more cohesive unit makes for a better project, that is why innovation happens at smaller companies or small research groups in companies or universities.
n(n-1)/2 is the formula to calculate the number of communication channels on a project where n=the number of team members/stakeholders on a project.
On a team of 1, it is all you, you make sure it works.
On a team of 2-3, it is just that few, you make sure you and others are doing their part.
On a team of 10, 45 communication connections, you might not have the same level of care because that isn't my role or someone else has got it. Beyond 7-8 team members communication becomes humanely impossible.
On a team of 100, you have so little power/responsibility that you feel out of place calling attention to issues, you don't know of everyone on the team even.
Metrics are a good thing, to use as an input, so is customer feedback, product goals/focus, usability, employee satisfaction and many other things that aren't always measured like technical debt, product quality, security, simplicity of processes/production, research and development and more.
If you measure the wrong things, it can give you the wrong idea that you are moving in the right direction while possibly overlooking aspects not captured in metrics.
If you only looked at revenue and employee head count for instance, growth might be deceiving. Profit and revenue per employee better, but also employee satisfaction, customer satisfaction, the market, product quality, timing, security, long term direction etc etc get overlooked in the metrics department mainly because domain knowledge has less power than oversight in most mature organizations.
This reminds me of bystander effect [0]. The demarkation of responsibility in large enough teams could invoke delays just in finding who is responsible for what.
To be fair, it could also be a death ray laser. The whole thing looks a lot more like Star Wars than a real plane. It has asymmetrical wings.
Back in WW2 it definitely did, especially in the UK where bombing had no respect for the class system. Winning or losing the war would make a personal difference.
But since then? All the wars have been overseas with no real threat to the mainland US; there was a real technological race against the Soviet Union, but that ended in the 1990s. The post-911 wars were more of an excuse to settle scores and play the Great Game than a real effort against terrorism (no pursuit of the Saudis for example).
The consequence is that the main thing that matters is selling the technology to the Pentagon, or promoting a career inside it. Nobody really believes that if they procure a crappy IT system the enemy is going to fly a 747 into their office. Someone might get killed, but nobody they know or who matters, and it's never going to come back to the project manager or procurement person who made terrible, expensive, uninformed choices about technology.
I have to hope that the people in charge of these things -do- care, and that it's simply difficult to get this right. However, given some of the things in the PDF, one has to wonder...
I also wonder sometimes if a similar thing isn't happening in enterprise software - that is, actual software doesn't have to work; it only has to serve as an object of trade between companies, and all the problems will disappear in general organizational noise & inertia.
- Stovepiped organisations: stick in your own lane. But security is cross cutting.
- Security orgs want to stick to what they know about, not what the threat scope is.
- Security unwilling to own risk, fall back on ass-covering checklists and mandatory processes. This leads to them being an obstacle, a cost rather than a benefit.
- True lack of expertise at stakeholder level. Particularly in the US, the experts are contracted, and never speak out of turn.
- Staying quiet. Americans are extremely conscious of organisational (rather than technical) status and embarassment, and it isn't career enhancing to identify naked emperors.
- Good security costs money upfront, and pays back over time. Bad security is free at the beginning, and costs massive amounts to fix, but: (a) fixing is someone else's problem, (b) fixing is new contracts and more work, (c) systems might not be noticeably hacked.
Large companies (e.g. Lockheed Martin) are often very adversarial, and deny fault with lawyers. I've often wondered if places like Japan, with more cooperative cultures, can address this differently.
How well this statement retains its correctness across time and space. Pretty much my experience in every company beyond certain size.
> Security unwilling to own risk
Security cannot fundamentally own risks created by other parts of the organisation. I'd actually put it the other way around - the organisation is often unwilling to own risks identified by security.
For example, the chem eng group own the risk of the chemistry being wrong and the plant blowing up. They don't get to say 'let's outsource production to ChemCorp'. Likewise, security needs to secure the ICS, not just ignore it and say 'the SCADA guys do that, it needs SMB1' or when the risks are pointed out say 'you must now change the passwords every 30 days'.
Business units burying their head in the sand? Well, that can happen too. Pen-tests are great for demonstrating problems, but how many security orgs have the ovaries to do them and force realisation? Did security work with the business unit to mitigate risk, or just want to shut it down?
I'd love to get specific but my point is that there is a lack of holistic vision across the enterprise, and incentivising cooperation between stovepipes is needed, and being willing to take risk -- not throwing away the rule book, but writing a new chapter on how to apply it in context.
https://securityaffairs.co/wordpress/53856/cyber-warfare-2/d...
Japan invented some of the best aspects of safety culture, like being process driven, checklists, point & call https://www.atlasobscura.com/articles/pointing-and-calling-j...
It has been remarked before that if security was treated the same as safety critical systems (like aviation operations, and increasingly, hospitals) then we would have much better security. Tbh, I'm not sure, because of the adversarial nature of attack and defence, but it would be interesting to test.
However, one that I know eventually got fixed I'll talk about (it makes a great example anyway). When port scanning one of our pieces of equipment, I noticed a strange port number that was accepting packets. I started sending random packets to it and for the most part it ignored them, but occasionally I could get the system to crash and restart.
Turns out, the server had a debug port enabled and active, even in the production build. This allowed you to essentially invoke any C function you wanted, remotely, if you knew the format (which was published in the OS manual)! Very, very bad.
When I reported it, I got a lot of responses like, "Well, this will be on a closed net anyway." and "If they get on this network, there's much bigger problems." Both statements were true for the most part, but still a very dangerous attitude to have. Just because a network compromise would be bad, doesn't mean you should make it worse by neglecting defense-in-depth. And never assume that somebody isn't going to plug an ethernet cable into your equipment that shouldn't be there (this happens all the time).
If that was the whole story, the military budget would be plummeting as our representatives realized that they could also, and far more legitimately, take money away from the military to put in their pet projects.
Law enforcement has about equally broad support, including from anti-federal-government groups (though not always the same ones that back the military, as their are pro-law-and-order anti-interventionist groups that aren't keen on military spending, and pro-military groups that are federal law enforcement as jackbooted authoritarian thugs.)
But testing gives the lie to all this. The patriot system was battle tested in the 1990s and its deficiencies became apparent - and lessons seem to have been learnt.
So perhaps more adversarial testing is the right approach - set the marines to take out the air forces weapons, the navy to destroy the army.
If people know their beloved weapons systems are going to get roughed up, then the tick box stops being the determinant of achievement - it becomes "what would one of those navy/marine/air force/army bar stewards do?" That's a much higher bar.
tl;dr blow shit up and see if it still works
I seem to remember a story about "how good is the SAS" because they were asked, after years of development, to try and destroy an armoured train that carried nuclear material from power plant to disposal (it ran through populated areas so was proof against head on collisions at a gazillion miles per hour and so on)
The guy took a calor gas canister, filled the train half full of gas and lit it. The armoured million dollar train of course ruptured with the internal explosion.
kudos to the well trained SAS demolitions expert, but i suspect a lot of the army could have done that, at various earlier stages.
not sure where that is going, except, yeah blow things up, early on.
But I was asking a question of ethics, not fact.
Maybe write some weapons systems or work with people that do and you would have a different perspective.
Given that that's not really reasonable, maybe you want to give us some perspective? You can't go around accusing others of low effort comments and then not provide any insight yourself.
They had some goofballs policies that made it seem like vulnerabilities were the goal. I could bitch at length. Their TSA style security theater practices were the order of the day. The IA training was an embarrassing joke and they made you do it often enough to make you a little crazy.
I just checked the certificate of networthiness page and they don't have a valid SSL certificate. I recall that being the case years ago too. I wonder if it's been that way for the last 7 years? That's a cute little terrarium of the whole biome I remember.
Off topic a bit, but that all aside... I am more proud of the work I did there than at any other place in my career. I got a lot of excitement and engaged feedback about the interactive learning materials I created.
I'll never know if it made any difference, but the mere fact that someone's son or daughter COULD have noticed an IED threat they wouldn't have otherwise because of my work gives me all sorts of proud fuzzies.
That work had way more meaning than all the other CRUD/ML/Advertainment schlock I'll get to do for the rest of my life :)
That's not quite true. Internal use sites don't have a valid cart issued by a "default" external vendor.
Public sites use existing CAs that are in use by the public. E.g., the Marines public facing site[0] is signed by DigiCert. If you go to a site that's public facing but for internal use like MoL[1], you'll see that the cert is issue by an internal DoD CA. This is intentional.
The DoD has an internal CA already set up. These internal use sites are a gateway to sensitive information, so the DoD doesn't want to rely on an external CA for HTTPS. What I never understood was why these internal CAs weren't marked as trusted on the internal machines. That would avoid the browser warnings when accessing one of these site from DoD hardware, and it would (in theory) force the user to double check when accessing the site from an external device.
[0]: https://www.marines.com/ [1]: https://mol.tfs.usmc.mil/mol
What I find as the most common error is that users setup an alternate browser (such as Firefox) that does not use the system certificate store and then lack the system's local certificate authorities.
Additionally, DOD PKI is now cross-signed with Federal PKI (FPKI), so it's larger than the DOD now and other agencies also use the same smartcards (PIV).
It seems we end up with a lot of possibilities for the states of these stores to diverge from our expectations ... I've been wondering how to verify a sane state for all these stores for even a use as simple as my own personally owned/controlled notebook ...
I'd really like a way to audit the system trust store in macOS and enforce that is in alignment with whatever the current 'blessed by apple' certificate trust relationships are and that any trust relationships I ever manually added by mistake/debugging have been removed...
I asked a question about this on stackoverflow but no one has responded ...
https://stackoverflow.com/questions/52527886/revert-all-cert...
What I ended up doing to help this process along is including the relevant certificates inside my DOD Smartcard PKCS#11 module as certificate objects (with, of course, no corresponding private key objects).
For applications that use PKCS#11 (such as Firefox, via NSS), this means that when the module is loaded the appropriate certificates are also made available automatically. This was also (I believe) supported by the "TokenD" driver used to support macOS/Mac OS X so that enabling this driver made those certificates available and provided by the token, so no modifications to the local macOS system trust store were needed.
As far as the SSL certificate, I assume you mean: https://www.atsc.army.mil/ ? That site seems like it has a valid certificate, if you validate against the DOD PKI (now cross-signed with FPKI) root CAs:
$ openssl s_client -CApath ./dod -connect www.atsc.army.mil:443 -servername www.atsc.army.mil
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA
Start Time: 1539109915
Verify return code: 0 (ok)My first year there it was a goofy flash game with uncanny valley cartoon characters awkwardly telling you not to share secrets at the bar to get laid. Every year I stayed it seemed to get longer and more awkward. At some point they added a boxing minigame that didn't have any training value. Nothing was optional.
It became a goal of mine that they'd let me remake it in a way that was... not patronizing... I never found anyone who knew who to talk to get me the project though. :(
The training likely stressed that just the source of the classified information was somewhere "outside" DoD it did not change the classification. This is because changing the classification requires an Declassification Authority to act on it, which is generally the Original Classification Authority -- of which there are very few.
Job offers are trivial to get. Meaning.. proper autonomy / feedback balance.. impact.. Life must be too easy for me to be such a snob. Neural fatigue is real.
If you're not ready for that level of commitment (though it's amazing work), and you're interested in being involved as a security researcher, reach out to me and we can talk about joining our bug bounty program.
Honestly, you don’t do this job for the money. I took a pay cut when I joined, on top of losing bonuses and equity. You join because you want to make a real difference in people’s lives, in a visceral, real way.
I can say without exaggeration that there are people who would have died except for the work that our team had done. Even when the stakes aren’t life or death, the impact you can have working for USDS is massive compared to anywhere else. You can personally change the lives of hundreds of thousands or millions of people. That’s the kind of hook that beats equity for me any day.
What that difference may entail varies greatly though. For one, it might be not being blown up by that IED. For another, it might be being bombed to bits at your cousins wedding, along with the other 40 members of your family, by a drone operator in Nevada. Very visceral indeed.
If you think that working for the military is "doing good" and the US is oh so innocent I suggest you watch the excellent documentary The Untold History of the United States by Oliver Stone [0].
[0] https://en.wikipedia.org/wiki/The_Untold_History_of_the_Unit...
1.) Does DDS really pen test developmental/operational weapon systems? I'm talking about custom flavors of standalone PIT systems at the lowest embedded level, not just public-facing unclassified commidity IT systems. Maybe I'm missing something, but the projects highlighted on DDS's website suggest otherwise.
2.) How's your Blue team ops? The current RMF meta in the field strikes me as an all-Red team party, while the Blue side of business is pretty much always MIA. I suspect it's partly because pen testing is fashionable these days, successful outcomes can be quite dramatic and perceivably understood by stakeholders, and avoidance of the inherent liablility of defensive posturing without significant impact to performance/capability if a complex system's requirements are not well understood (a compounded issue not exclusive to weapon systems), to name a few.
1. Well, this is rapid deployment, we can't have everything.
2. The enemy here is fairly low-tech. Shouldn't be a problem.
Needless to say, I'm not surprised by this report.
Would be perfectly acceptable if your hardware was only used for 2-3 years against only low tech enemies that don't have access to electricity during that whole time.
There aren't many low-tech places left on this planet, where it comes to computing.
Tell that to Vietnam and Afghanistan. Historically the US does well against standing armies (Iraq for example), but absolutely terribly against low-tech enemies who don't engage in a way that allows these super high tech weapons to be used effectively.
Reminds me of this: http://www.kiplingsociety.co.uk/poems_arith.htm
A scrimmage in a Border Station-
A canter down some dark defile
Two thousand pounds of education
Drops to a ten-rupee jezail[1].
The Crammer's boast, the Squadron's pride,
Shot like a rabbit in a ride!
There have almost certainly been satellite, submarine and other engagements too, they just aren't generally publicized by either side until 30-40+ years later.
Battles won by numerical superiority are usually won by defenders. If it's an invader, it's almost certainly early in the game. Even at the end of WW2, Germany wasn't invaded so much as it lost in France and Russia. The Allied rush to Berlin was an early aftermath. By the time supply chains necessary to conduct a protracted war have been committed, the true cost starts making invaders progressively less interested.
A more interesting concern is the major powers using proxies to demonstrate their new tech. If Russia sold Syria 10,000 drones, that might get interesting.
Sorry, no. Germany was very quickly overrun in 1945.
https://commons.wikimedia.org/wiki/File:1945-05-01GerWW2Batt... https://commons.wikimedia.org/wiki/File:1945-05-15GerWW2Batt...
Le Duan tried to in Vietnam, the Easter Offensive. Despite fighting to a strategic draw, he under-estimated the effectiveness of US airpower and lost 100,000 men on the field.
It's not too surprising and a little reminiscent of the security nightmare that are IoT devices.
All those weapon systems come out of hardware/engineering companies with little background in software engineering and the accompanying security best practices.
What I'd be most concerned about is that the procurement process is favouring companies who clearly aren't up to designing in rudimentary security, in weapons systems, ... smh.
That seems like getting clothing made and not having anyone flag that it was glued together with PVA instead of being sewn; and the company you hiredb not having anyone who realises that's a fundamental problem.
http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...
https://www.ghs.com/products/safety_critical/integrity-do-17...
https://runtimeverification.com/match/
The defense buyers just don't use such companies or products in most cases. They know they don't have to due to corruption mostly. The money they save might even get someone a bonus for achieving some metric like keeping costs down. Mass market is similar where they don't buy the stuff either. So, the supply of high-security systems are extremely low, usually high per-unit as a result, and not prevalent.
Sad but true...
For perspective, not too long ago during WW2 and following wars the best measures we had were napalm firebombs and binoculars. Civilian deaths were much higher, and friendly fire incidents were commonplace. Technology, despite dystopic appearances, has helped reduce the brutality of war.
Look at things like cable set top boxes, and automotive entertainment systems. It's like they don't care what the software is as long as some bits that some supplier sent them are flashed onto the device.
well, I recall asking about the security of the systems (I was the IT lead and was to help design the global port tracking system which they hoped to track all shipping containers) -- there was no encryption/authentication on any of the tags.
If you had a reader, you could read/write the tags.
They had not even thought about securing these systems - and they were trying to tout them as a security system for weapons shipments. They even had tags that had G-sensors that were to be able to tell you if a munition was dropped, if it had armed (some weapons will only arm themselves once a certain g-force is reached which indicates to the weapon they have been launched.)
The inclusion of this graphic makes me realize the report is not intended to explain the situation to engineers. It's to explain the problem to well-decorated higher ups that probably don't understand modern technology all that well, yet are calling all the budget shots.
I'm less interested in this than I am in what we could do to fix it. Is it just more money to hire competent security engineers? Is it a more responsive talent acquisitions process that gets the right people in at the right time?
Standard operating procedure would need to change so the government entity has security as a requirement, details on how the requirement can be satisfied, and a bunch of money to pay for it.
So tack on $X million for each contract to have a 3rd party audit the code, documentation, and hardware for security vulnerabilities. And an added maintenance contract to fix any future vulnerabilities for the lifetime of the program (20+ years most likely).
From the higher up side, what do you get for all that money spent? No new functionality, no fancy demos. Going to be hard to convince them security is important when they can fund something they view as more critical or more interesting.
EDIT: To answer the question of what can be done, I think it'd require a culture change on the contracting side. The engineering side of the house is mandated to only do work that relates directly to the contract. The hours bid will likely be for the minimum necessary to satisfy those requirements. You can create a new interface, but you won't have the time to do any fuzz testing for example.
Also, I couldn't help it, the DOD plans to spend 1.66 Trillion on these systems! Perhaps if we instead stop making new fangled, more complicated devices that with have tenfold more vulnerabilities to catch, how about we just stick with the machines we have and make then hardened. I imagine that it would save us loads if we just do that.
I am no military expert, but it seriously looks like China has us in a stranglehold.
Cloud: it's probably unplug the aerial / network cable
The best case scenario is a quick cultural shift, with awareness of computer security threats overflowing from the military to laws and society in general.
Of course, those attitudes have changed through the years and Galactica is something of a relic. A reminder of a time when we were so frightened by the capabilities of our enemies that we literally looked backward for protection. Modern battlestars resemble Galactica only in the most superficial ways...
They'll really have to set the passwords properly though.
If something like Minix 3 "NetBSD" in Rust ran on seL4, that would inspire more confidence.
Yeah, I've been thinking about that for a while. There is Genode/seL4, but it's hard to say if it makes as much sense.
Just thinking this isn't a U.S. only problem.