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 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.)
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...
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.
"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.
> “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]
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...
MBAs are a zombie fungus disease upon companies
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.
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.
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.
> 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?).
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.
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.
> 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.
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).
https://medium.com/war-is-boring/the-v-22-can-t-spend-even-o...
"Running a port scan caused the weapons system to fail"
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.
Well, there you go then. Thanks for being honest at least.
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.
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.
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.
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.
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."