My friend Randy Bias very kindly came in and did a web conference presentation at work this week on his views of cloud computing (which are well summarised in a post he did at the end of last year). Inevitably the topic of security came up, and Randy, drawing on his past experience in the world of infosec, strongly advocated building security in rather than bolting it on. I’m also a fan of this approach, but it raised a couple of questions for me:

1. If we’re building security in, then how do we audit the controls?
2. Will platform as a service (PaaS) give us a way to build security in such that it can be evaluated independently of the custom code running on it?

The audit paradox – my first encounter

A few years ago I was approached by a team that wanted to build a client facing web service. I explained that they’d need an XML gateway/firewall, and that we’d been looking at various solutions in the marketplace. They asked why such an expensive beast was necessary, so we got into the details of XML attacks and mitigations. I’ll pick on just one thing – schema validation. The XML appliance – a piece of bolt on security – could validate an incoming message to ensure that it conformed to the expected schema.

CC photo by arbyreed

‘No need for that’, they said, ‘we can follow the MSDN guidelines for schema validation’ (they were using .Net) – this was a genuine offer to build security in rather than bolt in on. ‘I think the IT Risk and Security guys will have a problem with that’, was my response, ‘how do they know that you’ve done it right?’.

There lies the issue – bolt on security is easy to audit. There’s a separate thing, with a separate bit of config (administered by a separate bunch of people) that stands alone from the application code.

Code security is hard. We know that from the constant stream of vulnerabilities that get found in the tools we use every day. Auditing that specific controls implemented in code are present and effective is a big problem, and that is why I think we’re still seeing so much bolting on rather than building in.

Can’t bolt on in the cloud

One of the challenges that cloud services present is an inability to bolt on extra functionality, including security, beyond that offered by the service provider. Amazon, Google etc. aren’t going to let me or you show up to their data centre and install an XML gateway, so if I want something like schema validation then I’m obliged to build it in rather than bolt it on, and I must confront the audit issue that goes with that.

PaaS to the rescue?

‘Constraints can be a win’ is one of Randy’s comments that sticks in my head. What if the runtime platform has the security built in rather than my custom code? What if security functionality, such as schema validation, is imposed rather than optional, and it’s the platform that I audit (once for all the applications)? That truly would be a win.

CC photo by WorldSkills

PaaS offers the promise of being able to do this, but frankly we’re not there yet. If we look at the antecedents of PaaS – the language frameworks, then there is cause for cautious optimism in the long term – e.g. Spring Security came along some time after Spring. A change in emphasis is needed though – security frameworks normally have lots of stuff that can be used, but precious little that must be used. If we return to the problem of auditability, the problem that must be solved is clearly providing evidence of a control and its effectiveness. This means that it must be always on, or clearly expressed in some configuration metadata rather than buried in code

Infrastructure as a service shows us that this can be done e.g. the AWS firewall is very straightforward to configure and audit (without needing to reveal any details of how it’s actually implemented). What can we do with PaaS, and how quickly?