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.
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.