SMB resources on the move
-
@Francesco-Provino said in SMB resources on the move:
@scottalanmiller I think that sometimes AWS or other public clouds are the way to go, because often the ERP or CRM are old-style windows applications that are available only for on-permise deployments.
That's a halfway approach. There are basically three ways to handle these kinds of systems:
- On Premises / Legacy where you run your own server and put the software on the LAN
- IaaS like you propose here. Taking the legacy system and just moving it to AWS or the like. This is a bandaid. It's generally an improvement, but only barely and often not cost effective.
- SaaS. The real solution. No reason to run your own infrastructure, let the vendor do it.
MS CRM, for example, has been available as SaaS for years. It's part of Office 365 already. Fully integrates with all of the rest of the suite.
-
@Francesco-Provino said in SMB resources on the move:
I'm very curious about that because I'm going to switch a company to D4B and I want to make a comprehensive evalutation of the alternatives…
There are lots of competitors these days. Google Drive gets a lot of attention, too. And there is Box. And you can get ownCloud hosted by Datto. And there is SmartFile. And you can run your own with NextCloud and others. So many options.
-
@scottalanmiller said in SMB resources on the move:
@thwr said in SMB resources on the move:
No matter what the vendor says, you can't audit their systems and processes in any way to be sure about the privacy of the data. And even if the vendor guarantees total privacy, what about a hack? Just a small security hole may leave tens of thousands of customers (read: SMBs) with their pants down.
That's sort of true, but it's incorrect thinking. It's the security equivalent to looking at "how many drives can fail in my RAID array" rather than asking "how reliable is the array?" By worrying about auditing, for example, we are immediately looking at paper pushing instead of the reality of security. No matter how little you can audit Amazon, they are more secure than any SMB, ever. Would it be nice to audit them? Sure. Is it required for them to be more secure, nope. Auditing doesn't make something secure. In fact, as PCI companies show over and over, auditing might actually make something insecure. Just like ITIL can be the cause, rather than the cure, to business workflows.
Basically, we get caught thinking that the means matter, rather than the ends. Or we are looking at proximates instead of goals.
No matter what the vendor says, you can't audit them. But no matter what you do with an SMB, you can't get them as secure. So which is better, not auditing but getting better security? Or auditing and getting worse security.
Depends... is your goal politics, or results?
@scottalanmiller : I can understand (and partly agree with) your point. From a (pure) technical point of view, everything cloud would be better for a lot of factors like reliability (given a fast and redundant uplink), security, energy consumption, zero server-side hardware costs and so on. That's not even a question IMHO. I totally agree with you that a small IT department can't get you the same level of security, how to say, not the level a whole security division at Amazon or MS Azure will give you. On the other hand, great danger may occur when someone finally hacks one of the cloud platforms. The question is not if, but when. And in this case, all your customers credentials, construction plans, research results, medical files, internal financial data, marketing strategies, generally confidential material etc may be in danger.
-
@thwr said in SMB resources on the move:
On the other hand, great danger may occur when someone finally hacks one of the cloud platforms. The question is not if, but when. And in this case, all your customers credentials, construction plans, research results, medical files, internal financial data, marketing strategies, generally confidential material etc may be in danger.
Not really, this is an illusion. This only seems worse because it is a shared platform. The fact that the breach itself would be worse is irrelevant to the individual businesses. That it would be worse to the provider and to the news media is true, but doesn't matter to us as IT pros or to the businesses we represent. Consider these two scenarios:
- 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.
There are two enormous reasons why this means that going to the cloud is better. First, the chances that #1 will happen is vastly higher than #2. The first happens all the time, the second has never happened yet. Nearly every SMB gets hacked as it is. So reducing the chances of getting hacked with the same exposure risk when hacked is a no brainer win.
The second factor is that in the case of #1, when a breach occurs, it is purely the SMB's fault. They used hubris and emotion to make a security judgement call and lost. That's not something that they could defend easily in court, to customer, to investors, etc. Basically they took a risk and bet against known security principles and did what is known to increase their risk. But if #2 happens they get to show that at least they did the best job that they could, used logic, statistics and industry security knowledge to reduce risk as much as possible AND they have someone else who is at fault to blame.
Lower risk, lower impact in case of a breach. It's pure win from a security perspective.
-
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.
-
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.
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.
-
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.
-
@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.
But that doesn't matter, risk still lower. WHY it happens might be interesting in some way, but it doesn't change the base fact that you were safer and that everything else is a red herring - getting lost in the means and forgetting the end goal.
But it brings up an interesting point. If an SMB is targeted, the breach will be of their data. If the provider is targeted and an SMB gets swept along with it, the chances of their data being found and utilized and identified remains close to zero. So there is yet another layer of protection in a cloud breach scenario due to not being targeted. So still safer yet.
-
@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.
-
@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.
