If you were using MongoHQ’s SSD backed MongoDB hosting, be prepared for them to be in touch as they’ve been at the sharp end of a security breach. But it’s not just direct users of MongoHQ’s services that should be concerned - users of services which make use of MongoHQ need to put on their worrying hat too. For example, MongoHQ hosted Buffer’s databases and that has been cited as the cause of the social media connector’s security breach. Another company, cloud based continuous integration specialists CircleCI, has also been compromised and issued its own security advice (through a statuspage.io supplied status page which as I write, has fallen over). They probably won’t be the only ones either.
With an interconnected set of reliant services, the services at the bottom of the stack are often the ones which have the biggest target on them. To draw a parallel, if you want to make the Jenga stack fall over going for the bricks at the bottom is a good strategy. Hitting popular data-service providers in the cloud pays big for an attacker; an original target may come with many bonus victims and the ripple out of awareness of the compromise can provide a bigger window for the attack to fill its swag bag and make out through the window. Which is why, when you are looking at a service provider in the cloud, you need to make sure they have good defences, an effective monitoring system and a notification system which lets clients react quickly… and that’s not a “service status page which updates regularly”. It’s the same list you should have for your in-house and condensate* systems too.
- systems that use cloud technology but aren’t actually up in the cloud.
This article was imported from the original CodeScaling blog