AWS Security Profiles: Stephen Quigg, Principal Security Solutions Architect, Financial Services Industry

In the weeks leading up to re:Inforce, 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 as a Principal Security Solutions Architect?

I’ve been with AWS for six years and four months. My job is to help customers get comfortable with the security measures that AWS takes on their behalf—measures which help customers build secure applications on top of our services. I help them understand both sides of the Shared Responsibility Model.

What’s your favorite part of your job?

Being thrust into a room full of security professionals who don’t have experience with AWS. They’re understandably wary of trying new things, so I’m happy when I see their attitudes and moods change. Once they begin to understand how I can help them, they start nodding their heads and uncrossing their arms.

What’s the most challenging part of your job?

When I present customers with a logical argument, some of them still won’t be reassured. I can ask “why not?” but they might not be able to explain. That’s a tough situation, because those are the people that my team needs to keep talking to. We need to keep trying to understand what drives their concerns about cloud security, and what needs to happen for them to make the shift. It’s not effective to tell people that they’re wrong. You have to understand their needs, explain things, and let them draw their own conclusions.

When I look at our customers’ information security teams, these teams are just people like me, who are often stuck in very difficult situations. They might not have the resources or the time to do all the things they want to do, and they probably have to interact with a lot of people who think of them as blockers, even though their job is to protect the company. AWS represents a wonderful opportunity for change. I want to show them a new style of service, and that we’re listening to them, and that we’re acting in their best interest.

In your opinion, what’s the biggest challenge facing cloud security in the financial services industry right now?

The biggest challenge for our customers is that they already have so much work to do. And when their businesses start transitioning to AWS, their security teams now have new work.

Their ability to do all of that work can be improved through the advanced automation that AWS offers. But we need to help our customers learn how to build automated solutions. We offer wonderful services, and we can help people stitch them together, but all of this represents a new “cloud security” operating model that customers often have to start up while still maintaining their existing operating model.

Five years from now, what changes do you think we’ll see across the financial services/cloud security landscape?

Many incidents that currently require a human response will be dealt with automatically. Beyond that, the ability to automatically analyze the evidence to figure out what went wrong, and what to do about it is where we’ll see big developments.

I think the other big change is that customers will start worrying less about high-touch processes like patching, because they’ll have automated the process of building new things. There will still be vulnerabilities—there will always be vulnerabilities—but these types of changes will be helpful because it will mean fewer people logged onto production servers. We’re moving toward a zero-touch environment where, barring extreme emergencies, everything can be done via automation.

It’s typically human error that causes security incidents. It’s not malicious, it’s just that people make mistakes. And the fewer the number of people involved, the fewer the number of mistakes that can happen, because you can automate code testing to make sure it’s working properly. It’s hard to have that level of assurance when we’re talking about a person’s fingers on a keyboard.

How does working in a highly regulated industry like financial services affect the work that you do as a solutions architect?

I have to be really diligent about listening. I can’t answer customer requests by painting with broad brushstrokes and saying “close enough.” Many AWS customers are regulated. They have strict requirements from their regulators that they have to meet. AWS can’t make assumptions that something is “good enough.” The customer has to make those decisions.

So it’s important to be very precise about what you tell customers, and it’s important to be very transparent, and to give them very accurate information, because they’ll need to be able to prove that they understand the AWS cloud when they talk to their regulators. It’s not good enough for AWS to talk on their behalf.

What does cloud security mean to you, personally?

I love technology and security. Since 1999, when I first started working full-time as a security professional, my singular point of focus has been information security. Back then, my job was to help advise people on security architecture and to do pen testing. And during those years, I watched a lot of people fail: The solutions they bought were the equivalent of trying to patch up a wound with sticking plasters. The solutions rarely worked.

What drives me today is that after six years at AWS, I still absolutely love it. I’m a part of one of the biggest improvements that has ever happened to information security. The ability of customers to automate tasks, plus the ability to pass management of really complex architecture to a cloud provider that is focused on security, a provider that “does security” as its core competency, its core business—that thrills me.

I see all these opportunities for our customers, and I want them all to succeed, because everyone benefits from a more secure world. I benefit from a life where I can do my banking on my phone, and where I can video call from anywhere. My family and my children will benefit from this world.

You’re co-hosting a session at re:Inforce that focuses on “When and how” to use AWS CloudHSM. When should you use CloudHSM, and what’s the alternative?

You should choose AWS CloudHSM when you have strict compliance requirements that require cryptographic operations to be performed within a FIPS 140-2 Level 3 validated device, which is what CloudHSM is. You should use it when you can’t use any other AWS cryptographic service.

