3 ms·

Of course the requirement exists for all SaaS providers. But while a break in on Evernote reveals my notes (which would be bad, but not lethal), a break in at b

Of course the requirement exists for all SaaS providers. But while a break in on Evernote reveals my notes (which would be bad, but not lethal), a break in at bastio might compromise the servers where I host my SaaS products, triggering a very nasty chain reaction. So while the risk you face may be the same, the damage that can be done is vastly greater. But I'm sure you're aware of that. Assuming someone gains root level access to one of the boxes bastio is hosted on, then he could 1a. block all outgoing traffic from the server except for the service (to avoid alarms getting through) or 1b. replay the heartbeat sent by the server 2. retrieve the database 3. Sniff on all incoming traffic for the HttpOnly Cookies The worst thing is you might not even know which customers' keys are compromised. I'm sure you are thoughtful about security, but of course you are a great target because of the valuable loot (root access lot's of other servers) A lot of your concerns are considerations for me too as I am thinking of launching a distributed SaaS. Just take it as input to your threat analysis :)

skyraider 13y ago
Yeah, definitely, it's all an input to the threat analysis. Thanks for the great discussion. It's interesting stuff and fun+important to just think through. Yes, you're right that someone could intercept the HttpOnly cookies, but as you said, only if they were able to compromise the server, since we use SSL and won't have any XSS surface. Also agree that alarm or heartbeat-based IDS stuff won't cut it here. We're working on an (agent-based, with signed code deployments) IDS (https://sentryhq.com/ https://sentryhq.com/) that sits on the server and makes decisions to take certain actions not just when an attack matches some probably-out-of-date rule, but when some ever-growing list of invariants change. It's kind of like what banks use, except it responds automatically. We will eventually be able to overcome all of these concerns (in the daemon-based model, wherein we don't store server keys) by validating OS user key distribution commands with secure emails to the people who requested them + nonces for confirmation. At that point, if we can enforce best practices amongst our customers, we can probably reduce the security problem to the trust problem, which is as solid as can be expected. Actually, what do you think about such an IDS? Usually the tactic is "let my admins respond," but you are quite correct that that isn't sufficient, as your IDS may pick up the attack but the response may never come. We are thinking that the response isn't usually fast enough either.

skyraider 13y ago

Yeah, definitely, it's all an input to the threat analysis. Thanks for the great discussion. It's interesting stuff and fun+important to just think through. Yes, you're right that someone could intercept the HttpOnly cookies, but as you said, only if they were able to compromise the server, since we use SSL and won't have any XSS surface. Also agree that alarm or heartbeat-based IDS stuff won't cut it here. We're working on an (agent-based, with signed code deployments) IDS (https://sentryhq.com/ https://sentryhq.com/) that sits on the server and makes decisions to take certain actions not just when an attack matches some probably-out-of-date rule, but when some ever-growing list of invariants change. It's kind of like what banks use, except it responds automatically. We will eventually be able to overcome all of these concerns (in the daemon-based model, wherein we don't store server keys) by validating OS user key distribution commands with secure emails to the people who requested them + nonces for confirmation. At that point, if we can enforce best practices amongst our customers, we can probably reduce the security problem to the trust problem, which is as solid as can be expected. Actually, what do you think about such an IDS? Usually the tactic is "let my admins respond," but you are quite correct that that isn't sufficient, as your IDS may pick up the attack but the response may never come. We are thinking that the response isn't usually fast enough either.