With software systems, instead of demanding a perfect defense against the root password being compromised, think "if the root password is compromised, how do we prevent that from bringing it all down?"
In other words, think in terms of redundancy and isolation between systems.
And the largest piece of hubris and madness in critical systems is allowing over-the-internet updates.
I've worked professionally in both industries; they are not fundamentally different. Software practices can learn a lot from aviation practice, but they seem determined to spend decades rediscovering the methods the bitter, expensive way.
For example, software is still stuck in the dark ages where the idea is better training / better programmers / more punishment will prevent these sorts of failures.
What is your source on this? This goes against what anyone at any company where I have worked at ever believed.
No-fault root cause analysis, process improvements, inherently safer practices, languages, libraries is what every place aimed for. I don’t even know what you might mean by punishment?
See "Trust the programmer" https://beza1e1.tuxen.de/articles/spirit_of_c.html
Also, a general belief among C++ programmers that better training is the answer to programming bugs. This belief is slowly fading, but it's got a long way to go. Scott Meyers' books on Effective C++ represent a lot of effort to educate programmers out of making mistakes. For example, from the table of contents: "Prefer consts, enums, and inlines to #defines". If C++ was an airplane, #define would simply be removed.
> I don’t even know what you might mean by punishment?
There are several calls for punishment in the comments on the article.
The question is whether both sides are doing their best, within reason, to mitigate issues. The programmer doing everything right while the admins forget to patch for years won't change a thing. The opposite is true, patching or configuring correctly won't do a thing if the system is full of "built-in" holes.
It's not a stretch to think of a setup where specific conditions that define this "within reason" are established for software developers and administrators. It's what an audit should normally uncover: weaknesses in the process, points for improvement, etc. Only this time it would be in the form of general and specific guidelines that get progressively stronger as time passes. It's not a sure thing but it raises the bar enough for most ransomware attacks to become cost prohibitive for the attacker.
So would that make D the airplane version of C++?
https://dl.acm.org/doi/abs/10.1145/3386323#:~:text=The%20D%2....
BTW, I practice dual path in my personal life. If I'm doing something risky, I have a backup. For example, when I work under my car, I put the car on two sets of jackstands, even though I use stands that are rated for trucks. I'd never rely on a single rope/piton if rock climbing. I cringe when I see climbers doing that. I carry an extra coat in the car in winter, and water when driving in the desert.
I like much of the way D's designed. It doesn't try to be flashy, gimicky or different for the sake of being different. It gives you a set of practical tools and doesn't try to be too opinionated on the way they should be used. It mostly makes it hard to shoot yourself in the foot. But if you really want to you can. You gotta really try though.
The simpler they are, the easier they are to learn. The easier they are to learn, and less "opinionated", the less resistance they tend to build up against adoption.
D is interesting, because it seems, from my experience, D, like Ada, has been a hypeless language. Though I haven't checked on licensing encumber meets that might be behind that.
You can frequently see them come out in Rust threads, they're generally against it, coming from C/C++, it seems a common attitude amongst low level devs in my experience (there's a thing with "hardware" sounding "hard" which I guess makes them feel more "hardcore").
It's obviously not universal, but it's super easy to find if you search for some programming language discussions.
When the docs exist, and are accurate they can somewhat hide behind "get better programmers"; when they aren'the some can be even moreso, because there is nothing worse than trying to drive poorly documented hardware. It either works or it doesn't.
T. QA guy amongst a bunch of dev types who regularly points out how they do a great job implementing the wrong thing on a regular basis, and helps shape process to make that harder.
The fact they come out in Rust threads has more to do with Rust's evangelist types running afoul of the long standing love of "things that work". Somewhat in the cowboy camp's defense, none of theach no guardrail's type ever turns down a good static analyzer or test suite once you figure out how to get it smoothly integrated into their process. That's where I think Rust gets their outreach wrong.
Don't try to sell development on a brand new lang to learn and replace what they are using. Use the lessons you learn with making that lang, and improve the tooling they are familiar with. We don't have an infinite capacity to learn a new lang and library ecosystem every 6 months to just keep doing what we do. Once you get savvy enough with C and where the spec holes are, you've gotten to a point where you've gotten insight into how things actually work many levels more accurately than just about any other programming toolchain, and also onenjoy of the only languages completely divested of licensing lock-in on the planet.
There is also the point that you can'take really argue against C's effectiveness. It's always the first code to be made functional on any new silicon. I'm interested to see if Rust supplant's it, but I'm weary of any language that's heavily reliant on LLVM as I'm getting more savvy on how licensing risk tends to play out in the long run.
You can't beat the immortality and ubiquity of GPL. It is as close to the unrevocable toolbox from the public domain you'll ever get.
All of the things you mention are great, but they don't really address the problem. You need developers who know what the issues are and are willing to do the work to fix them even though they don't add anything to the feature list. In my experience, I don't have much reason to believe that today's developers are any better about that than yesterday's. There is a lot of security cargo-culting going on, which probably does improve the situation, but there's also a lot of "bootcamp" developers without the background to know that there are issues.
You'll never build a better tool than the one that eases your own pain. Make the user's pain your own, and beautiful things happen.
The software industry is to responsibility roughly as surgeons are to checklists.
Historically the choices were made to spend billions (and trillions) of dollars to invade countries harboring terrorists and use the situation to project power against other adversaries, advantageously control the price of oil, work trade deals, etc.
I predict the same path will be taken with cybercrime. The U.S. defense apparatus won't be giving subsidies to non-tech companies to boost security. Rather, they'll be waging war and using overlapping objectives and narratives to further other goals.
We might seem some special forces go into action under cover. However it would be assassinations done in such a way that Russia either won't know who did them, or is willing to look the other way (the later implies something diplomatic).
But there are other options: assassination for instance like Israel does with nuclear scientists.
Airliners are now pretty resistant to engine explosions, once thought to be impossible to do.
Keep in mind that a bunker will never fly.
Nobody is suggesting not going after criminals who attack software.
Though the prevailing logic on a bunker taking flight is that the engine size will be too large to be economical, which you probably factor in, Walter, but the uninitiated in the aerospace industry tend to simplify away.
Securing a company is like saying that you have to chnage all of the wiring in a country without impacting power supply. ALL of them - the house wirings, the cables transporting power, everyting. At once.
Security in a company is not a single system, it is a messy interaction of unknown dependencies nobody understands. And this mess runs a business.
Of course, there are plenty of things one can do but even for simple tasks such as "let's reset all the 100,000 accounts to make sure they are long/complex/whatever". This is asking for apocalypse.
How it is difficult is visible when you work in information security and have to balance the "we MUST NOT be hacked" and "we MUST NOT impact the business".
It didn't start out that way. It took a long time to figure out how.
> But this is not a good comparison.
I can't agree with that. I don't see any rationale for either airplanes or software systems being special.
> Security in a company is not a single system,
An airplane isn't, either. For example, part of airplane safety is the air traffic control system. Part is the weather forecasting system. And on and on.
If this was something done for fun and without impact on people then nobody would care.
Suddenly, a Monday morning, someone says "woah, this cannot be - you have to fix this". But this is not fixable, you have to build a new plane from scratch, or completely review the existing ones. Planes would be grounded.
Now a software company: typically your old plane flying by more or less miracle (when it flies). You cannot fix it, you have to rebuild it. Either you ground the company and force them to build something new, or you will always have legacy.
The legacy is not fixable - it simply is not. You need money to redo everything and if you do not have the proper pressure then it will not happen.
Then, building a new company/software can be done the right way. This is not even difficult, I would even say that having these constraints will help in the overall quality. But this is a new software, not a "fix" of the old one.
Just like software.
And now only FAA/EASA etc. certified companies and individuals can build a commercial aircraft.
And they can only build the aircraft they are certified to, using the same certified components, and the same certified tools. They cannot change any aspect of the construction without another round with the authorities.
Let me know when the CIOs of listed companies are up for that kind of lifestyle for their email and word processors.
And its precisely those methods that keep the planes in the sky.
Its not orthogonal, is a necessary prerequisite.
I think you're absolutely right that this kind of rigidity is not part of our tech culture, but maybe it should be if that tech is running power grids, [oil] pipelines, and other critical infrastructure.
In summary - maybe we should spend more money so that we get systems which are reliable and resistant to this kind of attack. (_I_ think that's probably a good investment for power/transit/core network/safety systems)
Yes and no. "No" because there are best practices and bits of midleware that although may still get improvement over time, receive nevertheless fewer and fewer changes (and have logarithmic looking dynamic of development). They mature. Advising strongly things that passed the test of time and broad use scrutiny just makes sense, regardless if that may look "rigid". (Not that many implement their own double linked lists nowadays.) Then "yes" because the our "tech culture" pool is big enough to also accommodate fashion, hype, and a whole lot of other psychosocial can of worms...
And that level of rigor is appropriate for the stakes that selling mass produced commercial aircraft implies. The discussion context was critical systems. But then you threw "word processors" in there. Why?
The point is, failing to secure those general use computers has bad consequences.
I just hope we don't take it too far. Many young and talented people in the CS and IT space cut their teeth testing the limits of legitimate access without pushing into the full on destructive regime these attackers have.
I'd hate to see things cracked down on so hard we lose a good signal for talent because we decide that the integrity of cyber systems must be defended at all costs. However, there needs to be a much more pronounced reaction to the types ofor blatantly malicious activity that has been escalating for the past decade or so.
What would you suggest in its place?
You'd need to replace the internet with something - postal mail, Fedex, courier deliveries, etc, or just have things that never get upgraded. Every one of those options has significant limitations, and in many countries, I'd trust SSL over postal mail every single day.
I think if you alter the wording to be "more-secure internet deliveries" then you'll have me agreeing with you, but unless I've missed something, your comment seems poorly aimed (which is odd, as your previous example of the root password is spot-on).
Do you really want a missile guidance system update-able over the internet? How about the auto drive system on your car? What about the code that keeps track of accounts in your bank? Don't forget the code that keeps the pipeline running!
The Internet has a two-fold issue.
A) It's fundamental ideation was an interconnected network of trusted nodes, with a self-healing capability to facilitate C&C continuity in case of nuclear attack. All protocols have underneath them that starting assumption.
There is an entirely unexplored depth of "authorization/security first" computer networking practice out there waiting to be enumerated, instead of trying to bolt-on security mechanisms to what is already built without an ideation of distrust built in from the get-go.
It's just so wildly impractical to implement, and undesirable to at least the Western philosophical foundation to free by default expression that it's not a natural thing to wrap one's head around.
B ) What are you gonna do to me? I'm behind 7000 proxies in different jurisdictions that work fundamentally different from yours and are unlikely to cooperate with your projection of power!
In short, it's a people problem, not a technical one. To the degree it is a technical one, the middle-boxes hold everything back <shakes fist>.
Taken to an extreme, anyone can take down a house made of straw with their fist, but nobody can exploit hello world.
I despise seeing simple apps with ridiculous dependency trees (package.json with line counts in the 5-6 figures, for example) and other complexity that can't possibly be fully understood by whoever's responsible for operating it. But I suppose things would be in even worse shape if we reinvented the wheel instead of using well-known libraries and so forth.
Solid libraries are boring and done: old, stable and active bug fix support. Not new features weekly.
Java or .net vs the js ecosystem. In our client contracts we have responsibility for our deliveries; in .net and Java we use well supported libs of over a decade old which we can support ourselves if the maintainers quit. With js this is an issue. Things are generally just not set up for decades of runtime and yet, there we are: we now have node js projects of almost 10 years old with many libs we have to audit and support ourselves and they are not very good quality. I think modern web is only just seeing the tip of the iceberg security wise. It will get much worse.
If I may quibble over a technicality, hello world is just one layer of an already complex technology stack. Suppose someone was able to slip code somewhere deeper in the stack such as your printf implementation (which generally a programmer will, and should, trust just works like it's supposed to) that opened a C2 channel. Then when you run your innocent hello world program, you're pwned through no fault of the program at the top of the stack.
Your comment speaks to exactly how people underestimate the true attack surface. It's far more vast than most anticipate, and their conception of it tends heavily towards the literal surface.
I think you have cause and effect backwards.
Yes, if you want to build a more secure house, you will need more material than another house with equivalent functionality. However, a bigger building isn't magically more secure than a smaller building.
If you walk into my house, I will detect and kick you out almost immediately. If you walk into our office building all you need is a hardhat and a confident stride and you can get anywhere you like. Hell, people will probably even help you get there.
Which makes it similar to code. The smallest app in terms of total 'material' builds up its queries with string concatenation. It takes a lot of 'material' to prevent those kind of injection vulnerabilities. And yes, a data access library that helps you with that is also 'material'.
After following the lock picking lawyer on youtube for a while, it seems to me there is a fallacy somewhere in here.
The weak points of a structure are often underestimated to begin with and adding complexity to the building (eg. door badge system vs. a good padlock) doesn't necessarily add security.
I have a counter example about scale. The more material you put into a city (the more houses you build), the more vulnerable it is (more potential problems, more opportunities for crime, etc).
While the house is less vulnerable than a tent, it can be secured for only as long as the flow of people and material through this house is very well controlled. The bigger squat house is not necessarily more secure. On a city scale free movement of people and goods is essential, and thus any place can be potentially visited (used) by anyone. We want the same urban infrastructure to be re-used by as many people as possible. There is a huge attack surface.
Code is more like a city. We want the same code to be re-used in as many different contexts as possible.
Company private security and protection against these attacks is more than abysmal. Just take the pipeline hack as an example. There should be no way at all that infrastructure critical to the nations security is getting shut down because of a corporate hack.
If the private sector wants to earn profit from these things they need to show they're competent enough to handle it.
---
What you described is a zero day, which is very rarely used - most ransomware simply uses the absolutely low hanging fruit of companies lagging behind years in security updates combined with highly insufficient backups.
In the same way companies do not have sufficient HA for their critical systems or processes. HA means being actively resistant to events impacting availability by having (typically automated) redundancy to remove SPoFs. It doesn’t mean HA owing to luck the server hasn’t died in 10 years owing to lack of/poor maintenance. But both with HA and backups companies can dodge bullets (until a real emergency) and maybe never even have a major incident.
Ransomware kind of exploits this lack of organisation level sufficient backing up of all critical information assets.
It really is as you say, low hanging fruit.
Personally I find this just puzzling, in my home folder I loose files at least once a year and I also lost whole partitions. So having no backup at all is no option for me at home. I cannot understand how no or unmaintained backups can be an option at companies.
Encryption introduces it's own SPOF's. If you'very never had a power failure in the middle of a key rotation, you've never been bitten back by your attempt at securing everything with cryptography. Or worse, corrupted by sketchy hardware.
Defense in depth, and proper threat modeling is key. There is also the very real question of "Do you really need that Internet connected anyway?"
Or they invested, but not in the right areas, or there was a new attack through a zero day.
They can be extremely competent in managing oil and gas (and the physical and operational safety that comes with it), but not be competent in Cybersecurity.
It’s real, hard costs today for something that may or may not happen and paying for controls that might prevent an attack. In the best case, as a customer, nothing happens. Whether improving the likelihood that nothing happen is worth a $1 or $3 per barrel premium (or if that $2 is justified) is a hazy mess and hard to make a decision around.
That's why you have government and law to require it. The free market solving everything is a myth, and the USA is lucky that all the pipeline hackers wanted was money. Imagine if that was a nation state trying to immobilize the military in preparation for an invasion. No ransoms, instead bombs start falling while you are paralyzed.
It's impossible to prevent all attacks, physical or cyber, so at some point one needs to either submit to an order where attackers act with impunity, or otherwise invest in retribution.
For what it's worth, a couple weeks ago someone (according to a manifesto, an anarchist group) did exactly that in Munich - they set about 50 10 kV electricity cables that were laid bare due to construction works ablaze to strike against a military supplier and cut off about 20.000 households for over 36 hours until the utility managed to restore service: https://www.br.de/nachrichten/bayern/stromausfall-in-muenche...
Sabotage or plain old theft against utilities is pretty common, but it's hard to do something physical that truly disrupts service for longer than a day or two - the networks are designed with reliability against all kinds of issues in mind. An IT-based attack leaves no traces if done well and can have a week to month long impact, simply because back when these networks were designed, IT threats were not existing.
The ransomeware attack in question wasn't capable of shuttering the pipeline as a target, whether the hackers wanted money or not. That was a voluntary action by the company, a questionable precaution they chose to take.
The US military isn't directly restrained by that pipeline. They have their own fuel supply lines that do not particularly care about that specific pipeline. And even if they did, they can go to the source, they don't require that pipeline for fueling purposes. They have other means of mobilizing refueling, up to and including anything that is necessary from a transport, manpower and logistics standpoint (including commandeering approximately four zillion private fuel trucks and tankers to get fuel moving for defense purposes).
There is no scenario where that pipeline existing or not existing tomorrow would shut down the US military or prevent its ability to defend against an impossible and amusingly implausible attempted land invasion of the US domestic territory.
So, imagine if that was a nation state (uh, which one?) mobilizing for an invasion that can never happen, an invasion that could never get across the Atlantic or Pacific. No.
Bombs start falling? From where? China? Russia? Russia is doing what, invading the east coast? With what ships? With what air cover? With what magical clandestine capability to hide a massive military as they sneak across the Atlantic on non-existent ships. With what aircraft carriers? And with China, so the US sends bombs back the other direction. The ability to throw a thousand nukes at China isn't restrained by the East Coast pipeline, and they know that, as does every other nation on the planet. Again, your setup is so far outside of reality that it's absurd.
Baseline security standards? Sure. But what is the baseline? And how influenced by lobbyists is that baseline? You know the big security companies would love to have their product be a government requirement. Attackers do not have regulations. They know the regulations and work around them. Makes it more difficult, but eventually they develop new attacks.
So now you’ve got this government body making regulations that needs people who understand security to make the regulations, who then need some way to audit the companies to ensure compliance. The companies then have to focus on the audits and not on emerging threats, or do both, and it increases overhead.
I’m not against government regulations when it is a good fit, but there are a lot of unintended consequences. The government is made up of people, too, and they may not be as close to the work to understand the optimal allocation of resources to minimize security risk.
Further, would the same be true of giant pharma companies that create drugs that we ingest? ("Oh, skip those tests. If a few people get injured, we'll pay hush money.") Why don't we see it? Simple: Incredibly strong regulations in US/EU/Japan (the "big three" for global drug regulation & approval).
And the trick to making AML regulations effective is massive fines -- fines so large that they genuinely affect quarterly earnings and stock prices. The same could be done with corporate computer security regulations.
Regulations should not adopt a private company's baseline security standard; we should lean on the work NIST has already done and standards that already apply to (mostly defense) critical infrastructure.
[0]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
Industrial civilization has been dealing with these kinds of tradeoffs for what, a couple hundred years now? Regulations seem to be the best option out there.
The entire reason the pipeline hack is such a noteworthy event is that (and I truly believe this), someone was dumb enough to take a job bigger than their head. I don't think a nation state would have burned that opportunity by signaling their technical capability that way.
Funnily enough, the pipeline hack and ransom wouldn't even be feasible without the advent of cryptocurrencies making the AML bypass feasible. As much as I despise those regulations in particular, I cannot argue with their efficacy.
It’s also easy to assume that everyone is incompetent. That doesn’t make it true. Like any hostile situation, a defensive position can always be overcome, you have to have an active offense as well.
Sure, given enough time and motivation anyone can probably break into anything, but that isn't an excuse to let the password for the FTP server that pushes out updates be 'password123'.
Here's the problem companies have absolutely no incentive to care about Security. Several years back some hackers stole a bunch of my information from Experian. You know what I got out of it, a free $10 subscription to their identity service, along with lifelong worry of wondering if someone has opened an account in my name and racked up a ton of debt that I'll be held responsible for.
You know what Experian got, nothing, a slap on the wrist and now their stock is in the same place it was before.
I am doing my Masters in Information Assurance and Cybersecurity right now, and the whole mindset of all of my classes is "you're going to be pwned eventually so figure out how to move the risk to some other poor sucker to take the blame when it happens." pisses me off so much. The entire industry basically uses this as an excuse to avoid responsibility and just make sure they aren't the ones held responsible when the manure hits the rotary oscillator, and that bugs me to no end.
At the end of the day there are real people who are getting screwed and hurt by this, while the execs and security "consultants" spend their time trying to figure out how to make sure that when sh* hits the fan they can't be sued, and d** the customer and their well-being we've got to figure out how to make sure we keep the law away.
EDIT: Clarity and formatting
In a lot of cases the execs of these companies will continue to collect a large bonus, despite the fact that they utterly failed their customers.
Backups, and strict security, might be important? Put security right up their as important as their rediculious salaries.
Victim blaming is a framing that makes it sound like it's about moral and ethics. But it's about practicality. There is a causal chain leading to a bad outcome and we simply break the weakest link. Sometimes it's easier to lock up the treasure and sometimes it's easier to lock up all the thieves.
Consider the case of computer security. Locking up all the thieves is super duper hard, because they are located in places like Russia and China that wont cooperate with law enforcement.
Oh, they do. With their local ones. Those thieves can operate with impunity as long as they don't hit their fellow countrymen.
The victims of these breaches are the end users. Companies are the beneficiaries of not having to pay for and especially not having to inconvenience themselves with much more secure systems.
That said, it's true you can't ask for 100% security. You can instead set standards. You can especially set standards of security for any enterprise that the public dependents on. Since, there are no coherent standards now, just liability isn't useful. And the standards should involve actual topology, what kinds of information is allowed in and out at all.
The thing I'm a bit tired of is IT people in these threads taking every incident that comes along as an opportunity to elevate their pet cause. These more serious incidents have more in common with mafia extortion rackets than computer security.
I'm in the improve the security camp. I think security can be improved if we impose good standards (meaning enforce inconvenient things like no backdoor updating apps, no critical infrastructure connected to the web).
The reason "treating this like terrorism" is useless is that there's always another hacker. It's hard but not that hard and anything doable today will be automatable tomorrow.
If the hack comes from a jurisdiction without extradition, how will you solve that? How foea a country know they are not allowing their citizens to be harrassed with trumped up charges? What if definition of hacking differs in two countries?
It is not just Russia and China, Denmans and Uk have refused to extradite to the US becausw pf concerns over inhumane treatment.
https://www.theguardian.com/world/2019/may/10/dutch-court-bl...
Note you are misquoting me: my comment: *"..."treating this like terrorism" is useless"
The right sort of the law enforcement action might be useful. But "treating this like terrorism" is just escalating penalties, threats and so-forth, which doesn't make sense for a very conventional property crime.
These standards (and PCI-DSS, and ISO, and NIST (and this one is by far the best)) have plenty of blah blah that never gets implemented. They rely on some magical risk assessment exercices with a nice risk grid that gives you answers.
The reality is that the top 5-10-whatever risks are very simple to assess and very difficult to address. Unfortunately such concerns do not exist for the writes of standards.
I have been doing information security for 25 years in huge companies. The more relevant the risk is, the more painful it is to implement.
Even the ones such as "awareness" that theoretically should be useful assume that people care or think. I get emails from people who went though 10 awareness sessions who wonder why someone wants to enlarge their penis. And yes, the awareness sessions wera like in the ads: short, to the point, entertaining, relevant, magical.
So now imagine rising a risk that endangers the key legacy system that cannot be isolated.
running power plants is expensive, if companies in competition don't have to run their own power plants then the ones that do will have higher costs and will have trouble competing
Obviously you're correct because impossible is a tall order, but it's possible to get close assuming the aspiring intruders don't have dynamite or artillery[1].
Negligence.
Of course there are always 0days. There are always sophisticated attacks. There is always human error.
Then there are people in leadership positions being given accurate information about basic security problems and possible outcomes over long periods of time flatly refusing to make security a priority or spend any time fixing dangerous situations.
Many of these ransom situations aren't the result of targeted attacks, but "hey we have this exploit and ransom kit, let's scan the entire Internet and see if we get anything".
Or the ever popular (ok maybe not so much any more) unsecured elasticsearch server on the public internet. I'm sorry but if you put your production data on a public IP on a standard port with zero security, it is positively your fault when your data gets stolen. (not much to do with ransom, but an example).
There is a difference between being the victim of a sophisticated attack and being the victim of your own negligence (and a lot of grey area in between).
Both are truthful and full of good will.
What you're describing isn't (shouldn't be) the end of discussion. The trick is to get management to explicitly acknowledge the liabilities.
And then others say: " if we do that, we will have to redesign too much of the airligher" i.em break production.
Youve got to have your priorities straight
If this is a real plane then there are consequences for the company and people (jail). Suddenly it makes sense to fix things.
The software industry is in the former case - new code being diarrhea-ed down without any consequences if it is hacked.
Why? Many of the companies who got hacked had massive IT issues of their own fault, the most common being:
- full access for everything across the whole network, no subnetting with strict firewalls that limits the scope of an intrusion
- outdated software/firmware stacks leading to avenues for compromise
- no/ineffective/outdated virus scanners
- no meaningful backup infrastructure and regular testing if said infrastructure is already working
- lack of 2FA on administrative credentials
- lack of monitoring on central file servers to detect if a compromised machine is encrypting the file server's contents piece by piece
> It's physically impossible to build a house that can't be broken in to
Indeed, but a burglary insurance will likely refuse service or jack up rates if you don't lock your door or not have an alarm system installed.
I really, really hate reasoning by metaphor, but you do lock your doors, right?
Which is exactly why you don’t store your savings in your sock drawer, you put it in the bank.
Companies not taking appropriate backups is akin to keeping all of your money in a dish by the front door. Sure your house may never get broken into but nobody is going to have sympathy for you if it does.
Making it a criminal offence to pay a ransom would eventually stop criminals ransoming the data they take to the company they took it from, but it wouldn't stop attacks and data breaches if there's some other way to profit. For example, attackers could sell the databases they steal. Or they could ransom individual's data directly to the individual. Or they short the stock of the company and then release the stolen database publicly to make the share price fall.
It's important not to over-simplify the problem. There is no single, simple solution as long as there are many ways to profit from data thefts.
You're listing a bunch of things that are almost assuredly already happening. If a company was dumb enough to keep social security numbers unencrypted in a database or spreadsheet, that data is going onto the dark web whether they paid a ransom or not.
It's a LOT harder to find a buyer of proprietary data that will likely put the buyer in prison for a long time, than it is to get a ransom from one individual trying to keep the whole thing quiet. Once you advertise "I have Apple's top secret next gen laptop details!!" - when someone releases a strikingly similar laptop, or "leaks" the details on an Apple focused fansite, the feds will be all over them.
Of course you can "break into" a typical computer system by gaining physical access to it, for example by breaking into the house that it's in and unscrewing the computer's case; but that's only metaphorically connected to what's going on here, which is that criminals are sending data over the internet to the computer systems in question. The software the owners previously installed on those systems then responds to that data by giving the criminals complete control over the system, as long as they care to maintain it, or unless the system is destroyed. This is dumb.
Writing software that does not behave in this fashion is not only physically possible; it's actually the majority of software. Even in typical software, there is only one deployed exploitable security hole per thousand lines of code or so, and, until only about 25 years ago, it was reliably possible to recover from such an invasion by reinstalling the OS.† The best software, like seL4 or qmail, has orders of magnitude less, though we can quibble about whether the actual number is 0 bugs or 1 bug.‡
The problem is that our systems are architected so that even one exploitable bug anywhere in hundreds of millions of lines of code enables total and irreversible subversion of the system; our system complexity is growing much faster than existing code is getting audited and fixed; much of the code is not even open to auditing; and the people with the power to fix it have no incentive to do so, instead spreading pernicious misinformation claiming that usability and security are unavoidably in conflict (a concept obviously absurd to anyone who has had to use an OS without memory protection) and bulletproof security is impossible anyway. So, at any given time, there are somewhere between thousands and hundreds of thousands of exploitable vulnerabilities in our systems, any one of which is sufficient to enable the implantation of a persistent backdoor that cannot be reliably detected or removed.
The solution to this has been known since the 01970s. At the systems design level, minimize the complexity of the trusted computing base (the hardware and software whose integrity every program in the system relies on) in complexity, audit it rigorously, and freeze it. At the hardware level, provide an easy incorruptible way to restore a known safe state. At the social level, ensure that the people who rely on the integrity of the computer system have the authority to audit it and fix any problems they find, and the technical competence either to do this themselves or to delegate these tasks to people who are competent to do it, rather than to charlatans. At the user-interface design level, ensure that users can understand the information they need to assess the risks they are taking in relying on any given piece of information, and decouple the system to eliminate their incentives to take risks, for example with memory protection and petnames. We know a lot more about how to achieve these things than we did 45 years ago, and in some ways we have enormously more resources. We have seL4, Bitcoin, ssh, Monte, elliptic-curve cryptography, BLAKE3, NaCl, LUKS, decades of SOUPS proceedings, RISC-V, yosys, and 16-MIPS microcontrollers§ that cost 3¢.
But that future is not merely "not widely distributed"—it has become inaccessible except in isolated cases like Trezor, as economic incentives have driven our hardware and software down a path of boundlessly ballooning complexity and diminishing alternatives, while proprietary software licensing eliminates any possibility of assessing and controlling the risks. Meanwhile, the shallow pop culture of computing reduced users from creators to mere customers, and then "eyeballs", while conflating hacking—the only way out of this mess—with computer invasion.
So, I fully expect that if I live long enough to need a pacemaker, I won't be allowed to secure it against ransomware, which will be rampant at that point.
It doesn't have to be this way. This can all be made better.
Ready? Begin.
______
† In fact, shortly before that, on most PCs you could recover from any kind of system corruption just by taking the floppy disk out, resetting the system, and inserting a new, uncorrupted floppy disk. Better hope that one's not stoned too...
‡ You might argue that the possibility that there's an undetected security bug in seL4 means that complete computer security, even against carefully crafted data sent over the internet rather than some dude running off with your cellphone while it's unlocked, is still impossible. But in fact I think there's a very real difference in kind between the possibility that I might currently have presymptomatic covid, and the certainty that I have a small amount of covid. Systems like qmail are analogous to the first case, because they might be secure or might contain an undiagnosed flaw; systems like Linux and Chrome are analogous to the second case, because they are certain to contain a small but fatal fraction of flaws, which are inexorably multiplying.
§ Unfortunately the whole line of Padauk microcontrollers is out of stock this week at LCSC.
A modern jet airliner uses about 1,500,000 bolts and screws. Imagine if they were designed so that a failure of any one of them could cause a catastrophic failure of the entire aircraft. Then imagine if people were defending it by saying “This is a metallurgy problem. There will always be the occasional improperly cast bolt or over tightened screw. To expect that to never happen is victim blaming”.
(Yes, fuzzy metaphorical reasoning is what misled us in the first place, but the problem isn't that the "this is victim blaming, you can always break into a house" people are using fuzzy metaphorical reasoning; it's that, like physics crackpots trying to build the Grand Unified Theory out of styrofoam models, they are only using fuzzy metaphorical reasoning.)
Specially if an entity with a nation's resources is trying to get in.
That's the case with a lot of these companies who:
a) Have pitiful/non-existent bug bounty programs (or even worst, prosecutes white hat hackers who raise issues)
b) Prioritizing exec bonuses instead of investing in InfoSec
Sure, but as much as we might roll our eyes at the state of corporate security, this is a disingenuous metaphor.
It's neglect and incompetence. It's repeatedly forgetting to lock the door even after every neighbor has been robbed.
(One exception to my solution is poor government and public institutions who run awful software. Not sure what we can do)
If I have a habit of burning down my house by being sloppy with safety, my rates will go up. There should be something similar
Let us take the case with Equifax mismanaging their servers, with running obsolete Java packages resulting in identity theft for millions of Americans.
Credit score is controlled by 3 companies. Credit score determines mortgage rate and hence it literally controls if a US resident can afford to buy a house or get a job (in some states). Don’t the companies need to take some responsibility?
Similarly dozens of companies leaving Elastic search installs and MySQL open to the internet. I mean.. how sloppy can one get?
Fine, be sloppy, just pay $$$$$ to your insurance company. That $$ amount will indirectly decide whether we go to war with Russia or pay software engineers.
Not related to the subject, but wow I wonder how alarming it is that "war with Russia" meme is having a strong comeback, as it's being casually brought up in online discussions about software.
They elected one of ours, we can unelect one of theirs.
Things are actually getting better in some ways. Modern OSs with automatic updates are more secure than OSs have ever been. The days where clicking a link on an email or plugging in a USB could infect your computer are almost gone outside of rare zerodays which get patched for everyone pretty quick.
Things are getting even better with hypervisors, SELinux and secure languages rolling in. Significant portions of Android and in the future linux, will and are being rewritten in rust which wipes out entire classes of the worst bugs we are being faced with.
The problem is that the attackers are also getting more sophisticated and the targets are becoming more valuable with more and more getting put online.
It doesn’t feel like even Google are winning