Only Cloud Providers Get Security Right. Can IT Vendors Catch Up? (esecurityplanet.com) 136
Slashdot reader storagedude writes: If cloud service providers are the only ones who can get security right, will everyone eventually move to the cloud?
That's one of the questions longtime IT systems architect Henry Newman asks in a new article on eSecurity Planet.
"The concept of zero trust has been around since 2010, when Forrester Research analyst John Kindervag created the zero trust security model. Yet two years after the devastating Colonial Pipeline attack and strong advocacy from the U.S. government and others, we are still no closer to seeing zero trust architecture widely adopted," Newman writes. "The only exception, it seems, has been cloud service providers, who boast an enviable record when it comes to cybersecurity, thanks to rigorous security practices like Google's continuous patching."
"As security breaches continue to happen hourly, sooner or later zero trust requirements are going to be forced upon all organizations, given the impact and cost to society. The Biden Administration is already pushing ambitious cybersecurity legislation, but it's unlikely to get very far in the current Congress. I am very surprised that the cyber insurance industry has not required zero trust architecture already, but perhaps the $1.4 billion Merck judgment that went against the industry last week will begin to change that.
"The central question is, can any organization implement a full zero trust stack, buy hardware and software from various vendors and put it together, or will we all have to move to cloud service providers (CSPs) to get zero trust security?
"Old arguments that cloud profit margins will eventually make on-premises IT infrastructure seem like the cheaper alternative failed to anticipate an era when security became so difficult that only cloud service providers could get it right."
Cloud service providers have one key advantage when it comes to security, Newman notes: They control, write and build much of their software and hardware stacks.
Newman concludes: "I am somewhat surprised that cloud service providers don't tout their security advantages more than they do, and I am equally surprised that the commercial off-the-shelf vendors do not band together faster than they have been to work on zero trust. But what surprises me the most is the lack of pressure on everyone to move to zero trust and get a leg or two up on the current attack techniques and make the attack plane much smaller than it is."
That's one of the questions longtime IT systems architect Henry Newman asks in a new article on eSecurity Planet.
"The concept of zero trust has been around since 2010, when Forrester Research analyst John Kindervag created the zero trust security model. Yet two years after the devastating Colonial Pipeline attack and strong advocacy from the U.S. government and others, we are still no closer to seeing zero trust architecture widely adopted," Newman writes. "The only exception, it seems, has been cloud service providers, who boast an enviable record when it comes to cybersecurity, thanks to rigorous security practices like Google's continuous patching."
"As security breaches continue to happen hourly, sooner or later zero trust requirements are going to be forced upon all organizations, given the impact and cost to society. The Biden Administration is already pushing ambitious cybersecurity legislation, but it's unlikely to get very far in the current Congress. I am very surprised that the cyber insurance industry has not required zero trust architecture already, but perhaps the $1.4 billion Merck judgment that went against the industry last week will begin to change that.
"The central question is, can any organization implement a full zero trust stack, buy hardware and software from various vendors and put it together, or will we all have to move to cloud service providers (CSPs) to get zero trust security?
"Old arguments that cloud profit margins will eventually make on-premises IT infrastructure seem like the cheaper alternative failed to anticipate an era when security became so difficult that only cloud service providers could get it right."
Cloud service providers have one key advantage when it comes to security, Newman notes: They control, write and build much of their software and hardware stacks.
Newman concludes: "I am somewhat surprised that cloud service providers don't tout their security advantages more than they do, and I am equally surprised that the commercial off-the-shelf vendors do not band together faster than they have been to work on zero trust. But what surprises me the most is the lack of pressure on everyone to move to zero trust and get a leg or two up on the current attack techniques and make the attack plane much smaller than it is."
Wow Pot meet Kettle! (Score:3)
Re:Wow Pot meet Kettle! (Score:5, Insightful)
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
But if someone finds a hole in the cloud the effect would be on a nuclear level.
Just imagine if the hole allows an intruder to bring down all hosts for a cloud provider like Microsoft.
I just consider that there are holes, but if someone knows about them they don't reveal them until they need them.
Re: (Score:2)
Never underestimate the willingness of the really dark forces to resort to physical means to get access to a whole datacenter, region of datacenters or even all of them.
But I can still expect that there are other holes in the cloud since many datacenters for cloud services do communicate with each other for redundancy.
So my take is that if you haven't been hit it may be because that you aren't interesting enough. I have been working with several different operating systems and databases during 35+ years, an
Re: (Score:2)
Re: (Score:2)
You're too focused on the idea of port scanning. That's now how this works. You don't need to start bombarding IP addresses with scanning tools to find and identify the configuration page for a cloud provider.
In any case you're argument is irrelevant. It does happen. We've run plenty of stories here on Slashdot from cloud breaches thanks to misconfigured instances, never an actual technical exploit, but always really low hanging fruit. Cloud customers are a nice target for this due to the complexity and usu
Re: (Score:2)
It's one of the big reasons I'm a fan of terraform. (as much as I hate it on a day to day basis)
Making sure that disks are encrypted, that VPCs have the appropriate subnets and that databases re in the correct subnet with no route to the internet is much easier once you have the infrastructure setup with terraform.
Now getting your infrastructure properly setup with Terraform can be painful, and one of the things that I'm getting better at getting done with GPT.
Personally, I find the defaults of GCP better t
Re: (Score:2)
Cloud provider services are under constant bombardment from bots looking for low-hanging fruit, that is you.
Yup. Can confirm as both CSP SRE and CSP customer. A few thousand hits per hour looking for vulnerable Word Press installs isn't anything special to the point I did a little ditty to dump those IPs into a bit bucket for a few hours. Every now and again I'll redirect them to a honey pot just for giggles.
Re: (Score:2)
I would say if you can't get security right, go anywhere but the cloud. Cloud provider services are under constant bombardment from bots looking for low-hanging fruit, that is you. You might get away with being an idiot on a self-hosted solution. No chance for that on a cloud service. You will be found and taken advantage of.
From experience I'd guess that's not the current reality.
I had a dev leave a PostgreSQL database listening on port 1234 open to the world on GCP. I would have expected that database to be compromised in minutes or maybe a couple of hours at most. It took almost three months before it was compromised. The only reasonable explanation is that Google thwarts port scanning on their network, which allowed this database to avoid compromise for an insanely long time.
Re: (Score:2)
Re: (Score:2)
Big oof, so much wrong with everything you said.
Just saying it doesn't make it so. There are literally endless strings of stories of breaches from misconfigured cloud services. If you can't get security right the cloud won't save you. If you know the basics of security then cloud services are actually a good addition to your IT capabilities.
Re: (Score:2)
Accidentally public S3 buckets have entered the chat
Re: (Score:2)
I've never claimed that.
Your attitude claims it for you.
about memory safety being unnecessary
Where did I say that? I use C++ because memory safety is necessary. As I've told you time and time again, the DEFAULT in C++ is memory safe. Just because you're too incompetent to use the memory safe features built-in to the language and standard library doesn't make it unsafe.
But as you've demonstrated time and time again, you don't understand how languages work under the hood. You think they're magic. And it is this magical thinking that continues to make memory safe lan
Re: Wow Pot meet Kettle! (Score:2)
Well that's twice now that you've said that I've said things that I just haven't said. Though looking back, you seem to make a habit of that.
Re: (Score:2)
Re: (Score:2)
Dude...that's been your only salient argument against rust, everything else you've said is anywhere between "no shit" (i.e. that memory safety is no guarantee against security problems, which itself is an invalid argument to the effect of it being moot) all the way to easily proven false. Your claim that C++ is somehow safe by default is laughable and shows just how bad you are at it. Your only possible disclaimer of it at this point is if you intend to say that you don't actually understand the meaning of
Re: (Score:2)
But do continue, watching you rage is comic gold. Why else would I bait you like that? :)
Because you're a master at baiting.
Re: (Score:2)
Your claim that C++ is somehow safe by default is laughable and shows just how bad you are at it. Your only possible disclaimer of it at this point is if you intend to say that you don't actually understand the meaning of the term, which would be believable.
If your C++ isn't safe by default, then you are the one who is bad at it.
It's clear from our discussions that you have absolutely no idea what C++ actually is or how it does the things it does. You exposed yourself as believing in any old blog FUD you've come across. You've learnt to repeat their drivel, but you don't understand what drivel you're saying. You're a sad cargo cultist.
Re: Wow Pot meet Kettle! (Score:2)
Exactly!
Re: Wow Pot meet Kettle! (Score:2)
If your C++ isn't safe by default, then you are the one who is bad at it.
I never claimed to be good at C++, nor do I ever intend to, and for exactly the same reason why I have no interest in COBOL.
It's clear from our discussions that you have absolutely no idea what C++ actually is or how it does the things it does. You exposed yourself as believing in any old blog FUD you've come across. You've learnt to repeat their drivel, but you don't understand what drivel you're saying. You're a sad cargo cultist.
A cultist would need a cult leader who writes poorly thought out manifestos. Basically like this one:
https://www.open-std.org/jtc1/... [open-std.org]
Re: (Score:2)
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf
What's wrong with saying that there's MORE to safety than just memory safety? What's wrong with saying that some safety concerns lie OUTSIDE of the language and requires other tools that check beyond language rules, and not expect any one language to cater for all scenarios? You didn't read or understand the whole thing.
See? You basically admitted that you think memory safety is all there is, and no memory safe language can ever have security issues.
Re: (Score:2)
I never claimed to be good at C++,
That's not the point.
The point is you've fallen for, and repeated, ALL the FUD around C++. So a statement like "C++ is safe by default" completely passes over your head because of your ignorance.
Re: (Score:2)
What's wrong with saying that there's MORE to safety than just memory safety? What's wrong with saying that some safety concerns lie OUTSIDE of the language and requires other tools that check beyond language rules, and not expect any one language to cater for all scenarios? You didn't read or understand the whole thing.
Actually if you look, not even particularly carefully, your leader directly contradicts you:
Unfortunately, much C++ use is also stuck in the distant past, ignoring improvements, including ways of dramatically improving safety.
This makes it pretty glaringly obvious: There is no "default" to C++ that you could actually call safe. And that's not even getting into the biggest problem of all:
I envision compiler options and code annotations for requesting rules to be enforced
In other words, what you need to make C++ actually safe doesn't even exist right now, let alone as some kind of default as you claim. I can't venture to guess what is going on in that big hollow coconut of yours when you say that it's not only there but is
Re: (Score:2)
The point is you've fallen for, and repeated, ALL the FUD around C++.
No but you know what's funny actually is you've accused me, many times, of repeating of whatever I found on some blog. Not only have I not done that, but you yourself have done it many times for rust. You've repeatedly parroted exactly the same talking points that a lot of other anti-rust people have, and every single one of them reads as if you don't know the first thing about it.
So a statement like "C++ is safe by default" completely passes over your head because of your ignorance.
No, it's because it doesn't actually exist, and you're an idiot for claiming it does.
Re: (Score:2)
Actually if you look, not even particularly carefully, your leader directly contradicts you:
You couldn't read past that? You realize what he wrote afterwards - the whole thing - puts that into context. The EXACT context I just said.
There is no "default" to C++ that you could actually call safe.
Yes there is. I know what I'm talking about. YOU are just cherry picking quotes from something you obviously don't understand.
In other words, what you need to make C++ actually safe doesn't even exist right now, let alone as some kind of default as you claim.
They DO exist right now, you illiterate dipshit. But what you don't seem to understand is that C++ continues to evolve. They exist, but there will be more coming, as we figure out better and better ways.
You REALLY didn't understand a thing you
Re: (Score:2)
Re: (Score:2)
You couldn't read past that? You realize what he wrote afterwards - the whole thing - puts that into context. The EXACT context I just said.
Well I did quote bits well passed that, so...yeah. And yeah, it puts it into context, which isn't at odds with anything I said. And no.
And you can only guess, because you know jack shit.
I can only guess because, while you're very predictable, I can't peer into your thoughts from across the internet.
Like I said, the default in C++ - doing the minimal thing - is actually the safest. But you not understanding a single basic thing about C++ means no matter what I say, you would not comprehend it.
Let's just provide an example then -- remember how I said you think the handguard is useless because you need to read the manual? Well here's an example of very "minimal" and "default" C++:
(note: angle brackets replaced to satisfy slashdot)
int main()
{
Re: (Score:2)
But then who would squeeze all of that entertainment out of you?
Re: (Score:2)
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
Ah there's nothing like thoroughly defeating your argument while getting entertainment out of it :)
Re: Wow Pot meet Kettle! (Score:2)
You're what Internet technologists refer to as a lolcow. If somebody like me doesn't milk the lols out, your utters will swell, which can be quite painful. Do you really want that?
Re: (Score:2)
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
I'm in Los Angeles, what trees once existed have long since been removed to make room for graffiti laden concrete so that some heroine addict can put a tent on it and call it home.
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
I can't, you already beat me to it.
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
Only gangbangers are allowed to have guns here.
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
You first
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
I see you're feeling melancholy This PR should help:
https://github.com/fish-shell/... [github.com]
Re: (Score:2)
Re: (Score:2)
I told you, you need to be milked for lols. Can't you see I'm busy here?
Re: (Score:2)
Re: (Score:2)
Oh wait I get it, you're cranky because you haven't been milked in a few days.
Re: (Score:2)
Re: Wow Pot meet Kettle! (Score:2)
Well I'm milking damnoregonian right now, you'll have to wait your turn.
Re: (Score:2)
Re: (Score:2)
When you get called out for your complete and utter bullshit, you just claim to be doing it for the lols. You do that a lot apparently, because people see through you a lot. You're obviously someone just lying about themselves. You have absolutely no experience in anythi
Re: (Score:2)
No...I pretty thoroughly debunked both of you. In your case, I didn't even need any references, I just gave you some code examples using a language that you claim to be an expert at. If you ever had any counterargument, you'd have used it by now.
It sounds like he needs your help though, he's currently fighting for his life on that hill and he badly needs an ally. Only you can save him!
Re: (Score:2)
So go kill yourself.
Ice Road Trucker (Score:5, Insightful)
There are two kinds of Ice Road drivers. "Those who have been in the ditch and those who will be in the ditch".
Cloud security people are hesitant to brag to much about how much safer they are because they know how risky things are.
Nothing looks sillier than "XYZZY Cloud Co is so secure" followed be a headline a short time after "Major Data Breach at XYZZY Cloud Co".
Also, most of the cloud security people who would be credible enough to matter on the record have insider knowledge of exploits that are actively being addressed. There is a permanent sword of Damocles in this industry.
Any CIO that tells their Board that the company data is 100% secure should be fired or demoted to a place where they cannot do any damage.
Re: (Score:3)
Re: (Score:2)
When everything works safe, too many people and systems slack off and get lazy because "it's all safe and secure". Then one day everyone does it. We are trending to that because we have cloud providers, now.
Re: (Score:2)
In aviation this is called "normalization of deviancy". Basically, once you cut corners and appear to get away with it, you're a lot more likely to keep cutting them. Remember the fertilizer plant in Iowa that went boom? Similar idea.
Re: (Score:2)
Yep, and at the end you save a penny somewhere and that finally topples everything over and you lose a billion or everything. That is why all technical systems must expect to fail catastrophically, because eventually it happens. You can delay things by staying vigilant and threatening the bean-counters with death whenever they try to save one more penny, but eventually they win and a while later things come crashing down. Ultimately, bean-counters always try to do things cheaper than possible and they are i
Re: (Score:2)
Stats about which cloud provider is most secure will just end up making your own service less secure.
Re:Ice Road Trucker (Score:4, Insightful)
Google/Amazon/MS spend a lot more money on data center security than most can afford, and they generally have first pick of the engineers and security experts over almost every other company, including the fairly large company I work at that recently had a serious cybersecurity incident in a data center. We've decided that offloading that liability to someone who's better equipped to deal with things like nascent attacks was the prudent thing to do, and, honestly, I think it's the prudent thing for almost anyone that can't airgap their network. Our incident had nothing to do with unpatched software, social engineering, or any other dumbass easily preventable vector out there. It was very likely a state actor looking for specific things.
It's not a matter of if, it's when, and probably the best thing you can do to delay when is to put your data somewhere that has more money invested in better people and better infrastructure than you can realistically field. Even then, it's still a gamble. You're just betting with hopefully better odds.
Re: (Score:2)
Indeed. Also a major cloud provider having a large breach will probably put them out of business and may well put others out of business as well. As soon as that is in the press, a lot of companies will adjust their risk analyses and the cloud will look even more expensive than it already is compared to running your own.
So they are scared as hell and do the max they can afford to do. Or they would, because the bean-counters are always present and always erode quality over time. Because of the bean-counters
Re: (Score:2)
For damn near every other kind of IT organization. the cost of security is treated as a waste of time and money, so it is always underfunded. For example, that's why Verizon has a major data breach every three or four years. The downside for them in a data breach is small enough in both direct costs and reputation that there is
Re: (Score:2)
Indeed. My suggestion would be $500 for every customer that has their data compromised, no questions asked, unless they can prove more damage was done. That would change things pretty fast.
Re: (Score:2)
Also a major cloud provider having a large breach will probably put them out of business....
You would think so, but it hasn't happened yet. And this is despite cloud security breaches happening all the time. It appears that cloud providers have taken the approach of, "make breaches of all cloud providers so common that people learn to accept it as normal."
Re: (Score:2)
Also a major cloud provider having a large breach will probably put them out of business....
You would think so, but it hasn't happened yet. And this is despite cloud security breaches happening all the time. It appears that cloud providers have taken the approach of, "make breaches of all cloud providers so common that people learn to accept it as normal."
Exactly.
Just to name a few simple examples, Okta and LastPass, not as cloud providers, but as companies who survive despite security being their core reputation.
And it's worse with the cloud providers, because if a Google has a bad breach, what exactly are you going to do about it as a customer???
In fact, people have passed the responsibility to an external entity, and that entity is too big to be simply switched away from, and everyone else is in the same boat.
And maybe that's the appeal. It becomes "the g
Re: (Score:2)
Sure, cloud security breaches are common, but how common are cloud provider security breaches? And that is the kicker. As long as they can blame it on the cloud customer, they can, with some justification, claim it was not their fault. That ends if, for example, somebody breaks into the management layer of Google or Microsoft, steals 100'000 cloud images and uses the cloud for some really nasty DDoS afterwards.
Re: (Score:2)
To be fair, Google has never suffered a major breech of its cloud infrastructure. All leaks have been due to attacks on individual accounts, rather than getting into the infrastructure itself.
Well, unless you count the NSA's access.
Never had a ransomware attack encrypt large numbers of cloud servers either. Clearly they are doing something right that many orgs are doing wrong with their local IT infrastructure.
Re: (Score:2)
The thing about cloud providers is that if they are breached, they can edit the client's config, and say the client was the one that had the issues, for example, a bucket magically turning publicly accessible. We really don't know how secure cloud providers are, because they can bury breaches and easily blame it on their clients.
You clearly have no clue about the automation tools that are used to manage deployments in the cloud at scale.
When a config is not what the CI/CD system expects it will throw an error and bring in a security team to investigate it.
While the cloud provider could theoretically fake both the settings and the logs, many organizations pipe their logs to places like loggly, datadog, or splunk so they'd have to come up with a reason that the external logs don't show the user changing the settings or compromis
What a steaming pile... (Score:5, Insightful)
I've worked on various SAAS platforms and the security is laughable. So many work-arounds get put in place _because_ of the (frequently ridiculous) security measures that it ends up compromising the system. I have one that I'm working on right now that has a one-hour token expiration time, which forces a re-authentication. Somehow I have one tab of my browser that's been working for a week without re-authenticating (and no, it isn't because I've re-authenticated on on another tab, oddly those ask me to re-auth and I just ignore it and go back to my "magic" tab - also, no I didn't "save" a password, I never do).
Granted, in-house security can also be bad, but at least you have to make the effort to get into the internal network before you can mess with that. Maybe other people's experience has been different than mine, but I sure as hell would not say that the cloud gets security "right". Not even close.
Re: (Score:2)
I've just seen a different cloud lately... (Score:5, Interesting)
Cloud providers ... (Score:3)
I do. So yeah: Cloud providers can claim an excellent security record. Because it's their customers' stuff that gets swiped.
Insecurity providers (Score:3)
Even on the most secure cloud provider, any IaaS customer can easily setup a very insecure virtual infrastructure. IT providers need to have a lot more education of all aspects of their work. They also need to learn that throwing lots of commercial security products or services at the problem does not work. Security is a whole attitude thing. I saw this problem back when i worked as an operations director at an ISP. The IT service providers that were our customers frequently had security issues of their own making or their own lack of knowledge; we just provided access to their insecure networks.
Re: (Score:2)
any IaaS customer can easily setup a very insecure virtual infrastructure
This. While cloud services generally have a great track record of managing their security they give their customers plenty of rope with which to hang themselves. For a while it seems like we heard a story every other week of some major sensitive data leak by someone leaving default passwords set on an EC2 instance or uploading their private keys to a public repo somewhere on the cloud.
Companies may see benefit in outsourcing the hosting of the application but they will end up in the shit if they fire people
You don't use the cloud for security (Score:2, Insightful)
Those are the things that motivate people to use cloud services, not security.
Pfftt (Score:2)
Take that NSA... looks like you'll be moving over to cloud vendors.
Really? (Score:2)
Re: (Score:2)
Facebook runs their own hardware (custom hardware at that). I don't know how they get lumped into cloud computing.
LinkedIn was on prem with their own data centers. before being bought by Microsoft and moved to Azure in 2019,
As for Alibaba Cloud, that is by definition a data breach. The CCP, and anyone they wish to share the data with, has access to everything on Alibaba Cloud.
I don't understand (Score:4, Interesting)
> If cloud service providers are the only ones who can get security right
I don't understand. First of all, it seems to me that if you're using cloud services, you have already taken some steps away from security. For one thing, you have your service and/or data on a system that is accessible remotely...over the public Internet. For another, the service/data is on machines controlled by some other organization. I'm not saying this isn't acceptable ever, but I am saying that this isn't obviously getting security right.
But maybe it's not really "getting security right", but only "getting zero trust right". That leads me to my second point: If the cloud providers can do it, why couldn't it be done by others?
The article makes the point that it's all very complex and everything needs to be tracked and authenticated. I'm sure this isn't already universally done, but is it really that hard? Every organization I've ever worked at already authenticated users. Only authenticated users have access to most resources. Source code, documentation, and, in many cases, configuration parameters can only be altered by authenticated users, and a log is kept of what was changed when and by whom. A lot of what I understand the article to be asking for seems to already be in place.
Then we get to:
> The hardware stack is controlled by the cloud service providers. For the most part the CSPs build their own hardware and theyâ(TM)ve even been building their own CPUs. They build their own network devices, NVMe SSDs and motherboards.
I don't think this is quite true. As far as I know, cloud providers generally use commercially available CPUs (with some widely publicized security vulnerabilities, no less) and use commercially available SSDs.
> There is a single software stack that they control and, for the most part, they write themselves
I would be shocked if this were true. As far as I know, these software stacks are largely built from open source software (hi, Linux!). To the extent that the stack is open source, nothing prevents a not-cloud-provider from using the very same software. To the extent that the stack is not open source, I'm not sure that should inspire more confidence in its security. Besides, "software stack that they control" sounds nice, but I guarantee you that the software stack is too complex for anyone to really vouch for its security.
> They do not have to have network monitoring, multi-factor monitoring, OS monitoring, etc.
I am not sure why the author thinks this is true.
All in all, I understand the idea that not every organization has the budget and competence to make sure everything they do is subject to all the authentication, audits, updates, monitoring, and logging you might wish for. But the problem with using a cloud service provider to handle this for you is that they really can't; you need to access the cloud somehow, which means you will have some hardware that runs software, and users that need to be authenticated, have their authorization revoked when appropriate, etc. At best, you can outsource part of it all to the cloud service provider...but it does require that you trust the cloud service provider to do their part of the job. At that point, is it really zero trust anymore?
Re: (Score:2)
You are assuming that things running on the cloud provider are accessible over the internet.
That are times that is only indirectly true with a public API gateway hitting a controller that hits a private api gateway that then triggers jobs that modify the cloud infrastructure. With four layers of indirection between the internet and reaching the infrastructure.
While generally most things are desirable to be reachable via the internet these days on AWS and GCP it is entirely optional
Additionally, the network
Re: (Score:2)
That depends on your threat model.
On Alibaba Cloud, that is almost certainly true, but almost certainly a violation of the terms of service, which puts you in a weird place.
Google seems determined to keep the CCP and NSA out of their systems after being embarrassed by finding out that the NSA had breached them from the NY Times and not their internal monitoring. Google assumes that their hardware vendors cannot be trusted and are malicious and so they have cryptographic signatures in their firmware to verif
He's kidding, right? (Score:3)
Just from the last two years, just microsoft, just databases, just off the top of my head:
https://arstechnica.com/inform... [arstechnica.com]
https://www.techradar.com/news... [techradar.com]
The basic claim of this piece requires way, way, way more justification than this guy gives.
This is just dumbing the population down further (Score:2)
basic logic (Score:2, Insightful)
If cloud service providers are the only ones who can get security right
First, you need to prove your basic assumption. Until you've done that, everything based on it isn't even false, it's worse than false.
Who says cloud service providers get security right? Just because we haven't yet had a total compromise of the major players doesn't mean that a) all OTHER cloud service providers get it right and b) there wasn't one that we just don't know about.
That we hear many more incidents in standalone IT systems is simply a scale factor. There's a few hundred cloud service providers
Re: (Score:2)
There is also another thing: If a cloud system gets hacked (which happens all the time), it is on the owner of that system and not on the cloud provider. If your on-prem system gets hacked, it is always on you, regardless of whether it was the virtualization and management layer that got hacked or not (if virtualized). So, for example, the last of my customers that got hacked had their exchange server hacked, the attackers never got into the private cloud management and virtualization layer. In a public clo
Re: (Score:2)
But at least by now we know. When I started my career as a sysadmin, you know, back in the old days, 15th century about, I always said to myself that I'm doing my job right if the boss wonders if he needs me because everything is running just fine.
Now, an eternity later, as an auditor or consultant, I hear things like that from the bosses. They finally got the message. Not all of them, but some.
"Only Cloud Providers Get Security Right." (Score:2)
[citation needed]
Cloud providers are scared as hell ... (Score:2)
.. of being breached. That is the mein reason the get this mostly right. What they do not even touch is end-system security, just virtualization and management interfaces. (Yes, this is simplified.) As a consequence, you are about as secure with non-virtualized or carefully virtualized on-prem infrastructure as you are with cloud systems. On-prem is often cheaper although the TCO calculation is not simple.
One day, we will hear about a major cloud provider getting hacked. The hack may already have happened,
Re: (Score:2)
Re: (Score:2)
Indeed. The cloud does not make you more secure. It does make everything more complicated for an illusion of simplicity and security though. If you screw up anything of that added complexity, you can even more easily get attacked. Of course that will not count as a hack of the cloud provider.
If ... (Score:2)
As the Spartans said (https://en.wikipedia.org/wiki/Laconic_phrase)
Zero Trust is also a nebulous concept (Score:2)
From the ACM Queue Magazine [acm.org]:
You need competent staff plus reviews (Score:2)
I saw a malware incident. It was caused by a bad configuration change. It was cloud-hosted but managed by local staff. Another part of the network was again cloud hosted, but managed by a different group. It escaped untouched. Any security configuration changes should require review by some kind of committee. There is no magic bullet. Cloud-hosted solutions can get blown away too.
Re: (Score:3, Insightful)
Holy observation bias batman, and really bad one at that. Look if you find anyone making a claim relative to something and then proceed to search about examples only of failure without looking at the relation you can make anything look bad. Here let me try:
"Open source has absolutely horrible security." https://heartbleed.com/ [heartbleed.com] Done. Now obviously my statement is stupid, and open source software actually has a great security track record. But that's precisely the kind of logic you applied.
But actually your
Re: (Score:2)
Not only that, but the first one I'm not sure truly counts as a breach.
Early FB developer accounts gave you access to download any users data and activities. There were people who tested it out by grabbing Mark's information.
What is amazing is that the back door Customer Service password wasn't leaked years earlier than it was. For years you could log into any account with the password 'Chuck Norris'. I don't know if that counts as a data breach though.
When remotely installing kernel level root kit is the
Re: (Score:2)
For small companies with no clue or capability at all, SaaS is still a better bet.
If you can afford an IT department, though... you really ought to keep everything possible in house, maybe excluding a corporate vanity web site.
Re: (Score:2)
Re: (Score:2)
That's a lovely absolute statement that tells everyone you are insufficiently experienced to back it up.
Believe it or not, you are not the lone insightful genius in the world who understands all the use cases, and there are an awful lot of businesses out there supplying and using variations of SaaS. It can make sense, both logical and financial.
Re: (Score:2)
SaaS starts making a lot of sense when the alternative is Microsofts business suite.
While self hosted and desktop software is a nice idea, the business drivers for productivity apps mean that you wind up with SaaS products that are cheaper than desktop applications with better collaboration.
Is this insane that it works out this way, probably. But, it is a business reality