SMB resources on the move
-
@stacksofplates said in SMB resources on the move:
Didn't we have a discussion previously about a PaaS that had been hit by crypto because they were using Windows does servers on the back end? For reasons like this I agree with some auditing if done correctly.
This isn't "hosted vs non-hosted", this is "enterprise top end cloud vendors" vs SMB. Unless that PaaS was AWS or one of the select group of enterprise cloud hosts, it doesn't matter. This isn't about one model or the other, it's about an actual vendor list of the top players who have the top security in the world.
So if people take this to mean that they can just go find the guy who lives next door, get him to make a PaaS just for them and host on it and that will make them safer, they didn't get the right message. It's if they go to AWS or Softlayer or maybe even Azure that there is no way for them to be more secure on their own.
-
@stacksofplates said in SMB resources on the move:
We have a few audits and I'm fine with that as long as it's not a check box scenario. I totally understand that people want to know that we meet certain requirements.
Audits aren't a bad thing if done well. Almost none are done well. But if the audit either:
- Creates a false sense of security (believing that the audit itself protects you) or
- Causes bad behaviour (like avoiding security in order to have internal audits)
Then the audit itself is a security problem. So statistically, audits undermine security.
-
@scottalanmiller said in SMB resources on the move:
Unless that PaaS was AWS or one of the select group of enterprise cloud hosts, it doesn't matter.
Ah I apologize, I meant SaaS. They had some software that you could access, which would have been built on whoever.
-
@scottalanmiller said in SMB resources on the move:
the chances of their data being found and utilized and identified remains close to zero
How is that logical? The hacker isn't going to comb through everything manually. They'll grab everything they can.
-
@stacksofplates said in SMB resources on the move:
SMB has all data on premises. SMB gets hacked, all data exposed.
SMB has all data at cloud provider. Cloud provider gets hacked, all data exposed.But to his point, for the first scenario you were the target and they got your data. For the second scenario you might not have been the target and they still got your data.
That's the point...
-
I think that this isn't a black and white only discussion. I'll get back to this tomorrow, had a terrible night with under two hours of sleep. Sorry.
-
@scottalanmiller said in SMB resources on the move:
@stacksofplates said in SMB resources on the move:
The first happens all the time, the second has never happened yet
Not really a good argument. There are millions of businesses and a handful of cloud providers.
Sure, but YOUR DATA is still at less risk on a cloud provider. It's that simple. No matter how you word it to sound bad, the risks remain lower from all serious security studies, including groups like the CIA and top financial firms. The most secure firms in the world say that they can't match what Amazon is doing, period. And if they can't with billions to throw at it, the degree to which SMBs are at great risk still is insurmountable.
And the complexity of their systems is infinitely more than an SMB.
IaaS like you propose here. Taking the legacy system and just moving it to AWS or the like. This is a bandaid.
So for an SaaS approach the only thing stopping someone from getting in is a password. And possibly 2FA, but if using SMS 2FA that's been hacked pretty easily http://fusionlacedillusions.com/index.php/2016/06/20/heads-blm-leader-hacked-plans-reveal-martial-law-chaos-conventions/
-
@thwr said in SMB resources on the move:
I think that this isn't a black and white only discussion. I'll get back to this tomorrow, had a terrible night with under two hours of sleep. Sorry.
Ha ya this is too much for a Sunday.
-
For example, I treat my lab at home like I do a production system. The only way in is SSH with a key, password (not key encryption pass but actual system pass), and OTP (from IdM, so the internal IdM server would have to be compromised before that code could be spoofed). Then once inside, you need a kerberos ticket for all the systems joined to the realm. Some aren't but that's not something I can fix. Users on the jump box are not wheel members and you can't su to another user on the jump box. Only certain ciphers are available and other similar precautions. Hopefully today or tomorrow I'll get it set up for email notifications on successful auth messages from GrayLog (I just haven't had the time yet). Everything is done with dynamic tunneling so I just tell Chrome to use the SOCKS proxy and I have access to whatever I need. It literally takes me about 3 more seconds to log in than it did with just a password. So now, the only way for someone to get my info is to physically come in my house and take it (which is a different discussion).
-
@stacksofplates said in SMB resources on the move:
@scottalanmiller said in SMB resources on the move:
the chances of their data being found and utilized and identified remains close to zero
How is that logical? The hacker isn't going to comb through everything manually. They'll grab everything they can.
Sure, but grabbing gobs and gobs of unidentified data that isn't targeted means that combing through it is very, very hard. Just because they have it doesn't mean that they can identify it, will ever get to it or will attempt to exploit it. Might they? Sure. Has there been a breach? Yes. Is it meaningful? Possibly not.
If you had all of the data from Amazon's AWS.... 99.999999% of it would be useless to you.
-
@thwr said in SMB resources on the move:
@stacksofplates said in SMB resources on the move:
SMB has all data on premises. SMB gets hacked, all data exposed.
SMB has all data at cloud provider. Cloud provider gets hacked, all data exposed.But to his point, for the first scenario you were the target and they got your data. For the second scenario you might not have been the target and they still got your data.
That's the point...
No, it is not. The point is being more secure. Again, don't let the means drive the ends. Focus on the goal, don't get lost on proximates.
-
@thwr said in SMB resources on the move:
I think that this isn't a black and white only discussion.
It's not, BUT the end goal is security. Discussing HOW enterprise cloud is more security is interesting, but it doesn't change the final results as to which is more secure. We see this mistake with RAID risks all the time, people get distracted trying to understand a single aspect of the risk, like how many hard drives can fail, and miss the big picture and forget the goal of reliability. How many disks can die isn't what makes one RAID level safer than another primarily, it's background noise, but discussing it makes it seem like it is what is going to matter and it continuously misleads people.
-
@stacksofplates said in SMB resources on the move:
So now, the only way for someone to get my info is to physically come in my house and take it (which is a different discussion).
There is always another means of compromise, just thinking that there isn't itself is a security risk. One that I guarantee AWS' security team (ranked the best in the world) doesn't make. They also have monitoring and people there 24x7 always watching everything with the best AI and the best human I that there is. Nothing you do gives you the tools that they have, nothing.
But beyond that, the fact that someone could grab your stuff physically alone is enough to end the discussion. Amazon effectively removes that risk. You can't physically target data at Amazon. You can't target it via software tools, you can't target it with guys and a trunk and guns. You have to attack through different vectors.
-
Another massively overlooked factor is that a breach of Amazon would also mean anyone doing so would look like a kid holding a bucket in front of the ocean. Sure he can steal all of the water that he wants, but data is going in faster than he could take it out. Assuming that there was a breach, and that it was not found FOR YEARS you'd still have essentially zero chance that YOUR data would be some of the data downloaded. There is so much data to get, all unidentified, that mostly they'd be getting OS files, cat pictures and such, not valuable data. Some, yes. But whose? And would it be up to date and useful to the attacker? Not likely. Amazon is an essentially useless target.
But we are assuming that someone would breach Amazon (hard) and then continue the breach year after year as they attempt to download all of that data (very, very hard.) No one anywhere has the bandwidth to suck down what Amazon has. So anyone would, at best, be trickling out data.
So for all intents and purpose, there is no universal breach of AWS even possible. Sure, aliens might come down with planetary scale transporters and pull the entire datacenters up somewhere. But no human IT system today could effectively breach Amazon simply because of the scale. It would always be a partial breach, and a very small one at that.
-
The idea that cloud providers provide a high profile, high profit, high risk target comes from an emotional response to the idea that "all the eggs are in one basket." But they are not, not really. And the basket is huge, and the eggs are invisible and the basket is in Ft Knox. And then are a hundred baskets.
It feels really risky. But it really is not. Of course, we need to still apply all of the regular security that we normally would on top of Amazon's security. That goes without saying. Amazon just layers more and more security on top of that.
And remember, if you are encrypting your data, then breaching Amazon doesn't breach you anyway. You still have to be breached additionally. So in most high security cases, even the fear of the low risk of Amazon being breached is effectively unfounded. Even Amazon won't necessary have access to your data.
-
@scottalanmiller said in SMB resources on the move:
@stacksofplates said in SMB resources on the move:
So now, the only way for someone to get my info is to physically come in my house and take it (which is a different discussion).
There is always another means of compromise, just thinking that there isn't itself is a security risk. One that I guarantee AWS' security team (ranked the best in the world) doesn't make. They also have monitoring and people there 24x7 always watching everything with the best AI and the best human I that there is. Nothing you do gives you the tools that they have, nothing.
But beyond that, the fact that someone could grab your stuff physically alone is enough to end the discussion. Amazon effectively removes that risk. You can't physically target data at Amazon. You can't target it via software tools, you can't target it with guys and a trunk and guns. You have to attack through different vectors.
No we are talking about this
The belief that a larger company makes them a larger target, well sure that's true, but just being a little fish doesn't protect them - the tools of hackers are mostly automated today. They don't care if they are stealing $1 or millions, 1 health record or 100 thousand.
Beating someone up and stealing their credit card isn't hacking, gaining access to their bank account and using money there is hacking. This isn't a physical security discussion. That does come into play, but we are approaching from a purely technical side.
-
@scottalanmiller said in SMB resources on the move:
And remember, if you are encrypting your data, then breaching Amazon doesn't breach you anyway. You still have to be breached additionally.
And that's the same with on premise data.
-
@stacksofplates said in SMB resources on the move:
Beating someone up and stealing their credit card isn't hacking, gaining access to their bank account and using money there is hacking.
Hacking as a term for stealing data works in both cases. It's all the same thing, protecting against theft. Whether social engineering (the biggest risk to SMB), physical breach (second biggest threat to SMB) or technical means (third biggest risk) doesn't matter, we need to secure against it and look at the risk as a whole to determine our risk profile.
-
@stacksofplates said in SMB resources on the move:
@scottalanmiller said in SMB resources on the move:
And remember, if you are encrypting your data, then breaching Amazon doesn't breach you anyway. You still have to be breached additionally. So in most high security cases, even the fear of the low risk of Amazon being breached is effectively unfounded. Even Amazon won't necessary have access to your data.
And that's the same with on premise data.
Not totally, with on premises they also know whose data they have BEFORE the decrypt it. On AWS, they do not. So not the same. Not totally different, but not totally the same.
-
@scottalanmiller said in SMB resources on the move:
@stacksofplates said in SMB resources on the move:
Beating someone up and stealing their credit card isn't hacking, gaining access to their bank account and using money there is hacking.
Hacking as a term for stealing data works in both cases. It's all the same thing, protecting against theft. Whether social engineering (the biggest risk to SMB), physical breach (second biggest threat to SMB) or technical means (third biggest risk) doesn't matter, we need to secure against it and look at the risk as a whole to determine our risk profile.
No one is disagreeing with that. But the whole discussion previous to this was completely about technical, not physical.
