[lsc]

>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)

[1]http://www.defcon.org/images/defcon-16/dc16-presentations/de...

[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.)

[einhverfr]

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.

[lsc]

>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.

[einhverfr]

> 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.

[lsc]

>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.

[einhverfr]

We can do either but our default is vm's, just because for smaller businesses that is a lot more practical. Customers typically do not have root access to their VM's unless they supply their own keys/x509 certs so we can take ours off. If we are managing the box we have, for example, stored root passwords (rarely needed and only two people have access) encrypted in PostgreSQL (which means we do not log when we are not debugging and we do not allow history to be stored since manual keys must be entered when retrieving this info).

> How are you managing images? I mean, that's the thing you've gotta watch for, a backdoor in the install image.

It's not the only thing you have to watch out for. If someone can compromise the host they should be able to compromise all vm's given a little time. We do have some automated ways of checking for changes though. In general the physical hosts are much less exposed but cannot guarantee that more generally. We are always discussing ways to tighten security (I am considering setting up a rediculously tight selinux policy on the physical hosts).

> It does seem like having your own physical hardware would make... a big difference, security-wise.

The big difference is actually where the hardware is located. The big difference is really having your own physical hardware on your own premises on your own intranet vs using someone else's physical hardware in their datacenter, with their intranet. In general though if you have someone else's hardware on your intranet you can better control it than if you have your hardware somewhere else.