This is ridiculous and really only happens because the cost of securing your customer (or citizen) data is higher than the cost of losing control of it. If the cost of losing data to hacks was, say three times higher than the cost estimated to secure it, the problem would become much less common very quickly.
As it is, states and corporations externalize the costs of hacks to the victims of their incompetence. They have no reason to take opsec seriously because they aren't held liable in even the most egrigious cases. Data should be a liability.
This is the crux of it, methinks. "Data is the new oil" has been a common refrain and as long as the externalities of poor security posture hygiene can be completely outsourced while these companies make mountains of cash by monetizing your every scrap of behavior, attention and information, this will only get worse as every entity seeks to hoard more information on you.
Keeping more data than absolutely necessary for critical business operations should be an existential threat for any entity. Those businesses built on this data ought to take Fort Knox level pains to secure it. Anything short of that and we will continue to exist in a society of deteriorating trust and social contract.
A framing I often use is, "Data is like holding uranium". It can be incredibly valuable, but also very dangerous. You should be very sure that the data you're holding is worth the cost of safely protecting it (a high cost), and if it is not, get rid of it.
Stripe is a good mental model here, I don't want a person's credit card data, I want to charge them for my product. I love storing a Stripe customer ID, if a hacker were to grab that table, I wouldn't lose (a lot) of sleep, they couldn't do much with it. If that table held credit card data...I would.
That farms out a lot of responsibility to Stripe, but for a side project, I don't have the time necessary to do as good of a job at it relative to Stripe.
I think GDPR was a great step in this direction, even with the annoying cookies popups. There's some states in the US with similar laws basically saying "it's legal for you to collect this data, but if you do you need to build systems for people to request all the data tied to them and for it to be deleted". Hopefully the next step would be to make data sharing opt-in, while it's somewhat limited it is really nice that iOS makes apps request access to different data.
I'm really curious how effective these are in practice if someone got logs or backups, but it at least gives people a path to know what data is there remove the active copies
We also need changes so that posession of identifying information is not sufficient to establish identity. That sounds like a tall order but clearly this information is leaking all over the place and just because someone has my identifying numbers and date of birth and mother's maiden name and signature and fingerprints and whatever else, should not be adequate to gain access to bank accounts or execute contracts and other legal agreements.
The hard part of this isn't that we don't know how to do it, it's that people don't like the consequences of it.
Your bank can give you a bank card with cryptographic keys in it and then you need the card to make a transaction. But then if you lose the card...
At which point we fall back to birth certificates and things because there's nothing else available. The alternative would be that if you lose your bank card, you lose your money. Which could be mitigated by e.g. having backup cards that you keep at home in a safe, but some people would lose those too, and what then?
Why would losing your bank card mean losing your money? The bank card would be there to establish identity when performing a transaction. Going to a branch in person with government-issued photo id would be the way to establish identity when generating a bank card. It’s a pain to do, but it only needs to be done for a new account or to revoke/replace a card.
By analogy, the cryptographic key on the bank card is a cross between a session token and a private key. Like a private key, it is never directly exposed for verification. Like a session token, it can be replaced.
At least walking into a bank with a fake birth certificate and other forged identty is not a form of impersonation that can be done remotely and at scale.
I think there's generally considered to be three classes of authentication methods
- something you know, like a password
- something you have, like an RFID card
- something you "are", like a fingerprint
You can add multiple of these and choose from different categories to add security, but each time you do it also gets less convenient. You could require a birth certificate, DNA test, and social security number for any access to a bank account, but then it wouldn't really work as a checking or savings account, and if you lose your birth certificate you're locked out of your account.
Definitely worth considering the other side - when you need to access the account how much inconvenience and delay are you willing to put up with before you can? For a checking account it seems like people usually just want a single one of them - the debit card, account login, or face/fingerprint to authenticate
The common usage of this phrase isn't too inaccurate. Keep in mind what oil does to the environment, not just during spills but even in normal refining!
When oil is refined, it feeds energy consumption, which can have both positive and negative effects. When data is refined, it feeds AI, which can have both positive and negative effects.
When oil spills, it causes toxic damage to the environment. When data spills, it causes damage to society's individuals and the firms that should have kept the data secure.
It's not a perfect analogy, but there are some similarities.
Would be good to get a value on this liability onto a company’s balance sheet. This could be done as a value of risk, or a cost of insuring against data exposure (should be govt mandated to have insurance). If Lloyds can insure against weather and piracy then someone should be able to underwrite insurance against data breaches.
For government IT in particular, the cost of security is basically infinite because they aren't organizationally mature enough to do anything right. There's no way to make the cost of being hacked infinite; no court or legislature is going to order the DMV to be disbanded.
> There's no way to make the cost of being hacked infinite; no court or legislature is going to order the DMV to be disbanded
Disbanding the DMV doesn’t make the cost to any actor infinite (“DMV” is an abstraction, and state agencies are routinely created amd destroyed, sometimes as political damage control due to IT scandals [0], but that’s not an infinite cost on anyone.)
In 1995 the California State Police were disbanded and their role was given to the California Highway Patrol.
The part of the DMV that performs driver testing isn't the part that loses all your data. It wouldn't be impossible to disband their IT department and give the role to some other government agency.
They could also just, you know, stop collecting it. Print your height and hair color etc. on your driver's license and don't store it anywhere else. Instead store a hash of it at the DMV with the salt stored on the license itself, so you can revalidate the license without being able to reconstitute it.
The cost benefit calculation also includes the odds of being hacked. Enormous numbers of organizations are at risk but most survive by security by obscurity. Most are content to hope to remain obscure.
Especially since the cost of actual security is very high. You have to build it into every aspect of the system. It makes development cost an order of magnitude more and constrains usability... and you'll still never really be certain
When you take employees into account the cost becomes almost insurmountable. Keeping bank style security means tightly limiting access, making even simple operations more work.
That's not an excuse. That's a warning. We are at grave risk, and we need to completely reconsider how almost every piece of software is written. Competence is hard and expensive.
Exactly. Mandate financial compensation for any and all value derived from data that an individual creates, whether they opted in or not.
If YC ran banner ads and my comment is viewed on the same page as an ad, then I should receive some significant percentage of that ad revenue. If an ad is targeted to a customer on IG through an ad campaign, based on the user's data, then the user should get a significant percentage of that ad.
On Qubes OS even a zero-day would likely not be sufficient. It relies on hardware virtualization and runs everything in VMs. My daily driver, can't recommend it enough.
I can confidently tell you that your understanding of security mitigations is flawed. And I say that based on experience not just a baseless opinion. Silver bullets in security don't exist.
Let's every moveit instance was run in a container in a vm and in a dmz (actually moveit transfer is usually deployed in a dmz, isolated from everything else). But the entire purpose of the software is to contain all these important files and expose them to authorized parties, basically a file server (even has sftp!). The threat actors in this case didn't even bother compromising the OS, they just got a session id as a result of abusing sqli and .net deserialization flaw and logged into the webui and downloaded the files. At no point could a vm have stopped any of this.
I said your undersranding is flawed because you mindset is solution centric not data centric. If all an attacker cares about is access to your gmail, a qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies, defeating any yubikey 2fa you may have.
You are too confident. First, Qubes does not use VMware. It uses Xen, which has way less vulnerabilities, most of which do not affect Qubes [0]. And none of them have led to arbitrary code execution in host since 2006, except maybe for VMs with PCI passthrough [1].
Also, Qubes does not trust the hardware emulation [2]. It keeps the trusted computing base as small as possible. Of course, the covert-channel attacks are still possible [3], but they are much weaker and can be mitigated through isolation. Qubes does not implement an ordinary copy-paste functionality; it's implementation is much more secure, see [4,5].
Hardware-virtualized VMs without any devices attached are extremely hard to escape from or access for other VMs. I am not aware of any successful attempts in the last >10 years.
> qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies
This is wrong, because clicking on a link in my email would open a broswer in a dedicated, disposable VM. Also any attachment would also open in a disposable VM.
Having said that, you are probably right that in this case Qubes itself would not help as the whole database had to be available online.
I'll just say that the entire point of zero-day is that you are not aware of it now and that zero-click attacks exist and also that while your selection of a product based on historical performance under scrutiny is valid, you cannot use that as evidence to claim an attack is not possible.
And again, you miss the whole point of zero-day, it is an unknown. You can create an attacker-hostile environment but you cannot make guarantees or claim a solution is best practice against an unknown/undefined.
As far as I am aware for example, spectre/meltdown or *-hammer attacks could have been used against your disposable vm to read your email vm's memory. There are also hardware attacks against radio controllers/chips that could be used to wirelessly dump memory without your interaction.
You know, I was just telling someone how I thought those scenes in movies where the hacker guy types really fast and hacks everything were silly when I started working in security. Now, I know that if he is just the guy buying/trading exploits and spent a lot of time automating stuff and setting up infra,it is indeed possible to make it all look so easy (but still, some movies/shows take it too far). Especiallu in government work, the guys using the tools are rarely the guys that develop them or maintain their infra. The guys who develop access might also be different from the guys who action objectives or work on exfil or shell management.
I do know what zero-days are. And I do not solely use the historical performance as evidence for strong security.
Did you ever think that such a good performance that Xen and Qubes have is not a mere coincidence? What if I tell you that it is not just a pure luck? It just can't be luck statistically: in the Linux kernel, serious vulnerabilities are found all the time, whereas here they're extremely rare.
Let me tell you that it is actually a result of a good architecture. You know, in Xen, the trusted computing base, i.e., the code responsible for isolation and security is really small: it's of the order of 100k lines of code. In Linux it's millions of lines. Every code has bugs, it's unavoidable, but you simply can't have a similar number of bugs in 100k lines as in millions of lines. There are no "guarantees" here, just pure statistics.
In addition, Xen is very popular among big companies, so its code is constantly checked for bugs by the best people in the field. And zero-days in it are so expensive that you would not waste one on leaking personal data of people for no reason. Security is not about guarantees, it's about probabilities. And they are very small in Qubes, if you are not a big target. Even if you are, they are smaller than for any other system, thanks to the security-oriented design and reliance on compartmentalization.
Yes, Qubes is vulnerable to Spectre, Meltdown, *-hammer attacks. But it never attempted to protect the user against the hardware it runs on. It is physically impossible. Also, hardware attacks like these are exception, not the rule. And even they usually don't lead to VM escapes.
> Government IT is outsourced at prices that could pay top salaries
Mostly, its not; a lot is not outsourced, and a lot that is is outsourced on personal services contracts at rates that even if there was no vendor overhead wouldn’t pay for a top-flight pay and benefits package.
As it is, states and corporations externalize the costs of hacks to the victims of their incompetence. They have no reason to take opsec seriously because they aren't held liable in even the most egrigious cases. Data should be a liability.