But the return on investment is likely to be far less. If it is harder, more resources have to be spent, then they will be more selective if just because it would be prohibitive to bug every system across the world, at least at present.
>But the return on investment is likely to be far less.
I am not so sure about that. The internet... well, many of the wide-open holes have been closed... BGP hijacking isn't as trivial as it was in '08[1], mostly because filtering has been implemented in some places, but it's still something that could be done by someone of, say, my resources. It's trivial to anyone with real resources.
And there are all sorts of other possible attacks. Hell, even ignoring the (probably easy, for one of the three letter agencies) possibility of putting a backdoor in the firmware shipping on popular routers, well, most ISPs end up using ancient router firmware revisions on their routers[2]
Yeah; read over that BGP hijacking attack; it sounds way easier than setting up a collector at every ISP. (You'd still need local collectors to not add too much latency, but a single (/very/ well connected) collector could cover a reasonable region)
[2]Cisco charges an arm and a leg for firmware upgrades... they give you some of the really old stuff? but usually the choice is used $BIGNAME hardware without firmware updates, or you roll-your own quagga. (at the 10G/sec traffic level my upstreams can push, quagga/vyatta work just fine... that's what I use.)
Metadata cannot be protected as well as the actual content can. One of the keys of good security is to ask what has to be compromised for your data to be compromised, though. If you have SSL-protected connections, BCG hijacking alone isn't going to reveal your communications but BCG hijacking along with a fake certificate issued by a trusted CA under court order or merely voluntarily) would allow a MITM attack.
The thing is, if you have your own CA, and expect certs from both sides from the same CA, then it is very hard for an MITM attack of this sort to be orchestrated because you can say, "Something isn't right here." So that leaves attacks against the cyphers involved or against the endpoints.
One service we offer is an ability to use an SSL cert issued by the customer, as well as appropriate VPN options to connect to the system at all. Between these, in general I would expect that MITM approaches can be protected against in high security configurations. But that still leaves cyphers and endpoints.
So the first thing we need is a better PKI which can more robustly handle fraudulent certificates. This is something I have written about a bit. (see my blog, http://ledgersmbdev.blogspot.com for more.) But we also need a lot more.
BTW, we build everything on the basis of compartmentalized security with the idea that compromising customer data will require working through quite a bit of depth, particularly in relatively high security configurations. It wouldn't protect against a court order, but it should protect against a lot of other things.
Could the NSA hack us? I am sure they could. Could we make it difficult enough that they would be much better going through legal channels (maybe making deals with local law enforcement or the like)? That's what I am shooting for. It is probably the best one really can shoot for.
>Could we make it difficult enough that they would be much better going through legal channels (maybe making deals with local law enforcement or the like)? That's what I am shooting for. It is probably the best one really can shoot for.
Yeah; my point was just that getting to that point (where it's easier for them to go through legal channels) is harder than it looks. It's certainly not the default state.
> Yeah; my point was just that getting to that point (where it's easier for them to go through legal channels) is harder than it looks. It's certainly not the default state.
As we went through our initial design, and started talking to others, it became quite clear that the being industry standard when it came to security is not something that either myself nor my business partner were comfortable with. We opted to start looking at everything very carefully and review eachothers' works regarding security, suggesting improvement, etc.
It's one of the reasons we decided to go hosted cloud first and only later multi-tenant.
>It's one of the reasons we decided to go hosted cloud first and only later multi-tenant.
So by 'hosted cloud' you mean 'every user gets their own VM?' I mean, you could mean that you use on-demand dedicated servers, but most people mean virtual instances when they say "cloud" (I hate that word "cloud" - it's so vague)
(personally, i still think of multiple VMs on one physical box as multi-tenant. But managing a VPS per user? thousands of times easier than managing a user-account per user and just having a bunch of users on the same box. In my opinion, more secure, too.)
How are you managing images? I mean, that's the thing you've gotta watch for, a backdoor in the install image.
One thing I've noticed about my customers is that they almost all prefer to use my image than to do a net-install. (I give my xen users a paravirtualized boot loader, so they can load the distro install kernel and go from there.) the interesting thing is that my dedicated customers are far more likely to do their own install (I provide only... a very rudamentary PXE menu.)
Or, maybe that's just my perception because I only notice what OS they are running when they ask for help... whereas on the dedicated servers, I've recently had to move a bunch of them, which required me to look at consoles. So I guess there could be a bunch of arch users or something like that who just don't ask for help.
It does seem like having your own physical hardware would make... a big difference, security-wise.
Again, I don't understand why you think that it's harder for the NSA to hack / bribe / trick their way into data than it is to have to obtain court orders and convince everyone to work with them.