AWS Security Profiles: Adrian Cockcroft, VP of Cloud Architecture Strategy

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.

How long have you been at AWS, and what do you do in your current role?

I’ve been with AWS for two years, based out of the Palo Alto office in California. I tell people that I have three jobs. One is similar to the kind of thing that Werner Vogels does: I present keynotes at AWS summits. I’ve done fourteen keynotes so far, the biggest in New York last year and Tokyo this year. This gives me a calendar that takes me around the world, where I also spend a lot of time visiting customers, meeting with sales teams, gathering input, and talking to people about their architectural challenges, cloud migration challenges, and organizational challenges. I specialize in the architecture of highly available, multi-region, redundant use cases. That’s the second job. The third job is that I’ve recruited and now manage the team that looks after open source engagement from AWS (and to some extent from Amazon as a whole, as we support a few projects that are broader than AWS itself). We hired a bunch of senior, principal-level technologists who are open source specialists in different areas, and one of the most well-known things that has come out of this is AWS joining the Cloud Native Computing Foundation. I’m one of two board members representing AWS. My team has also created an open source web page that describes the work that AWS is doing in open source. We also have an open source blog.

What are you currently working on that you’re excited about?

My current focus is on resilience, particularly as it pertains to financial services. The problem that many financial services companies face is that their current infrastructure consists of data centers full of mainframes. But mainframe experts are retiring, and there aren’t very many millennial mainframe developers and operations people around. The talent pool is disappearing. So people at these institutions are beginning to ask themselves, “We use these mainframes to move trillions of dollars around. How do we run something like that on the cloud securely, and with extreme resilience?” These aren’t rhetorical questions. Financial institutions need to comply with government audits and standards and compliance rules. In fact, there’s a designation for these organizations — Strategically Important Financial Institutions (SIFI) — which means that they’re regulated in a very special way due to events like 9/11 and the 2008 market crash, events that can introduce systemic risk across the industry. AWS has the Well-Architected Guide to describe our current availability architecture, and we are deeply involved with some of these customers to upgrade it for SIFI workloads. The team is working across sales organization, solutions architecture, and the service teams. We’re currently focused on the availability side of the question, but the security piece is also important: We’ll need the right options, from key management to private end points, to make it all viable. It’s a really interesting project, and one I’m deeply involved with.

How did you choose your particular topics for re:Invent this year?

I have one talk in the container track on chaos engineering, which I’m co-presenting with an engineer from one of our partners, Gremlin. Ana Medina is going to do a live demo of trying to break some container orchestration, and I’m going to do the setup, which is how we see chaos engineering playing out. Chaos engineering is a hot topic with a lot of customers. The high-level way of thinking about it is that most large customers have a failover strategy for their backup data centers. But most of them don’t test it very often: Testing is a big pain in the neck, it’s not reliable when you need it, and it’s expensive. However, if you’re failing over between two cloud regions, your APIs are the same, your capabilities are the same, and a lot of the things that make testing hard involve the drift between data centers. AWS just doesn’t have those problems. We’re managing all that out for you. This results in a highly automatable, productized, safe way to do failovers, which means you can test a lot more frequently. Instead of having one annual test, you can run them every quarter, or every month, or every week. And you’re doing low-level, fine-grain testing against individual instances and services. The upshot is that you end up with a much more resilient system, rather than something that once a year you come along and say, “I’m going to see if I can get it through the audit.” There are analogs to that in the security space as well: We’re moving from annual audits of your security architecture to continuous security where you’ve got tamperproof logs of configuration so you can prove that your system has never been in an insecure state, for example, rather than inspecting it every now and again and asking everybody if they’re processing tickets properly.

My second session is about trends in digital transformation. As I meet with customers around the world, I often hear them say, “We’re different than everyone else; we have all of these unique challenges.” And when they start to list their challenges, the list sounds exactly like the lists from twenty other companies. So eventually, I put all these challenges into a presentation that says, “Here are the four things that are blocking you from your technology transition.” This isn’t about adopting any particular set of AWS products. It’s really about the step before that: If you can’t absorb technological change, if you can’t do a cloud migration, if you can’t be agile, then you can’t keep up with the rest of the industry. What’s driving this digital transformation is the connectedness of customers and devices. Pretend you’re a manufacturing company that makes door locks. Traditionally, you’d put them in boxes, ship them off, and hope to never see them again — if products come back, it means they didn’t work. Now pretend you’re manufacturing a connected door lock — if you don’t hear from your door locks every five minutes, it’s a problem. It means your product is either broken, or the customer has stopped using it. Either way, the connected version requires you to continually monitor and understand how people are actually using it—and this shift applies to a huge numbers of industries. So I’ll be talking about how to navigate the various organizational and cultural blockers that exist within many companies.

What’s the most common problem you see customers running into when it comes to cloud security and compliance?

Over and over again, I see people doing data center security that’s largely enforced by network architecture. They have these complex sets of networks with firewalls, and they think if you’re in this box here, and we have a firewall around you, you’re safe. This segmentation model in data centers is largely based on network structure. Then, when customers start to move to the cloud, their security teams say, “We don’t care what you’re doing in the cloud as long as it follows this structure that we use in the data center.” This means you need to go off and build incredibly complex structures to resemble data center structures, all in order to get sign-off from the security teams. But once these systems are running, you’ll quickly find they’re much too complex — and completely the wrong architecture for cloud and cloud security. But it’s almost like you have to go through this step. It would be nice if we could convince security teams to buy into cloud best practices from the start and to use larger, flatter networks with other mechanisms for segmentation.

Five years from now, what changes do you think we’ll see across the security and compliance landscape?

Five or ten years ago, the cloud was a subset of the functionality of the data center. We’ve now flipped this: It’s hard to build a data center that’s even a pale imitation of a subset of an AWS account. We just have so much scalable functionality. I think that five years out, it will be difficult to even pass an audit in a data center. People are going to say, “You’re running that in a data center? I can’t guarantee anything about your configuration!.” And you’re going to struggle to keep your data center from being overrun by hackers because you can’t control what’s going on. You’ll eventually hit the point where you can’t know enough about the data center to secure it. So you’ll move to the cloud, where, with the proper hygiene, you’ll be able to know everything. You can log everything that’s ever happened in a tamperproof log, and that ability allows you to make strong assertions.

I also think we’re starting to get governments around the world to support banking in the cloud. We’re still in the early stages, since this also requires teaching auditors how to understand what a banking audit looks like in the cloud: The goals are the same, but the implementation of patterns is different. We’re also seeing people using AWS Managed Services to create a PCI-compliant configuration from scratch via an API call, within a few hours. And then the auditor comes in, says, “You didn’t mess anything up. You’re done!” and walks away. I think these highly audited systems will be start to be built in an extremely automated, repeatable way.

What does cloud security mean to you, personally?

I bought a house last year and have been installing all these IoT things, like door locks, lights, blinds, and yard sprinklers. These are all cloud services. I think we’re getting to a point where your personal security is tied up into the cloud. The security of all those items, which used to be physical security, is moving toward a cloud-based security model that’s going to touch people more and more as it all rolls out.

The AWS Security team is hiring! Want to find out more? Check out our career page.