CloudHSM is a really important service for a small set of customers that really need it. Many of our customers’ needs are actually more easily served by other AWS services. And those services often require less skill to set up, and less attention from the customer. CloudHSM, by its very nature, gives customers a lot of responsibility. If you’re able to pick other AWS cryptographic services, AWS can do much more of the work.

You’re also hosting a builders session. What can you tell us about that topic?

Many people who are new to the cloud come from a traditional security architecture background, so we need to teach them about architecture in the cloud. Automation is really, really important in the cloud, but to get to the point where you can automate everything, there’s a lot you need to design and build.

Many of our customers in financial services also care very deeply about how things connect to the internet, whether it’s traffic that’s coming to their Amazon Elastic Compute Cloud (EC2) instances or traffic from their EC2 instances that’s going back out to the internet.

So I’ve designed a session to help those people get comfortable with how to take traditional security architecture and rethink it for AWS. This moves them one step closer to the cloud. The session includes stepping stones between what you’re doing on-premise and how you can do it in the cloud. I want to help people get comfortable and realize that the shift isn’t as large as they thought it was. The session will cover topics like firewalls, inbound and outbound proxies, and web application firewalls; all things that are easily built on top of AWS services.

What do you hope that people will do differently as a result of attending your sessions?

The CloudHSM session is deep dive into how customers can optimize their use of the service in terms of cost, performance, and resilience.

I’m hoping that the people who attend the session are either planning a deployment of CloudHSM or have existing deployments that they want to look at in terms of those three levers—cost, performance, and resilience. I want people to review their requirements and ask, “Am I using too many CloudHSMs? Have I provisioned too many?” There might be an opportunity to save money. Or, “Am I built resiliently enough? Do I have CloudHSMs deployed in multiple Availability Zones, or maybe in multiple Regions?” And finally, “Am I using the right AWS crypto service? Do I really need a CloudHSM, or should I be using AWS Key Management Service or AWS Certificate Manager instead?”

For the second session on modernizing security architecture, I’d like people to go home and start thinking about moving their data centers to AWS. I’d like to be the catalyst. Earlier, I mentioned some of the challenges customers can face when transitioning to security in the cloud—I hope my session will help attendees start thinking through the logistics of that transition.

Anything else about either session you want us to know about?

Yes. I am not a cryptographer, so someone from the AWS cryptography team is going to co-host the CloudHSM deep-dive. When I’m speaking to my customers, I always try to be very clear about this point. The one thing you should never wave your arms and be vague about is cryptography. I think cryptography on its own is fascinating, so I’m humbled by the fact that I will never be a cryptographer.

Have you been to Boston before? Is there anything that you’re looking forward to seeing or doing while you’re there?

I’ve never been to Boston, and I’m really looking forward to it. It seems like a beautiful city, and I’m excited about experiencing its atmosphere and its character as an historic European point of entry into America. Every American city has such a different character, so I’m looking forward to experiencing Boston. It’s also the city one of my favorite Neal Stephenson books was based in – Zodiac!

You make music, with track titles like “Hardware Security Module – SHA-3.” How does your day job inform your music? (And vice versa?)

I love my electro music, and I love my techno. The origins of techno were in Detroit, where the sound was built based on the repetitive noise of machines. Now, I’m from near the Glasgow, Scotland area, and Glasgow was at the heart of the Industrial Revolution. It was called the “engine room of the Empire.” We had shipyards and production lines. So I think the people of Glasgow and the people of Detroit have a common tie in terms of the music that we like.

Working in technology fuels the same kind of inspiration for me. We’re in the middle of a new industrial revolution, and my work and my mood very much influence my music. I’m really happy working at AWS, and I get to work with absolutely awesome technology daily. This all bleeds into the music I make. (HSM and Detroit are my techno tracks, and HSM and Chicago are my acid house tracks.)

You live in Scotland. What’s one thing a visitor should see, eat, or do when visiting Scotland?

If I were from Edinburgh, I’d tell you to see Edinburgh Castle. But instead, I’d say that you must visit the West Coast. The West Coast is our islands and our mountains—places like Glencoe, if you can get there. Other countries have bigger mountains. Other countries have steeper cliffs. But there is a loneliness and a barrenness about Scotland that’s quite breathtaking, and that I’ve never found anywhere else in the world. The West Coast of Scotland is absolutely the place that you must experience if you visit the country. If you don’t, you won’t understand the whole “Scottish thing” that we have going on.

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