This is a long overdue reply to Chris Hoff’s (@Beaker) ‘Building/Bolting Security In/On – A Pox On the Audit Paradox!‘, which was his response to my ‘Building security in – the audit paradox‘.

Hopefully the ding dong between Chris and I will continue, as it’s making me think harder, and hence it’s sharpening up my view on this stuff. If you want to see some live action then I’ll be on a panel with Chris at ODCA Forecast on 12 Jun in NYC[1].

CC photo by England

I suggested in my original post that platform as a service (PaaS) might give us a means to achieve effective, and auditable, security controls around an application. When I wrote that I assumed that the control framework would be an inherent part of the platform, but it doesn’t have to be. Perhaps we can have the best of both worlds by bolting security in.

Bolting

By this I mean optional – a control that doesn’t have to be there. Of course we can expect a PaaS to have a rich selection of basic security controls, but it would be silly to expect there to be something to suit every need. It would however be great if there was a marketplace for additional controls that can be selected and implemented as needed.

As Chris points out this has already happened in the infrastructure as a service (IaaS) world with things like introspection APIs giving rise to third party security tools. Many of these look and smell like the traditional bolt on tools for a traditional (non service delivered) environment, but how they work under the hood can be much more efficient.

In

By this I meant in the code/execution path – a control that becomes an integral part of an application rather than an adjunct. Bolt on solutions have traditionally been implemented in the network, and often have some work on their hands just to figure out the context of a fragment of data in a packet. Built in solutions are embedded in the code and data (and thus don’t struggle for context) but can be hard to isolate and audit. Bolt in solutions perhaps give us the best of both worlds – isolation for an auditability perspective and integration with the run time.

The old problems don’t go away

When asked ‘why do we still use firewalls’ a former colleague of mine answered ‘to keep the lumps out'[2]. It’s all very well having sophisticated application security controls, but it’s still necessary to deal with more traditional attacks. I’d skirted over this on my original post, but Chris did a good job of highlighting some of the mechanisms out there (which I’ll repeat here to save bouncing between articles):

1. Introspection APIs – I already referred to these above. They’ve primarily been used as a way to do anti virus (which is often a necessary evil for checkbox compliance/audit reasons), but there’s lot of other cools stuff that can be achieved when looking into the runtime state of a machine.
2. Security as a service – if a security based service (like content filtering or load balancing) isn’t implemented in one part of the cloud then get it from another.
3. Auditing frameworks – these potentially fit three needs; checkbox style evaluation of controls before choosing a service, runtime monitoring of a service and it’s controls, and an integration point for newly introduced controls to report on their status (after all a control that’s not adequately monitored might as well not exist).
4. Virtual network overlays and virtual appliances – the former provides a substrate for network based controls and the later a variety of implementations.
5. Software defined networking – because if reconfiguration involves people touching hardware then it’s probably not ‘cloud’.

Conclusion

Moving apps to the cloud doesn’t eliminate the need for ‘bolt on’ security controls, and brings some new options for how that’s done. ‘Building in’ security remains hard to do and even harder to prove effective to auditors (hence the ‘audit paradox’). ‘Bolting in’ security via (optional modules in) a PaaS might just let us have our cake and eat it.

[1] I have some free tickets for this event available to those who make interesting comments.
[2] I’ve got an odd feeling that Chris Hoff was in the room when this was said.