Building/Bolting Security In/On – A Pox On the Audit Paradox!
My friend and skilled raconteur Chris Swan (@cpswan) wrote an excellent piece a few days ago titled “Building security in – the audit paradox.”
This thoughtful piece was constructed in order to point out the challenges involved in providing auditability, visibility, and transparency in service — specifically cloud computing — in which the notion of building in or bolting on security is debated.
I think this is timely. I have thought about this a couple of times with one piece aligned heavily with Chris’ thoughts:
Chris’ discussion really contrasted the delivery/deployment models against the availability and operationalization of controls:
- If we’re building security in, then how do we audit the controls?
- 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?
Further, as part of some good examples, he points out the notion that with separation of duties, the ability to apply “defense in depth” (hate that term,) and the ability to respond to new threats, the “bolt-on” approach is useful — if not siloed:
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.
…versus building secure applications:
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.
I don’t disagree with this at all. Code security is hard. People look for gap-fillers. The notion that Chris finds limited options for bolting security on versus integrating security (building it in) programmatically as part of the security development lifecycle leaves me a bit puzzled.
This identifies both the skills and cultural gap between where we are with security and how cloud changes our process, technology, and operational approaches but there are many options we should discuss.
Thus what was interesting (read: I disagree with) is what came next wherein Chris maintained that one “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.
While it’s true that CSP’s may not enable/allow you to show up to their DC and “…install and XML gateway,” they are pushing the security deployment model toward the virtual networking hooks, the guest based approach within the VMs and leveraging both the security and service models of cloud itself to solve these challenges.
I allude to this below, but as an example, there are now cloud services which can sit “in-line” or in conjunction with your cloud application deployments and deliver security as a service…application, information (and even XML) security as a service are here today and ramping!
While immature and emerging in some areas, I offer the following suggestions that the “bolt-on” approach is very much alive and kicking. Given that the “code security” is hard, this means that the cloud providers harden/secure their platforms, but the app stacks that get deployed by the customers…that’s the customers’ concerns and here are some options:
- Introspection APIs (VMsafe)
- Security as a Service (Cloudflare, Dome9, CloudPassage)
- Auditing frameworks (CloudAudit, STAR, etc)
- Virtual networking overlays & virtual appliances (vGW, VSG, Embrane)
- Software defined networking (Nicira, BigSwitch, etc.)
Yes, some of them are platform specific and I think Chris was mostly speaking about “Public Cloud,” but “bolt-on” options are most certainly available an are aggressively evolving.
I totally agree that from the PaaS/SaaS perspective, we are poised for many wins that can eliminate entire classes of vulnerabilities as the platforms themselves enforce better security hygiene and assurance BUILT IN. This is just as emerging as the BOLT ON solutions I listed above.
In a prior post “Silent Lucidity: IaaS – Already a Dinosaur. Rise of PaaSasarus Rex”
As I mention in my Cloudifornication presentation, I think that from a security perspective, PaaS offers the potential of eliminating entire classes of vulnerabilities in the application development lifecycle by enforcing sanitary programmatic practices across the derivate works built upon them. I look forward also to APIs and standards that allow for consistency across providers. I think PaaS has the greatest potential to deliver this.
There are clearly trade-offs here, but as we start to move toward the two key differentiators (at least for public clouds) — management and security — I think the value of PaaS will really start to shine.
My opinion is that given the wide model of integration between various delivery and deployment models, we’re gonna need both for quite some time.
Back to Chris’ original point, the notion that auditors will in any way be able to easily audit code-based (built-in) security at the APPLICATION layer or the PLATFORM layer versus the bolt-on layer is really at the whim on the skillset of the auditors themselves and the checklists they use which call out how one is audited:
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?
This is a very simplistic example (more infrastructure versus applistructure perspective) but represents the very interesting battleground we’ll be entrenched in for years to come.
In the related posts below, you’ll see I’ve written a bunch about this and am working toward ensuring that as really smart folks work to build it in, the ecosystem is encouraged to provide bolt ons to fill those gaps.
/Hoff
Related articles
- From the Concrete To The Hypervisor: Compliance and IaaS/PaaS Cloud – A Shared Responsibility (rationalsurvivability.com)
- Incomplete Thought: Why Security Doesn’t Scale…Yet. (rationalsurvivability.com)
- I’ll Say It Again: Security Is NOT the Biggest Barrier To Cloud… (rationalsurvivability.com)
- Hack The Stack Or Go On a Bender With a Vendor?
- Incomplete Thought: Why Security Doesn’t Scale…Yet,
- What’s The Problem With Cloud Security? There’s Too Much Of It…,
- Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are…
- Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…
My $0.02 – “Built In” will only happen when either IT owns security or the security professional is brought in AT THE BEGINNING to help design security into the solution. Until IT recognizes that security design is just as (if not more) important than network and storage design, the “solution” to the uneducated security professional will be to build a wall around virtualization/cloud and call it secure. That negates the use of all the cool toys like vShield/VSG/etc… And leaves the business vulnerable.
mike
All i’m seeing is cloud computing everywhere. Sites like http://www.dropbox.com, https://www.mypdv.com and so on are storing data inside of them. Then there is sites such as facebook who are taking up huge amounts of data storage. I think it would have been impossible to see such a thing only a few years ago.