May 25, 2011 – 6:53 am
The answer is very. Client data is always vitally important and combining that with financial details provides a red hot issue that Banks, not surprisingly take very, very seriously.
So when a supplier like StormMQ comes along and offers a Cloud based Message Queue Service, a discerning CIO will firstly take a view of the commercial proposition (which needs to be convincing) before even considering whether the Service will stand up to the scrutiny of his or her internal audit security teams.
Assuming the commercial proposition is attractive, the next stage is usually about where will my data be held and who has access? At this point a quality Cloud based provider should start to get excited (as we do at StormMQ) as we know to what lengths we have taken to build from the ground up a Service that offers 100% guarantee of data security that will convince even the most sceptical CIO out there……
For example:
Security and data encryption
We made the decision that our Services have to be 100% secure by default so that it is actually impossible to execute insecure ways of doing things. For example, you can’t use our Services without using SSL (and as things change, we’ll be locking down the choice of ciphers and secure hashes used, too). Internally, we only use IPSec – with IKE v2 the only choice – for all local network traffic. We use whole disk encryption, too.
End Point security
StormMQ Services can only be accessed over encrypted communications. Our webservice, REST API and AMQP end points all use 2048-bit SSL and support TLSv1. For our dedicated clusters we also offer private end points and an IPSec VPN and higher encryption strengths (if your operating system supports them). We have a number of controls at our entry points to identify and terminate disruptive traffic (‘DoS’ protection).
Network Security
All messages and out of band traffic through our Messaging Cloud uses mesh IPSec VPN tunnels with x.509 authentication and 256-bit keys.
Message Encryption
All messages, meta-information and AMQP ‘frames’ arriving at an end point are transmitted encrypted throughout our Messaging Cloud. All messages persisted for later delivery are encrypted on disk using AES-256 bit keys.
User Data
Critical account data encrypted in memory and is only encrypted-on-the-fly.
REST API Authentication
To guard against various REST attacks, all operations are invoked using HMAC-SHA256 signatures.
Passwords
Our system generates all passwords and secret keys. Hashing and Message Authentication algorithms do not rely on the partly compromised MD5 or SHA1 implementations.
Server Protection
Our servers are hardened, locked down and automated to become toasters in the event of compromise using best-of-breed practices. Back-end servers are web-inaccessible. Your IT Audit teams are welcome to review our server hardening.
All critical operational information is stored encrypted on disk using AES-256 keys.
Logging
All activity is logged. We provide all our clients with a full log of all their activity through their website portal.
And Finally….
The ability to locate and secure your data means so much to us that when you take up our Service, we will sign over ownership of the encrypted hard disks we use to you as an extra option. We provide a certificate of locality and ownership of data. At the end of your subscription, we will present the disks to you for secure destruction.
Access
We only allow a subset of SASL mechanisms, but, more importantly, enforce our password policy on our users. That way, we can ensure passwords are as secure as possible. The automated systems that use messaging don’t need memorable passwords for admin! We haven’t seen clients use LDAP with our solution – primarily as most production systems have a very small set of ‘robot’ users, and the complexity involved vs using Posix file permissions
We’ve taken this further, and use the virtual hosts of AMQP to provide isolated environments for systems, so configuration managers can partition knowledge of passwords for production and development – and prevent data ‘accidents’.
Management
We provide a rich RESTful API, with language bindings, to give users the management information they need, e.g. queue depth. Of course, how they use it is up to you. One of our customers integrated it with Nagios with a couple of lines of bash. Another uses AMQP’s message timestamps to calculate ‘how stale is my data’ and warn appropriately.
Monitoring
Internally, we monitor our own systems using AMQP. SNMP is too painful (and riddled with security holes), syslog too insecure, and JMX is just… complex, heavy and without a standard transport layer. Our message formats are simple JSON – it’s easy to parse, easy to create and open to every language. One of the beauties of using AMQP for monitoring is adding resource (which happens regularly as a cloud service) requires no changes – there’s just a new publisher.
Summary
So you can see that when we are asked how safe and secure is my data, the answer is very and probably more then many companies internal data centres!
Posted in Security | No Comments »
The AMQP 1.0 protocol is almost ready to be passed back to the PMC for voting. Over the past few months this specificication has changed significantly and it is now changing on a weekly basis. Keeping track of all the activity is very hard….to help with this we have built an automated system ontop of Jenkins. We use this hevily internally, please feel free to do so too.
