If you're using AWS, where else would you put it? Fire up an EC2 instance and obscurely store it in /var/www/?
These days S3 buckets start off private, and the AWS console warns you "hey, the data in this bucket is publicly accessible, are you sure?" Irresponsibility is irresponsibility, no matter the system being used. An SFTP server can be configured with PermitRootLogin yes and PermitEmptyPasswords yes so at some point it's not the software that's the issue.
Amazon allows S3 to be unsecured after multiple breaches. Simply the existence of the option is a security issue.
PS: It's a basic question of convenience vs security. If you allow people to lower security settings, they will. However, if Amazon onky allowed the unsecured option to be temporary say 24 hours then it would be less convenient to leave things open.
I used to agree with you, back when S3 defaulted to public or at the very least made public a very easy checkbox.
These days it defaults to private and you have to click many warnings and unhide options to even expose the public options.
That said, I don't know that many organizations practice good hygiene about which buckets they use. Like they might just use 'the one bucket that we have as a company' rather than separating their uses into many smaller buckets that are appropriately access controlled.
I'm not sure about S3, but I use Google Cloud Storage to host my websites and large file downloads. For that to work, "allUsers" has to have the "Cloud Storage Viewer" permission.
Would it be possible for that to work without allowing GCS and S3 buckets to be public?
Looks like the developer in question took action to correct the situation the same day they became aware of it. That at least is good.
If the data was never secured in the first place can you call it a breach?
They found this, great, was there any indication it was accessed directly before that? Is that something that can even be investigated?
You find a door to the data unlocked. You open the door. Can you tell if someone else had opened the door before you? Did you prevent 845 GB of data being found by a black hat or did you find that data because of a black hat?
As a user concerned with my own privacy, I don't care about the color of the hat. If it's for my eyes only and someone else looks at it, it's a breach of privacy. If that's due to the incompetence of someone I've entrusted my private information to, it's a breach of trust. If that's someone with a legal responsibility not to share the information, it reflects very poorly on them, and this level of negligence should in my opinion be considered criminal.
It’s a good practice for good faith security researchers to create their own account so that they can test the system without viewing an innocent users data. This is especially important for systems such as dating apps, which obviously contain extremely sensitive data.
> If the data was never secured in the first place can you call it a breach?
Yes. It's a "breach" even if just a security researcher found it. It's sometimes even a breach even if only an employee found it (depending on the specific role of the employee and controls on the data).
> They found this, great, was there any indication it was accessed directly before that? Is that something that can even be investigated?
You can be found "not guilty" by a jury, but that doesn't mean you are innocent. Sometimes there just isn't enough evidence of the crime.
We should care more about whether a crime happened than we care about whether we can prove the crime. In cybersecurity, not having enough logging should be something along the line of negligence.
> Did you prevent 845 GB of data being found by a black hat or did you find that data because of a black hat?
I've seen it both ways. Some employees are diligent and go out of their way to investigate proactively. Sometimes an employee only investigates if there is a sufficiently suspicious finding. I've seen instances where the only hint that a user breached a database was a SQL query error that got logged in an application such that the app as designed couldn't generate that query.
Thank you and thanks to the other replies. I don't often have a comment that is so full of questions and speculative thinking as this one was.
Negligence makes sense in this case. Just thinking out loud now. If that were made illegal/legal would software engineers need to be state/federally certified having a license to code? Would they possibly need to carry insurance like doctors do? Curious possibilities.
> If that were made illegal/legal would software engineers need to be state/federally certified having a license to code?
Not sure. I've certainly entertained that possibility, trying to think about the trade-offs.
In essence, programming is sometimes low level machine language or high level scripting. I don't think writing formulas in Excel (or any other spreadsheet) should be limited to just certified, licensed, and bonded Software Engineers.
> Would they possibly need to carry insurance like doctors do?
Software in the USA is not currently considered a "product", so it has no legal requirement to carry warranty guarantees. If that legal requirement is ever changed, or if a programmer works on a product which can cause loss of life either employer indemnification in the engineer's employment contract or a professional insurance policy should be considered. That said, of all programmers, this seems like a small subset.
> "the researchers warn that a motivated hacker could have used the photos and other miscellaneous information available to identify many users"
FaceBook has probably done it as a part of their regular business of stalking everyone on the planet. Isn't that more alarming than what "a motivated hacker" might be able to do?
Exposing sensitive information this stupidly should be criminally negligent. People use these platforms under an implicit trust arrangement.
I suspect if I made myself look like a successful trader and told people I was a trader then they would expect I'm a trader and I can be invested with. When I lose them money I'd be charged with some serious crimes for pretending to be a trader.
With increased regulation, comes an increased barrier to entry.
I'm absolutely for protecting privacy, and I hate that companies like Facebook and Google peddle our personal details for profit. I worry that unless we are careful, however, that we'll wind up creating barriers to bootstrapping. I don't want EU-style cookie banners, required GDPR data export plumbing
I want privacy. But I also want an escape trajectory and ability to do thins on my own as a sole proprietorship or startup. I don't want to have to work at one of the big firms because they are the only ones that can pay for lawyers and auditing.
Maybe we scale regulation with the size of a business? That seems fairer than prohibiting small startups from getting off the ground.
Maybe barriers for personal information isn’t a bad thing? In order to store personal information, you should at least be competent enough to keep it safe. I don’t think having some kind of barrier is too much to ask for a company of any size to have to reach in order to show that they are competent to securely store the data.
I’m not saying the barrier should be great, but something (anything!) that makes keeping personal data secure a priority for a company is a good thing.
How many instances of this kind of lax security have we seen? Perhaps if there were a few extra hoops, then we’d not have seen as many.
What if those barriers kicked in at some number, e.g. 5,000 users. Once you are dealing with a big enough crowd, you better be able to protect that data, no matter who you are (imo).
I think that is way more sensible. It gives people the time to experiment and understand growth and the nature of their market. It also gives room to hobbyists, which is an important demographic of creatives that shouldn't be punished by regulation.
My experience with S3 buckets was that it was super painful and annoying to make the images publicly visible. So these people had to go out of their way to make this publicly accessible.
We need a certification org like ISO to look into the practices of any data storing web service. Until recently we neglected it because the outsiders thought that it is straightforward to do so, but time after time we see ridiculous mistakes exposing sensitive data & passwords. This has to end yesterday. It is fine to fall victim of an elaborate hacking attack and lose customer data, it is not fine to not even follow a bare minimum of practices to protect their data.
I would like to see a Professional Personal Data Engineer license similar to becoming a PE in other engineering fields that would specifically qualify an engineer to build systems that contain PII.
Then if you have a data breach you can investigate and potentially pull the license and assign personal liability similar to if a bridge fell over.
I disagree. The GDPR and CCPA only have teeth against corporations. You will lose some money but nobody is going to jail over a GDPR violation. The investors will be sad but they aren't even really responsible, the employees who built the data-systems are.
At the same time, you can ruin someone's life through a data-breach. Imagine you are on one of these dating apps and your boss takes a gander at the leaks and fires you because of your private life. Or worse, some bigots show up at your house and burn a cross in your yard.
So how do we fix a situation where the person responsible for securing your data has no skin in the game? Put their head on the block. Other engineering disciplines hold the PE liable for mistakes because they recognize the stakes involved. I think that assigning liability is absolutely appropriate for building systems with PII.
Product certifications would be great too, although that would be done by a PE so you'd kill two birds with one stone by licensing Data Engineers.
How do you enforce that when the service is provided by a company in another country?
GDPR solves that because if you want to do business with European citizens you must comply with it no matter where you are. GDPR is not only about the fines, it stablishes protocols to communicate breaches, makes somebody responsible for it (the DPO) and makes distinctions between the different types of data and the requirements to handle it.
As I see it, Licensed Data Engineers won't make companies more careful with our data, since all they need to do is to sue them and fire them when there is a problem. We need laws that make data hard to use, so companies will only ask for what they really need, will use the data with a purpose and will store it only while it's useful.
Software is more similar to a car than it is to a bridge. Companies build and sell them all over the world. Cars are certified at each country as needed, but it doesn't matter who is building them, as long as they meet all the requirements. Software should be similar.
> So how do we fix a situation where the person responsible for securing your data has no skin in the game? Put their head on the block.
This implies there is a perfect scenario of security, but even the best security experts can still have breaches, it's unfair to punish people acting in good faith.
I've seen this comparison a lot and on some level I agree with the idea, but I don't think the comparison is actually that applicable.
This big difference is that this isn't just "the bridge fell over". In the case of a cyber attack, it's more like "a terrorist detonated a bomb on the bridge and blew it up". And in such a case, I think it would be a pretty big stretch to blame the engineer who designed the bridge.
"Somone crashed into the bridge support pillar in the median and the bridge fell down" sounds like the fault of the engineer.
"A foreign nation sent a fighter jet" doesn't.
I don't have any ideas on how to have a reasonable standard of "this is the sort of attack you shouldn't fall to," though. How do you keep this from being years outdated very quickly?
I agree that if a nation-state breaks into your system with a 0-day exploit, that's very very different than leaving your S3 bucket set to public.
I'm not suggesting that every data breach results in jail time, just like not every bridge collapse results in jail time either. There should be an investigation that determines the cause and whether that cause was foreseeable. The other engineering disciplines seem to have it adequately figured out, software isn't that different. I also don't think you should be facing life or anything, maybe something as small as a fine would work.
Ultimately the data breaches will continue to happen as long as the personal incentives of the people building data systems aren't aligned with the users, and the GDPR does nothing to address that.
Data privacy is an engineering problem - and currently there aren't any really good open-source tools to 'solve' data privacy - it's really up to the application developer to make sure they don't mess up. If the organisations is sufficiently large there is a CISO to ensure the correct processes are in place so that this sort of thing does not happen.
I think in an ideal world data privacy should be addressed by open-source software enabling software developers to easily express data privacy as code and version control it and review it much like we do with our infrastructure.
There is an product [0] which is currently in Alpha aimed at doing this. (Full disclosure I am one of the core devs) We don't support S3 buckets yet - but it's on the roadmap.
> aren't any really good open-source tools to 'solve' data privacy
The most exciting project I've found so far, who are working on this, is a project called Ceptr, who have open sourced a pattern called Holographic chain. It uses validation rules and open app logic to create completely distributed apps. Each user holds onto their own data. It is often called Protocol Cooperativism (close to Platform Cooperativism) You can find more about it in this medium post by one of the core contributors:
"It's a framework for writing fully distributed peer-to-peer applications. It is like a decentralized Ruby on Rails, a toolkit that produces stand-alone programs but for serverless high-profile applications." [1]
It's toothless, though. Due to the nature of security moving so quickly, any certification or audit standard that actually prescribes specific security controls is inherently going to take so long to get approved by the standards organization that by the time it gets approved, it's already outdated.
The "fix" that has been attempted for this is to try and write security standards that are high level (read: vague) so that they have more "shelf life", but the result of that is that nearly anyone can pass the audit/certification because the requirements are so vague. See: NIST CSF, ISO 27001, HIPAA...
I've worked on a couple of these NIST or ISO 27001 assessments and I would bet that even this company would meet some standard of "have access control". The audit/certification often won't care that the access control you have is "the bucket allows public access", it's still an access control!
For that matter, it's entirely possible they had security testing "controls" too. But again, the audit/certification probably won't even care that the security testing team is one guy who sometimes tests the app login every couple of weeks. "Oh, Jim tested to make sure that the app only allows 3 password attempts? Security Testing: Check!"
Don't get me wrong, the ISO/NIST frameworks are absolutely a good thing. For a lot of my work, they've been my bible. They are fantastic guides to help companies who want to be more secure focus their efforts and understand how they measure up. But that's only for companies that really want to be more secure. For all of the companies out there that just want to check a checkbox or pass an audit, these frameworks are way way too easy to give a "false positive".
The thing that ISO helps with is not so much requiring "must have access control", but much more the fact that it requires having specific people responsible for security and having processes to monitor and continuously improve the security practices.
It's often frowned upon by engineers, because it's much more about processes and management structure than anything technical. But I've been involved in a few organizations that went from "technically good but unmanaged" to ISO certified. And I'm quite sure all of them got more secure and did more in terms of continuous improvement after certification.
the computer and software is what it is (specifically: non-existent entry barrier, possibility of exponential customer base growth) also because there is little to no regulation about operating practices.
i'm not saying this is good or bad just... keep that in mind. careful what you wish for.
Don't take ISO. Let the market sort it out, after the governement provides the right incentives, and maybe provides some minimal baseline.
For example, the gov gives huge fines, and pierces the corporate veil.
Then insurers insure the risks for a data breach. They calculate the expensive premium, and lower it if you do what the consider the right thing, e.g. some ISO guidelines.
Now incentives are aligned: Corporations secure their infra to avoid expensive premiums.
Insurers give correct security guidance. If they overbear, they lose customers. If they are too lax, they pay huge insurance claims.
The governement's job is to make sure nobody is asleep at thehelm. After a while, make the insurance mandatory.
But that is how it already works, Equifax was fined $700,000,000 - very little of which goes to the people actually affected, and EFX is still operating as strong as ever.
That's why the government should punish more harshly. They should be sending the message: Stop this behaviour. The Equifax message was more like: Carry on, it's worth the risk.
Yeah, that's exactly what we need. Another PCI-DSS certification crap. What people don't understand is that their data is not private unless it's e2e encrypted. Most of the financial apps/websites have been bandly hacked and they have all the certificates in the world.
I hate to agree because it means more sclerotic regulation that gets ossified and at some point forgets the main aim it was put in place for... but we see that without that burdensome oversight people aren’t doing the right thing.
Maybe there shouldn't be publicly accessible AWS buckets. Or, if you create one, you have to specify some public domain type license to make it clear that's your intent.
agree, while AWS added a bunch of tooling around this, is it still entirely to easy to accidental or lazily make a bucket public. I honestly think they should consider splitting S3 into S3 public and S3 private independent services. Buckets in S3 private cannot be made public unless migrated to S3 public.
I set up a few websites for side projects that use Cloudfront + a public S3 bucket + Lambda for the backend when needed. It's extremely fire and forget web hosting for simple static sites and I think it costs me basically nothing.
How do you enable S3 for my use case (where I am ok with all the assets being public because they are all static JS/HTML/CSS/images) but also prevent breaches like this?
> How do you enable S3 for my use case (where I am ok with all the assets being public because they are all static JS/HTML/CSS/images) but also prevent breaches like this?
Do not put anything you don’t want to be public in your S3 bucket. Also, best practice would be for the bucket to be private but Cloudfront be authorized to access the objects to retrieve from the S3 origin and cache at the edge. Use a separate S3 bucket for sensitive data. Use lifecycle rules to delete objects as soon as feasible so you’re not storing sensitive data for longer than you need to. Ensure that cloudtrail logs and s3 logging is enabled for sensitive buckets, so you have access logs for forensics if you do unintentionally leak objects with sensitive data.
Oh, sorry, yeah I'm aware of these things. I'm trying to square the circle where the parent suggested that maybe there shouldn't be public buckets. (And maybe that's actually true... maybe to serve from them you should be required to figure out Cloudfront.)
Tech shops keep asking for more and more, beneath the ever-widening "full stack" moniker, and we developers do our best to oblige them. But, clearly, critical decisions are being made (or not) by people who are inexperienced yet afraid to ask for help. Maybe it's time to hire more "I-shaped" developers, rather than an org full of shaky generalists.
Would be fascinating to mine it for data about how flirting works linguistically. We've never had a corpus for that before right? Also to confirm/disconfirm those famous OKCupid posts about who wins in the dating game.
I was also intrigued, it seems like you select the specific type of the herpes virus you have, and meet a partner who carries the same disease.
Since these viruses are carried for life I suppose it prevents the fear of spreading it to a partner that doesn’t have it.
There also actually seems to be several sites in the exact same niche which was surprising to me, when searching for the name of the site I got ads for 4 competing sites.
If you own buckets personally or at work and want to scan them from an outsider's perspective, you can use S3Scanner [1]. Disclosure: I wrote it and there's a major re-write coming soon(tm).
71 comments
[ 2.9 ms ] story [ 124 ms ] threadI actually lost the count of this happening.
These days S3 buckets start off private, and the AWS console warns you "hey, the data in this bucket is publicly accessible, are you sure?" Irresponsibility is irresponsibility, no matter the system being used. An SFTP server can be configured with PermitRootLogin yes and PermitEmptyPasswords yes so at some point it's not the software that's the issue.
PS: It's a basic question of convenience vs security. If you allow people to lower security settings, they will. However, if Amazon onky allowed the unsecured option to be temporary say 24 hours then it would be less convenient to leave things open.
These days it defaults to private and you have to click many warnings and unhide options to even expose the public options.
That said, I don't know that many organizations practice good hygiene about which buckets they use. Like they might just use 'the one bucket that we have as a company' rather than separating their uses into many smaller buckets that are appropriately access controlled.
Would it be possible for that to work without allowing GCS and S3 buckets to be public?
If the data was never secured in the first place can you call it a breach?
They found this, great, was there any indication it was accessed directly before that? Is that something that can even be investigated?
You find a door to the data unlocked. You open the door. Can you tell if someone else had opened the door before you? Did you prevent 845 GB of data being found by a black hat or did you find that data because of a black hat?
Yes. It's a "breach" even if just a security researcher found it. It's sometimes even a breach even if only an employee found it (depending on the specific role of the employee and controls on the data).
> They found this, great, was there any indication it was accessed directly before that? Is that something that can even be investigated?
You can be found "not guilty" by a jury, but that doesn't mean you are innocent. Sometimes there just isn't enough evidence of the crime.
We should care more about whether a crime happened than we care about whether we can prove the crime. In cybersecurity, not having enough logging should be something along the line of negligence.
> Did you prevent 845 GB of data being found by a black hat or did you find that data because of a black hat?
I've seen it both ways. Some employees are diligent and go out of their way to investigate proactively. Sometimes an employee only investigates if there is a sufficiently suspicious finding. I've seen instances where the only hint that a user breached a database was a SQL query error that got logged in an application such that the app as designed couldn't generate that query.
Negligence makes sense in this case. Just thinking out loud now. If that were made illegal/legal would software engineers need to be state/federally certified having a license to code? Would they possibly need to carry insurance like doctors do? Curious possibilities.
Not sure. I've certainly entertained that possibility, trying to think about the trade-offs.
In essence, programming is sometimes low level machine language or high level scripting. I don't think writing formulas in Excel (or any other spreadsheet) should be limited to just certified, licensed, and bonded Software Engineers.
> Would they possibly need to carry insurance like doctors do?
Software in the USA is not currently considered a "product", so it has no legal requirement to carry warranty guarantees. If that legal requirement is ever changed, or if a programmer works on a product which can cause loss of life either employer indemnification in the engineer's employment contract or a professional insurance policy should be considered. That said, of all programmers, this seems like a small subset.
FaceBook has probably done it as a part of their regular business of stalking everyone on the planet. Isn't that more alarming than what "a motivated hacker" might be able to do?
I suspect if I made myself look like a successful trader and told people I was a trader then they would expect I'm a trader and I can be invested with. When I lose them money I'd be charged with some serious crimes for pretending to be a trader.
I'm absolutely for protecting privacy, and I hate that companies like Facebook and Google peddle our personal details for profit. I worry that unless we are careful, however, that we'll wind up creating barriers to bootstrapping. I don't want EU-style cookie banners, required GDPR data export plumbing
I want privacy. But I also want an escape trajectory and ability to do thins on my own as a sole proprietorship or startup. I don't want to have to work at one of the big firms because they are the only ones that can pay for lawyers and auditing.
Maybe we scale regulation with the size of a business? That seems fairer than prohibiting small startups from getting off the ground.
I’m not saying the barrier should be great, but something (anything!) that makes keeping personal data secure a priority for a company is a good thing.
How many instances of this kind of lax security have we seen? Perhaps if there were a few extra hoops, then we’d not have seen as many.
AWS S3 has made it significantly easier to restrict bucket access, but those are all (relatively) new changes.
Then if you have a data breach you can investigate and potentially pull the license and assign personal liability similar to if a bridge fell over.
At the same time, you can ruin someone's life through a data-breach. Imagine you are on one of these dating apps and your boss takes a gander at the leaks and fires you because of your private life. Or worse, some bigots show up at your house and burn a cross in your yard.
So how do we fix a situation where the person responsible for securing your data has no skin in the game? Put their head on the block. Other engineering disciplines hold the PE liable for mistakes because they recognize the stakes involved. I think that assigning liability is absolutely appropriate for building systems with PII.
Product certifications would be great too, although that would be done by a PE so you'd kill two birds with one stone by licensing Data Engineers.
GDPR solves that because if you want to do business with European citizens you must comply with it no matter where you are. GDPR is not only about the fines, it stablishes protocols to communicate breaches, makes somebody responsible for it (the DPO) and makes distinctions between the different types of data and the requirements to handle it.
Also, enforcing GDPR is no joke, and we are still learning its consequences (http://www.london-registrars.co.uk/first-prison-sentence-ari...).
As I see it, Licensed Data Engineers won't make companies more careful with our data, since all they need to do is to sue them and fire them when there is a problem. We need laws that make data hard to use, so companies will only ask for what they really need, will use the data with a purpose and will store it only while it's useful.
Software is more similar to a car than it is to a bridge. Companies build and sell them all over the world. Cars are certified at each country as needed, but it doesn't matter who is building them, as long as they meet all the requirements. Software should be similar.
This implies there is a perfect scenario of security, but even the best security experts can still have breaches, it's unfair to punish people acting in good faith.
This big difference is that this isn't just "the bridge fell over". In the case of a cyber attack, it's more like "a terrorist detonated a bomb on the bridge and blew it up". And in such a case, I think it would be a pretty big stretch to blame the engineer who designed the bridge.
"Somone crashed into the bridge support pillar in the median and the bridge fell down" sounds like the fault of the engineer.
"A foreign nation sent a fighter jet" doesn't.
I don't have any ideas on how to have a reasonable standard of "this is the sort of attack you shouldn't fall to," though. How do you keep this from being years outdated very quickly?
I'm not suggesting that every data breach results in jail time, just like not every bridge collapse results in jail time either. There should be an investigation that determines the cause and whether that cause was foreseeable. The other engineering disciplines seem to have it adequately figured out, software isn't that different. I also don't think you should be facing life or anything, maybe something as small as a fine would work.
Ultimately the data breaches will continue to happen as long as the personal incentives of the people building data systems aren't aligned with the users, and the GDPR does nothing to address that.
I think in an ideal world data privacy should be addressed by open-source software enabling software developers to easily express data privacy as code and version control it and review it much like we do with our infrastructure.
There is an product [0] which is currently in Alpha aimed at doing this. (Full disclosure I am one of the core devs) We don't support S3 buckets yet - but it's on the roadmap.
[0] https://github.com/openquery-io/parallax
The most exciting project I've found so far, who are working on this, is a project called Ceptr, who have open sourced a pattern called Holographic chain. It uses validation rules and open app logic to create completely distributed apps. Each user holds onto their own data. It is often called Protocol Cooperativism (close to Platform Cooperativism) You can find more about it in this medium post by one of the core contributors:
"It's a framework for writing fully distributed peer-to-peer applications. It is like a decentralized Ruby on Rails, a toolkit that produces stand-alone programs but for serverless high-profile applications." [1]
[1] https://medium.com/holochain/holochain-reinventing-applicati...
It's toothless, though. Due to the nature of security moving so quickly, any certification or audit standard that actually prescribes specific security controls is inherently going to take so long to get approved by the standards organization that by the time it gets approved, it's already outdated.
The "fix" that has been attempted for this is to try and write security standards that are high level (read: vague) so that they have more "shelf life", but the result of that is that nearly anyone can pass the audit/certification because the requirements are so vague. See: NIST CSF, ISO 27001, HIPAA...
For that matter, it's entirely possible they had security testing "controls" too. But again, the audit/certification probably won't even care that the security testing team is one guy who sometimes tests the app login every couple of weeks. "Oh, Jim tested to make sure that the app only allows 3 password attempts? Security Testing: Check!"
Don't get me wrong, the ISO/NIST frameworks are absolutely a good thing. For a lot of my work, they've been my bible. They are fantastic guides to help companies who want to be more secure focus their efforts and understand how they measure up. But that's only for companies that really want to be more secure. For all of the companies out there that just want to check a checkbox or pass an audit, these frameworks are way way too easy to give a "false positive".
It's often frowned upon by engineers, because it's much more about processes and management structure than anything technical. But I've been involved in a few organizations that went from "technically good but unmanaged" to ISO certified. And I'm quite sure all of them got more secure and did more in terms of continuous improvement after certification.
i'm not saying this is good or bad just... keep that in mind. careful what you wish for.
For example, the gov gives huge fines, and pierces the corporate veil.
Then insurers insure the risks for a data breach. They calculate the expensive premium, and lower it if you do what the consider the right thing, e.g. some ISO guidelines.
Now incentives are aligned: Corporations secure their infra to avoid expensive premiums.
Insurers give correct security guidance. If they overbear, they lose customers. If they are too lax, they pay huge insurance claims.
The governement's job is to make sure nobody is asleep at thehelm. After a while, make the insurance mandatory.
Basically, it's what works for fire insurance.
There are data-breach insurers already.
Again, that has not changed anything.
It’s like we need an FDA for data.
How do you enable S3 for my use case (where I am ok with all the assets being public because they are all static JS/HTML/CSS/images) but also prevent breaches like this?
Do not put anything you don’t want to be public in your S3 bucket. Also, best practice would be for the bucket to be private but Cloudfront be authorized to access the objects to retrieve from the S3 origin and cache at the edge. Use a separate S3 bucket for sensitive data. Use lifecycle rules to delete objects as soon as feasible so you’re not storing sensitive data for longer than you need to. Ensure that cloudtrail logs and s3 logging is enabled for sensitive buckets, so you have access logs for forensics if you do unintentionally leak objects with sensitive data.
"Yuri, why iz Lomonosov-2 supercomputer keep sending me dick pics?"
Since these viruses are carried for life I suppose it prevents the fear of spreading it to a partner that doesn’t have it.
There also actually seems to be several sites in the exact same niche which was surprising to me, when searching for the name of the site I got ads for 4 competing sites.
[1] https://github.com/sa7mon/S3Scanner