How to Tackle Cloud Infrastructure SecurityCloudPassage's Carson Sweet on Merits of the New Model
Infrastructure security used to be more manageable. But it's far more complex in today's cloud environment. Carson Sweet of CloudPassage shares insight and strategies to improve cloud infrastructure security.
Several key factors influence the complexity of infrastructure security, and the first is the virtualization itself, says Sweet, CEO and co-founder of CloudPassage.
"As we see more infrastructure moving from a traditional hardware deployment model to virtualized servers, virtualized networks, software-defined networks, etc.," Sweet says, "these virtualized environments obviate the ability to control the actual physical underlying infrastructure."
And "control" is an operative word. In the old model, organizations had critical systems and servers behind their own four walls. Today, these elements are increasingly in public clouds, where security leaders have less direct control. "That's a complexity that security organizations are struggling with," Sweet says.
In an interview about cloud infrastructure security, Sweet discusses:
- Factors making infrastructure security increasingly complex;
- Why in-house solutions are so challenging;
- Lessons learned from pioneers of third-party cloud infrastructure security services.
Sweet's information security career spans nearly two decades and includes a broad range of entrepreneurial, management and hands-on technology experience.
A senior information security strategy and technology consultant, he has created groundbreaking security solutions across a range of industries and public sectors. Prior to co-founding CloudPassage Sweet served as RSA's principal solutions architect for the financial services sector, where he specifically focused on virtualization & cloud security, Internet application controls, data protection and anti-fraud.
How to Tackle Cloud Infrastructure Security
TOM FIELD: What are some of the factors that have caused infrastructure security to become dramatically more complex for organizations?
CARSON SWEET: It used to be fairly straightforward, because infrastructure was very static and relatively slow-moving in terms of the rate of change. There are several factors that have changed the way that security organizations have to come at security for infrastructure, and limit them in many ways to what they can do. There are about five I'll touch on very quickly.
The first is virtualization of the infrastructure itself. So, as we see more infrastructure moving from a traditional hardware deployment model to virtualized servers and networks, these virtualized environments obviate the ability to control the actual physical underlying infrastructure. The physical underlying topologies, IP addressing and so forth, are now very dynamic and determined by computer systems as opposed to being relatively fixed. That causes a big problem because we've relied on these fixed physical environments and the ability to put hardware devices directly into the hardware components of the network itself in order to make security work. So the virtualization of all things infrastructure is probably the biggest challenge [to] security organizations.
The second is control. The infrastructure environments used to be essentially, data centers. So everything was behind our four walls; the bad guys were on the outside, we had firewalls and layers of perimeter security to protect the good stuff on the inside. And that was a very simple model. Now we're actually pushing things out into public cloud environments in many cases and even financial services are heading down this road; the benefits of that model and simply too compelling to ignore. And as a result, we suddenly are in a situation where you don't control the physical environment again, you don't control the operational environments. You're really limited to the virtual devices themselves in terms of what you can touch and make security modifications to. So that's a complexity that security organizations are struggling with.
The third is more platforms. We had our hardware platforms and a few hypervisor platforms. Most organizations had one or two, and that was it. With very modern, contemporary data center infrastructure environments, you're looking at multiple virtualization platforms internally. You're looking at VMware, V-Cloud. Most organizations are working with open stack now. Then when you start to add public cloud environments into the mix, particularly organizations who are growing through acquisition, you could end up with two, three, four different public cloud providers like Amazon Web Services, Rack Space and IBM Software. So just the sheer number of environments, and the fact that each one of these environments has different capabilities and constraints, is a very complex problem.
The level of distribution from applications is really different. It's very similar to back in the '90s when we went from mainframe base computing to a client server distributed computing. That distribution of the computing elements off of one giant computer to many smaller computers that were relatively close to each other physically has now once again evolved into an environment where it's desirable from a computing perspective to broadly distribute these computing resources. When you start to think about the way we've done security for years, very heavily reliant on network security and physical topology and proximity of things to one another, that massive distribution that cloud as a structure enables creates challenges in the old models.
Finally, the rate of change, and this is one we hear a lot. The rate of change in a traditional data center environment was relatively slow. Changes did happen, but they happened on the order of magnitude of weeks to months typically. The application is now the application deployment models that are using cloud infrastructure. These infrastructure environments are truly software to buy, and they start to look a lot like software in terms of the rate of change. Change is fundamentally the enemy of security and compliance. If you build a system, it doesn't change much; it's static. You can prove it hasn't changed. As things do continue to change, however, and the rate of change increases, there's just more raw work that the security and compliance organizations have to do to continually verify and prove to auditors and regulators that those environments are still in a state that meets regulatory requirements and all standards.
FIELD: How does the regulatory landscape further challenge organizations when it comes to securing their infrastructure?
SWEET: Financial services is one of the most regulated sectors in the world, obviously. The regulators and auditors, they're getting their heads around cloud. They're realizing that this is a very different model and that there are new risks that have been introduced. And they're really putting a lot of focus on that. We're hearing much more about auditors that are focused on transformation from a traditional environment that's been in a pretty steady state for years, and everybody knows how security is getting done, they're very comfortable with it. When auditors see a major disruption like cloud infrastructure, they put themselves on red alerts. So the fear, uncertainty and doubts that the regulators and auditors come in with, which translates into scrutiny and the amount of attention that those environments get, is amplified dramatically. So within FinServ, and particularly any other heavily regulated industry, these areas are getting even more scrutiny around cloud infrastructure transformation. So that makes it harder on the other side of the equation for the security and compliance organizations. On the one hand, they've got a whole new environment they have to deal with. They've got a whole set of tools they have to figure out. On the other side, they've got regulators and auditors that are deeply scrutinizing these environments because they are new. So it does make things more complex.
Biggest Security Gaps
FIELD: In terms of tools and skills, where do you see organizations having their biggest security gaps?
SWEET: I think it really is in tools. That's probably the biggest challenge that we hear and see. Really the interesting thing about the infrastructure environments is that the requirements haven't changed much. You still have a very specific set of requirements that have to be met, and those requirements, like your Sarbanes-Oxley, FFIEC standards, and so on, they change slowly. So you still need to deliver strong access control. You still need to deliver configuration and validation. You still have to deliver threat management. You still have to delivery visibility and oversight into all these different environments, including the change. So the requirements haven't changed; what's changed are the delivery parameters. Now you have to be able to deliver all of those things in an environment where you don't always control the physical; you don't always have control of the network; you don't always have the ability to dictate the way that hardware is being built. You don't have the ability to deploy hardware-accelerated appliances in the network because all that's been virtualized, and a lot of it is now not in your control. So the lack of tools that reconcile the need to deliver the existing standards that we've done for years in this new technical environment, that's really the challenge.
So the question for security organizations is, "What do we do next now that we can't rely on perimeters, we can't rely on appliances, we can't rely on hardware, accelerated security functionality; how do we do security next?" The security market has struggled to come along and figure out the right models, and that's one area that we focused heavily on as a company, is what is a model that works in any of these environments, that works at the kind of scale and the rate of change that financial services and other organizations are seeing as they make a transformation. So, really, tools are the big challenge.
In terms of skill sets, the hot new skill we're seeing security organizations struggling to procure/ acquire is big data. The amount of change associated with these cloud environments, for example, a big data analytics capability that comes up for a few weeks in a year, that's still in scope for an annual audit. So the amount of data that's got to be collected, crunched, sliced, diced and presented to auditors, and also the amount of data that's got to be considered and analyzed for threat analytics, vulnerability scanning, all the things you think about in a relatively slow-moving environment, those are really becoming big data problems, and that's one of the ways we approach it. So we do see organizations struggling to get the big data talent. That's a very hot space in and of itself; the ability for security organizations to pry big data analysts away from the big data companies out there, it's very difficult to do. So that's probably the single biggest skill area that we see sort of some challenge in.
FIELD: What are the pros and cons of trying to build in-house solutions?
SWEET: Probably the biggest challenge with trying to build in-house is, honestly, just making it work. CloudPassage invested about $20 million and spent about two years really getting the model that we deployed right, and making it work in any environment at scale. It is tempting, particularly for organizations that are using lots of open source, have big development teams or have big security teams. But the reality is, each time we see a major disruption in cloud infrastructure, it is a bigger disruption than anything we've seen since distributed computing. There is always this need to figure out how to get it right. And in the past we've seen organizations not just with cloud infrastructure, but with other areas of security that required evolution. They tried to build it themselves, experiment. They may actually build something. The thing that comes to mind immediately is key management - lots of organizations built their own encryption key management, but they soon learned they don't want to own it. So they'll try to build it, they'll get a team that's enthusiastic about it, but soon realize that it has to be maintained. That infrastructure itself is going to be audited, there is a lot of security controls and so forth that have to go into that. So for an organization to build that themselves can be a real challenge.
There are three major disruptions, not just cloud infrastructure, but other disruptions that the security organizations are having to deal with. [One of the largest] ones outside of cloud infrastructure is software as a service. So these organizations are using SaaS applications. Security teams have to deal with that security and risk issue. The second big one outside of cloud infrastructure is mobile. Bring your own device - how do you secure those mobile devices? Security teams have a triple whammy that has landed on top of them. They have to deal with cloud infrastructure transformation, mobile device security and SaaS utilization. They really don't have time to go out and build their own thing, and that's one of the reasons that we've had good success with organizations coming to us, and in many cases deploying the product that we provide because it does address the need. It doesn't distract the relatively limited resources that they have to focus on going out and creating a product.
Third-Party Cloud Infrastructure
FIELD: What are some of the pros and cons of aligning with a third-party cloud infrastructure security service?
SWEET: The biggest one is speed to value. These issues have hit the security organizations quickly. They are no longer able to stand in front of the cloud train and say, "No, we're not going to do it." The benefits of cloud infrastructure are just too great. The flexibility, the ability to get to market faster, to use op ex dollars instead of cap ex dollars, all of these things are extremely compelling to the businesses. So the security organizations really have been hit with this problem very quickly, just in the last two years. They haven't had time to ramp up. They haven't had time to get ready. And no one's walking into the CISO's office and saying, "Okay, you need to deal with cloud security, SaaS and mobile and here's 50 more people that are being asked to do this with the resources they have today." So they're looking for something that is quick, and can scale economically to help them address the cost issues with this. Many of the solutions that are out there today - most are relatively new - are built to that. That's one big benefit.
The second is that the solution providers, like CloudPassage, have been down this road dozens of times already, and we've modified our product over time. So we're not starting from zero. So these companies get the benefit of us having looked at this set of problems, addressed [it], stepped on the mines, [and] figured out how to get around the issues so they don't have to do that.
The third big benefit that they have is, they don't have to maintain it over time. So again, given the amount of new requirements that security organizations have on top of them today, they don't have a requirement ongoing to sort of care for the systems. Using a third-party solution gives them the ability to simply sit in a chair, pilot the solution, and not have to worry about actually building it and maintaining it, which is a huge undertaking in and of itself.FIELD: What can we learn from the experiences of some of these cloud pioneers?
SWEET: I think the folks that really dove in early to cloud infrastructure, the biggest thing that we can learn from them is that it's not the same, that it's not a matter of, you know, both on the cloud infrastructure side and on the security side. From the cloud infrastructure side, simply building or purchasing a cloud environment from Amazon or IBM, and then fork-lifting applications out there. That's not the way it works. You really do need to re-architect applications in order to get the most benefit from a cloud environment. That gives security organizations the opportunity to revisit how security gets done in those environments. Secondarily, it drives the requirement that there is a set of different ways that these things have to be done. Again, you can't use existing models like gateway models, like appliance models.
I think the second big thing that we've learned from the pioneers is that the rate of change is going to be dramatically different. Where software defined infrastructure and software defined networking is literally programmable and can be dynamically changed, change control goes away because these are automated tools that are making these changes. There's no more change control. The rate of change that security organizations have to address, that's another big takeaway when we look at the folks who have done this. The early adopters really taught us that.
The third, particularly on the public cloud infrastructure side, is that the cloud provider is not going to do everything for you, and that's a big one that we heard a lot of very early on. The assumption was that if we use cloud infrastructure, the cloud infrastructure provider is going to do everything for us. The reality is that a very clear-cut shared responsibility model has evolved in which the cloud provider will take care of a large portion of the common security needs that all of their customers require, but your specific requirements, once they hand you that virtualized infrastructure, that's the end user's requirement to deal with. That's been a big thing that a lot of security organizations have struggled to get around. We think that it's seeded itself as a de facto standard. There are a lot of organizations that are just dipping their toes in that still need to get their heads around that.
FIELD: What fundamental tip would you offer to organizations on how they should begin to assess and mitigate their infrastructure security risks?
SWEET: Probably the most important thing to do out of the gate is to understand what your organization is actually doing with cloud infrastructure. In a lot of cases, security organizations get pulled in later. We see a lot of cloud infrastructure initiatives being driven from the business unit level. We see a lot of shadow IT projects that are being deployed in infrastructures where there might be a traditional environment, folks are trying out open stack, they may actually be deploying some things on a public cloud. Figuring out the right folks to talk to, to figure out what is actually happening, is number one.
The second key piece of advice, especially for financial services organizations, is to talk to the auditors, talk to the regulators about how they are going to view the risks. What are their concerns about using public cloud? What are their concerns about private cloud? What are their concerns about the new rate of change? How are they seeing other organizations address this issue? Getting the view from the actual regulators, auditors, the folks that are going to judge the risks, is very key.
The third big piece of advice is to determine very early on who owns what piece of cloud infrastructure security. Now that you've got virtualized networks, you've got virtualized infrastructure, it's not a matter of the security team and the network team anymore. Now you've got the cloud operations team involved, the actual application developers that are moving to a model that we call dev-ops, and the operations team that run applications. So you have situations where they may own some component of cloud security. You may virtualize network access control, for example, up to the level where the actual application support team is dealing with their own network access control. As opposed to giving them a subnet where they can simply have the network security team set up a simple set of rules. Now it needs to be dynamic. So understanding who owns what and what that's going to look like takes a lot of the friction out of the process of getting the model and a strategy in place that can be sustainable over time.