Interview: John Howie, COO at the Cloud Security Alliance

In today's interview, I have the pleasure of talking to John Howie. John is the Chief Operating Officer at the Cloud Security Alliance. John has over 20 years of experience in information and communications technology in a variety of industry sectors, from financial to telecom, and entertainment to education.  

Today, we discuss the mission of the Cloud Security Alliance and what the organization seeks to accomplish. John talks about "The Notorious Nine: Cloud Computing Top Threats in 2013" and how people are responding to data breech and other security threat categories. I also ask John's take on the acceleration of software development on the cloud, mobile, dev ops and software-defined networking.

The following is a brief excerpt of our interview. 

Jeff Williams: Software development has been accelerating dramatically over the past few years. And I feel like Cloud and mobile and dev ops and software-defined networking and all those things are starting to really pick up speed and the tools are getting much better. Things like Chef and Puppet are allowing the use of Cloud in software development.

What's your take on the effect of that acceleration on security?

John Howie: That's a great question and a multifaceted question with a number of different answers. So let's see how I can try and provide a concise, clear answer to that.

I think you have to understand that the increasing capabilities of software development tool sets are benefiting both providers and consumers. That is the first thing to say. However, with the increasing power and flexibility comes increasing responsibility as well and you need to be careful about what you do.

From a provider's standpoint, we have a seen a move towards agile development and dev ops. And in some cases, this will come into conflict with traditional notions of security.

If you look at, for example, ISO 27,001, the Information Security Management System Standard, NX1 is the control set from 27,002 and it talks about separation of environment. It talks about the old, classic software development model of software development environment or software test environment. A pre-production environment to test those releases in and then your production environment.

And you should never conflate these or allow developers access to pre-production environments. In fact, if you do that, depending on what your auditor is looking for, you could fail your audit. 

In the case of payment card industry data security standards. Which, if you process credit cards and you accept monies in excess of a certain threshold--typically $500,000-- you are going to have to comply with PCI DSS and it has very similar language.

So the problem is that the Cloud providers are running at such significant scale; we are talking tens of thousands of servers in data centers, in multiple data centers worldwide. You cannot replicate those environments in dev, test, pre-prod and prod.

So inevitably, the walls are going to start to fall down. Or start to crumble. And you're going to start to see developers potentially having access to production environments. Certainly, developers are going to be developing software production environments because it turns out it's far cheaper to develop in a production environment on virtual machines rather than on your desktop. There's a number of studies that show that.

And so, how do you as an information security practitioner, understand this? Understand that the scales that we're working at are vastly different from the mainframe era. Which a lot of these security standards were written for and are still applied to today. Or a limited number of servers and desktop environments.

You're talking tens of thousands of servers. And hundreds of thousands of virtual machines running on them. So we've got to, as information security practitioners, look at dev ops and agile development from a provider standpoint. And to start to realize that guess what? The rules are changing. How can we permit developers' access to production environments? What compensating controls can we put in place to address these issues and provide, still, the necessary reassurances to consumers that developers don't have access to their data, their production data?

How do we make sure the development activity in production environments doesn't disrupt running production systems? Which are not part of development activity. Those are challenges which we have to look at the face on the Cloud provider site. And there's a lot of work being done in this space, a lot of fantastic research done by the Cloud Security Alliance and others.

On the Cloud consumer side, you're also seeing a shift as well. Now, in the old days of Cloud computing--which is kind of laughable because we're talking seven, eight years ago, the old days. What you'd do is you'd rent a virtual machine or virtual machines from your Infrastructure as a Service provider and back then, there was one and it was Amazon; now there's other options.

And you would write your software on top of, typically, the LAMP stack. Linux, Apache, My SQL, PHP. And you'd go live. Or you'd have some combination thereof. You might use Tomcat, Java, whatever. But you'd be responsible for securing the entire virtual machine. The operating system, the server software, which is your web server. Your managed software environment. And then your own software, including [inaudible 00:22:26]. Software updates, fine-tuning the environment using host-based firewalls, configuring security, managing identity. Real nightmare of stuff. In other words, you were virtualizing your data center and sticking it in the Cloud.

Guess what? If you have a hairball in your data center today and you move to the Cloud and you have a bigger hairball in the Cloud. If anything, you're actually increasing to your security troubles.

So we've seen the rise as Platform as a Service as a viable option for many Cloud consumers. And this allows them to write their own custom software and deploy it to the Cloud. But they no longer have to worry about the operating system. They no longer have to worry about the server software, the web servers, the database servers, the managed software run-time environments. That's managed for you by the Cloud provider.

All you have to be concerned about is writing the software that's deployed to the Cloud and making sure it works, so the Cloud environment and your application level security controls are in place.

And so, you are seeing this sea change away from Infrastructure as a Service towards Platform as a Service. Because it reduces the security operations burden for the Cloud consumer.

The ideal nirvana, of course, is Software as a Service. Because the bulk of all security is done by your Cloud provider and to the extent that you're running document collaboration or unified communications or e-mail systems. You're no longer going to use Infrastructure as a Service and run your own e-mail servers, your own document collaboration servers and so on. You're going to go procure that service at the Software as a Service level knowing full well that there's probably the ability to customize that with modules that you write or you can upload or customize in the Cloud environment.

So we are seeing a change in software development from a Cloud consumer side. And moving away from Infrastructure as a Service towards Platform as a Service. And in some cases, to Software as a Service. And the goal there is to reduce the attack surface. That has to be managed by the consumer and shift a lot of the responsibility over to the provider.

Jeff Williams: That's interesting. You think that the tide is sort of rising and security is getting more and more provided by the Cloud providers and then the Platform providers and the SaaS providers.

Is there a point at which developers just aren't going to need to care about security very much?

John Howie: Yeah. That's going way too far.

Jeff Williams: Okay, good. I wanted to make sure we were on the same wavelength there.

John Howie: That's kind of like the nirvana of where you could write really bad code that it doesn't matter. At the end of the day, your software developers have to be aware of the target environment that their software is running.

They have to understand the security capabilities and features of that environment. So for example, if I'm writing a Web application which allows people to log in and get access to stored content, do I write my own authentication and authorization mechanism? Which maybe means creating a table and a database of usernames and passwords and access levels.

Or does a Cloud provider in their environment if it's Platform as a Service, already do that for me? Or even better, for Software as a Service, is there already a similar service out there that I can just customize so I don't have to write any code at all? Or very little code?

And so, you're seeing the Cloud provider step up with these solutions. But at the end of the day, your developers need to know what environment their software will run in. Where the threats are; they have to go through threat modeling. Just as they do for traditional software development.

They still have to follow best practices following guidance from OWASP and SAFECode and CSA. And CSA and SAFECode actually just released a joint guidance recently around secure software development for the Cloud. And they have to be aware of where the threats are and where potential vulnerability lies and how those threats can exploit those vulnerabilities.

So, no. Developers will always have to understand security to some extend and they'll always have to be trained about security. But the biggest thing is, software developers have to understand the security provided to them by the platform and then take advantage of it.

Jeff Williams: I totally agree with that. I'm a huge advocate of standardizing security controls. I've been pushing organizations for a long time to try to create an enterprise security API for themselves and it sounds like maybe Cloud-type platforms are a way of doing that in a very sort of practical way of getting those controls out to developers.