At the UK Connected Systems User Group meeting yesterday we had a good session from Imran on Azure AppFabric. We ran out of evening before the end of the session, so I didn’t get to raise this question, but it’s a crucial point for me. The Service Bus exists to easily expose internal services to the outside world. It’s an easy sell to tech guys, but I haven’t yet worked with a client’s security team who are open to the concept.
Ithink the security guys have a good point: the status quo for exposing internal services to business partners involves VPNs, DMZs, NAT, firewall exceptions etc. Imran described this as “complex”, and from a delivery point of view it may be. But from a security point of view, it’s not complex, it’s just what they do. And there are two reasons why the security guys are happy with the status quo: 1) they understand the attack surface; 2) they own the attack surface.
Understanding the Attack Surface
Microsoft have a very detailed and approachable whitepaper on how secure Azure is: Windows Azure Security Overview (PDF, login required). There are a lot of familiar and reassuring security technologies and practices in the Azure stack. It’s a shift from the attack surface they know and understand, but there should be enough for security guys to agree that the model is enterprise-grade. I would say the end-to-end is more secure than most enterprises can realistically achieve – but I’m not a security guy.
Owning the Attack Surface
This is far more important. When you’re securing your own infrastructure, the payback for all the effort is that you own the attack surface. If an attack is mounted then you should have the tools and the access needed to deal with it, which means: 1) being able to see that you are under attack; 2) being able to identify the nature of the attack and (eventually) its source; 3) having the ability to contain the attack, routing past weaknesses or (at worst) taking the service down.
With Azure playing Service Bus, the only part of the attack surface you own is your internal endpoint. Hopefully you’d see obvious things like DDOS attacks and certificate hacks, but hopefully they wouldn’t get to you anyway.
What if the attack happens outside of your infrastructure – say an attacker is able to record your service requests and responses as they route through Azure*? And say they gain access to your keys so they can decrypt the content? Ignore for the moment how difficult that would be, and the chain of failures it would need to support that attack. The question is: how do you know about it? Maybe Microsoft will send a friendly email – “hey, your service has been compromised and someone’s reading all of your traffic right now. Do you want us to take the service down or just let it run?”. Maybe it’ll take a couple of hours before they discover the attack, and a series of meetings escalating up the veep chain before clearance is given to send that email. Maybe it would take far longer to identify an attack and identify who’s been compromised.
And that’s what I think is stopping the security guys from signing off this approach. You don’t own the attack surface, so you don’t know if you’re being attacked. And if your provider does get attacked, there’s a massive public relations and commercial incentive for them to keep quiet about it.
So, steer clear of the Service Bus then?
I’d say “no, but think about what you’re exposing”. I don’t imagine we will never see a security exploit in Azure. The same is true for AWS and any other cloud service, and the worst scenarios will have to be supported by poor security practices in the exploited party. What makes the Service Bus different is that you’re dealing with core business functionality.
If someone hacks Dropbox, quietly copies all of my documents and the provider doesn’t know or doesn’t tell me, that’s bad news. But it’s static content and in any case if it’s confidential, I shouldn’t be storing it on the Internet. But if someone hacks Azure AppFabric and can read Service Bus payloads, then they know my contracts and can potentially send in their own requests to my core systems. If that’s a service exposing reference data so a business partner can show my product list, it may not be an issue. If it’s a service for business partners to submit an invoice which my financial system processes, it may be more of an issue.
This isn’t an anti-Azure post and I have no significant concerns about the security model on offer in Azure AppFabric. I use Azure for my own business services and I’m happy to recommend it to clients. The Service Bus gives you a fantastic path to getting properly connected within and between enterprises. The issue is about recognising that no system is 100% secure, understanding the worst case scenario and factoring that into your decision matrix for publishing services on the Internet.
* – relay bindings will use direct connections if possible, but it’s not always possible so you can assume a worst case that all calls will route through Azure