Building security in – the audit paradox

28Jan12

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?



6 Responses to “Building security in – the audit paradox”

  1. If the enterprise uses static analysis tools such as HP Fortify then the security guys could gain visibility into code. Static analysis provides the ability to inspect code for things like XSS, SQL Injection and so on. If someone isn’t validating via schema, it could be flagged as unvalidated input.

    Static analysis is good for software written in-house, but you still wouldn’t have security visibility into the PaaS which you would more than likely buy. I can honestly say that I haven’t ran across a single PaaS vendor that even has the right security lifecycle to ensure their product offering is written securely. Right now it is more of a features race.

    If cloud is to be successfully leveraged by the development community, we need to do a frontal assault on the PaaS vendors as the next step..

    • Static code (and binary) analysis can certainly help, but those tools are hard to use. A proper secure software development lifecycle needs to start further back, with threat modelling – the kind of process that would identify that there is indeed (in my example) messaging, XML, and the need to validate a schema. I’m not sure that any of this (yet) answers the auditability question clearly enough. I would also add that I’ve yet to see any convincing evidence that the use of such tools and techniques leads to more cost effective development in the long term (otherwise by now I’d have expected to see a great case study from the firms who have become the poster children for SSDLC).

  2. Great points, Chris. The best security is security that’s easy to use. I really liked your point about the AWS firewall capabilities. I believe we should start putting security in the hands of the users/app-devs, making it self-service and easy to use, but in such a way that compliance is easier.

    The best security measures encourage proper use instead of acting like an impediment. Bad security is high overhead and encourages the user or developer to subvert it, which no one wants.

    Security built into the PaaS or IaaS layer such that it’s easily consumed, managed, and audited seems like a no-brainer.

  3. I beg to differ with the assertion that “Amazon, Google etc. aren’t going to let me or you show up to their data centre and install an XML gateway,”

    These XML gateways are usually just hardware or software appliances that you can install. Cloud vendors often provide quite a lot of flexibility in how networking can be configured between virtual machines on their platforms.

    In the case of Amazon, it’s just a matter of one of the gateway vendors offering their XML gateway product as an AMI. The security department can then configure the gateway into the network in front of the application servers.

    • Perhaps I was a little too fixated on XML appliances there, as most of the popular ones have specialised hardware. You’re quite right that there are software approaches that can be delivered as virtual appliances. It’s also true that cloud IaaS networking normally allows distinction between private subnets and those exposed to the public Internet (and there are VPN overlays if you need more flexibility).


  1. 1 Building/Bolting Security In/On – A Pox On the Audit Paradox! | Rational Survivability

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: