Yet another AWS config fumble: Time Warner Cable exposes 4 million subscriber records Records of roughly four million Time Warner Cable customers in the US were exposed to the public internet after a contractor failed to properly secure an Amazon cloud database. Researchers with security company Kromtech said freelancers who handled web applications for TWC and other companies had left one of its AWS S3 storage …
Um, the cloud is magic, you don't need security and you don't need people to manage it, duh!
Don't forget to mention that it doesn't require any of that pesky and expensive "expertise" - you can do that on the cheap too!
As someone else mentioned, the problem with people that look for cost savings instead of value is that they start cutting everywhere because they know they will be long gone with their consulting fee and/or savings bonus before the problems they have caused start to emerge.
"As someone else mentioned, the problem with people that look for cost savings instead of value is that they start cutting everywhere because they know they will be long gone with their consulting fee and/or savings bonus before the problems they have caused start to emerge."
Yes. The difference between cutting costs and reducing spend is subtle but crucial.
Bound to happen... Amazon are the biggest cloudfuck operator and its their silos that are leaking... The fact that the customer is really to blame is irrelevant. If you're a cybercrim / hacker you're spending quality time raiding S3 looking for open barn doors etc.
"Bound to happen... Amazon are the biggest cloudfuck operator and its their silos that are leaking.."
Yes and I blame Wimpey homes when people leave their front doors and windows wide open, piss off on holiday for 6 months and have all their electrical equipment nicked!
So, genuine question, is it the default for AWS S3 databases to be publically accessible, or is this a setting that the all these companies have changed from the default?
If the former, maybe Amazon should review their default settings, if the latter, the companies involved deserve to be litigated out of business.
* Default or not, does it really matter ? I say No! Because decades of network access up to now says you make no assumptions... Instead you double and treble check your locks always etc... Whereas what this says, is that the rise of the cloud is being purely driven by selfish corporate cost control.
* If so, its a true living nightmare scenario for the future of data security... As lawsuits won't fix this, fines won't fix this... This is why hackers / Cybercrims and scammers have already won the data wars uncontested imho. The recent VMWare Reg article 'Wants security industry to shrink' speaks volumes...
Default or not, does it really matter ? I say No! Because decades of network access up to now says you make no assumptions... Instead you double and treble check your locks always etc... Whereas what this says, is that the rise of the cloud is being purely driven by selfish corporate cost control.
Whilst I sort of agree with your first point, I think the bigger problem is the rise of the culture where developers are encouraged to go their own way and shove their data into a convenient cloud without any consultation with the IT staff who might have had some clue about network security.
Do you know the answer (I do not). I think the question is relevant especially given that seemingly over 3/4 of IT shops bitched at MS for years over their not making secure settings the default. Eventually they caught on and did something about it.
I say someone should answer this and shine a light on a bad AWS practice if indeed the default is Public.
No, it is not the default for S3 buckets. The default setting is that only the owner has read-write access; no one else has any access. You must intentionally change a setting for an S3 bucket to be world-readable.
In fact, if you have world-readable S3 buckets in your AWS account, AWS periodically sends you remind-o-grams, asking if that's what you really want.
So it's unclear why there's so much desire here to place blame on AWS. Misconfigured security settings is absolutely a customer problem.
Check out: http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html for details.
This has *always* been the case; users have to explicitly set permissions for buckets / objects to be accessible outside of their account (authenticated users, or everyone).
Note that there is also clear guidance on security responsibilities (the "AWS shared responsibility model") here: https://aws.amazon.com/compliance/shared-responsibility-model/
Indeed, but that won't spoil the fun of the Luddites on here who would like to pretend that cloud is less secure than their own bit barns.
So, in olde-worlde terms, lets say you have a perimeter firewall, and you open port 22 to the world, then you have open routing behind it, then you set all your root passwords to "password", then you get hacked and your data is stolen.
Who's fault would this be:
a) The firewall vendor
b) The Data Centre operator
c) The router manufacturer
--or--
e) The idiot who configured it
Cloud doesn't stop you from doing stupid things, it gives you the tools to do smart things but you still need to manage it, its just simpler to do the routine stuff like security, but its not idiot proof.
Cloud doesn't stop you from doing stupid things, it gives you the tools to do smart things but you still need to manage it, it's just simpler to do the routine stuff like security
Bzzt - wrong. This is one of those dangerous things I see all the time: because some vendor declares themselves "secure" because they happen to have a switch for it does not remove the need to have competent security people evaluate the whole scenario. If the original topic of this article would have had decent security processes in place this would have been found either in Ready For Service signoff process or on the next audit. And to do that you need specialists (unless you want your insurance to laugh in your face when you try to claim).
It's a myth that going cloud means easier security - if anything, you have just substantially enlarged your attack surface. I'd treat cloud storage as exposed by default unless proven and verified otherwise, and I'd add a ton of monitoring to ensure I can tell when that changes for any reason.
As a matter of fact, I'm willing to bet that that exact myth is what caused all these discovered exposures to take their eye off the ball.
The big cloud vendors like AWS don't "declare themselves secure", they publish and are regularly audited on the security of their areas of responsibility, by dozens of regulatory bodies worldwide.
Cloud security *configuration* is much easier than on-prem, its easier to set a policy on an AWS VPC Security Group, or an Azure Vnet NSG than for instance on a checkpoint firewall, I know. I've done all 3.
Security *design* is just as important in cloud or legacy environments.
A good idiot can stuff up either, but given equal competence Cloud is more secure, because the cloud providers can build a better, more secure data centre than you can.
@ AC, it may or may not make routine stuff like security easier, that is not really the point you addressed in your post. The fact that something is made easier is of no use if you do not bother to get even the easy configuration done. I see you assume that the worst case applies until you have checked and double checked that all possible steps have been taken to secure the shop. So one brownie point for you and all of those who follow that example.
However, if Joe Thickastwoplanks Or Bertie Cheapscate does not bother to look let alone check they have not messed up; then the ease or difficulty of getting it right does not matter. The fact that AWS was said to send out reminders of misconfiguration suggests that the Joes and Berties might need to invest in some staff who can read and do some basic checking as well.
"The fact that AWS was said to send out reminders of misconfiguration"
I'm not sure how often AWS do this in all honesty. I've had one, about a month ago, in 5 years of using AWS (and we've had deliberately open buckets for about 2 years, because we have developers who can't cope with authentication and we're publishing it to the Internet anyway).
Securing s3 buckets properly is hard though. Configuring vpc access only involves modifying the subnet routing table and setting deny rules on the bucket security groups. I bet I'm one of the very few have actually done this.
And then a whole load of AWS stuff stops working (lambda, for example, until recently - the new AWS toys are released without VPC support initially).
And then you get into all the Big Data and EMR stuff, which doesn't support application level encryption.
Redshift Spectrum, a Data Warehouse technology, launched without (and still doesn't have) encryption or VPC support.
The combination of AWS products not understanding encryption and not understanding VPCs leads the lazy to rely on just IAM, and IAM is so easy to get wrong. As I've said before here, their documentation often recommends grant * to *, which isn't helpful.
Security comes through multiple layers. In their rush to get products out AWS tend to start without those layers.
Option "D" for Derpy
I have this idea for a toy Nerf(c) gun to sell to kids. Sure, you flip one switch and it becomes a real AR-15 assault rifle, but the default position of the switch is "Kids Nerf Gun". Should I create a GoFundMe for this?
Possibly developers have been security slapdash for decades because it just gets in the way of doing cool stuff quickly.
Back in the day the operational staff probably kept them nicely caged in their festering pit of cool and cleaned up the more obvious stupidities during testing and deployment.
These days you don't need that expertise because DevOps and Cloud. Code it, click and there you go. New live system. Disrupt, baby!
Quality is boring, though, init.
In the old days you could put all sorts of rubbish on your box safe in the knowledge that it wasn't routable from the Internet.
Nowadays everything is port 80 or 443, even file access (e.g. s3) and microservices mean every little thing has a REST over http endpoint visible from the Internet regardless if the inefficiency that creates.
Putting everything on http is the equivalent of not having a firewall.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
