AWS Security Profiles: Paul Hawkins, Security Solutions Architect

Leading up to AWS Summit Sydney, we’re sharing our conversation with Paul Hawkins, who helped put together the summit’s “Secure” track, so you can learn more about him and some of the interesting work that he’s doing.

What does a day in the life of an AWS Security Solutions Architect look like?

That’s an interesting question because it varies a lot. As a Security Solutions Architect, I cover Australia and New Zealand with Phil Rodrigues—we split a rather large continent between us. Our role is to help AWS account teams help AWS customers with security, risk, and compliance in the cloud. If a customer is coming to the cloud from a on-premises environment, their security team is probably facing a lot of changes. We help those teams understand what it’s like to run security on AWS—how to think about the shared responsibility model, opportunities to be more secure, and ways to enable their businesses. My conversations with customers range from technical deep-dives to high-level questions about how to conceptualize security, governance, and risk in a cloud environment. A portion of my work also involves internal enablement. I can’t scale to talk to every customer, so teaching other customer-facing AWS teams how to have conversations about security is an important part of my role.

How do you explain your job to non-tech friends?

I say that my job has two functions. First, I explain complex things to people who are not experts in that domain so that they can understand how to do them. Second, I help people be more secure in the cloud. Sometimes I then have to explain what “the cloud” is. How I explain my job to friends reminds me of how I explain the cloud to brand new customers—people usually figure out how it works by comparing it to their existing mental models.

What’s your favorite part of your job?

Showing people that moving to the cloud doesn’t have to be scary. In fact, it’s often an opportunity to be more secure. The cloud is a chance for security folks—who have traditionally been seen as a “Department of No” or a blocker to the rest of the organization—to become an enabling function. Fundamentally, every business is about customer trust. And how do you make sure you maintain the trust of your customers? You keep their data secure. I get to help the organizations I work with to get applications and capabilities out to their customers more swiftly—and also more securely. And that’s a really great thing.

Professionally, what’s your background? What prompted you to move into the field of cloud security at AWS?

I used to work in a bank as a Security Architect. I was involved in helping the business move a bunch of workloads into AWS. In Australia, we have a regulator called APRA (the Australian Prudential Regulatory Authority). If you’re an insurance or financial services company who is running a material workload (that is, a workload that has a significant impact on the banking or financial services industry) you have to submit information to this regulator about how you’re going to run the workload, how you’re going to operationalize it, what your security posture looks like, and so on. After reviewing how you’re managing risk, APRA will hopefully give you a “no objection” response. I worked on the first one of those submissions in Australia.

Working in a bank with a very traditional IT organization and getting to bring that project over the finish line was a great experience. But I also witnessed a shift in perspective from other teams about what “security” meant. I moved from interacting with devs who didn’t want to come talk to us because we were the security folks to a point, just before I left, where I was getting emails from people in the dev and engineering teams, telling me how they built controls because we empowered them with the idea that “security is everyone’s job.” I was getting emails saying, “I built this control, but I think we can use it in other places!” Having the dev community actively working with the security team to make things better for the entire organization was an amazing cultural change. I wanted to do more work like that.

Are there any unique challenges—security or otherwise—that customers in New Zealand or Australia face when moving to the cloud?

If you look at a lot of regulators in this region, like the APRA, or an Australian government standard like IRAP, or compare these regulators with programs like FedRAMP in the US, you’ll see that everything tends to roll up toward requirements in the style of (for example) the NIST Cybersecurity Framework. When it comes to security, the fundamentals don’t change much. You need to identify who has access to your environment, you need to protect your network, you need good logging visibility, you need to protect data using encryption, and you need to have a mechanism for responding instantly to changes. I do think Australia has some interesting challenges in terms of the geographical size of the country, and the distant spread of population between the east and west coasts. Otherwise, the challenges are similar to what customers face globally: understanding shared responsibility, understanding how to build securely on the cloud, and understanding the differences from what they’ve traditionally been doing.

What’s the most common misperception you encounter about cloud security?

People think it’s a lot harder than it is. Some people also have the tendency to focus on esoteric edge cases, when the most important thing to get right is the foundation. And the foundation is actually straightforward: You follow best practices, and you follow the Well-Architected Framework. AWS provides a lot of guidance on these topics.

I talk to a lot of security folks, architects, instant responders, and CISOs, and I end up saying something similar to everyone: As you begin your cloud journey, you’ve probably got a hundred things you’re worried about. That’s reasonable. As a security person, your job is to worry about what can happen. But you should focus on the top five things that you need to do right now, and the top five things that are going to require a bit of thought across your organization. Get those things done. And then chip away at the rest—you can’t solve everything all at once. It’s better to get the foundations in and start building while raising your organization’s security bar, rather than spin your wheels for months because you can’t map out every edge case.

During the course of your work, what cloud security trends have you noticed that you’re excited about?

I’m really pleased to see more and more organizations genuinely embrace automation. Keeping humans away from systems is a great way to drive consistency: consistency of environments means you can have consistency of response, which is important for security.

As humans, we aren’t great at doing the same thing repeatedly. We’ll do okay for a bit, but then we get distracted. Automated systems are really good at consistently doing the same things. If you’re starting at the very beginning of an environment, and you build your AWS accounts consistently, then your monitoring can also be consistent. You don’t have to build a complicated list of exceptions to the rules. And that means you can have automation covering how you build environments, how you build applications into environments, and how to detect and respond in environments. This frees up the people in your organization to focus on the interesting stuff. If people are focused on interesting challenges, they’re going to be more engaged, and they’re going to deliver great things. No one wants to just put square pegs in square holes every day at work. We want to be able to exercise our minds. Security automation enables that.

What does cloud security mean to you, personally?

I genuinely believe that I have an incredible opportunity to help as many customers as possible be more secure in the cloud. “Being more secure in the cloud” doesn’t just mean configuring AWS services in a way that’s sensible—it also means helping drive cultural change, and moving peoples’ perceptions of security away from, “Don’t go talk to those people because they’re going to yell at you” to security as an enabling function for the business. Security boils down to “keeping the information of humans protected.” Whether that’s banking information or photos on a photo-sharing site, the fundamental approach should be the same. At the end of the day, we’re building things that humans will use. As security people, we need to make it easier for our engineers to build securely, as well as for end users to be confident their data is protected—whatever that data is.

I get to help these organizations deliver their services in a way that’s safer and enables them to move faster. They can build new features without having to worry about enduring a six-month loop of security people saying, “No, you can’t do that.” Helping people understand what’s possible with the technology and helping people understand how to empower their teams through that technology is an incredibly important thing for all parts of an organization, and it’s deeply motivating to me.

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

I believe the ways people think about security in the cloud will continue to evolve. AWS is releasing more higher-function services like Amazon GuardDuty and AWS Security Hub that make it easier for customers to be more secure. I believe people will become more comfortable using these tools as they start to understand that we’re devoting a huge amount of effort to making these services provide useful, actionable information for customers, rather than just being another set of logs to look at. This will allow customers to focus on the aspects of their organization that deliver business value, while worrying less about the underlying composition of services.

At the moment, people approach cloud security by applying a traditional security mindset. It’s normal to come to the cloud from a physical environment, where you could touch and see the servers, and you could see blinking lights. This background can color the ways that people think about the cloud. In a few years’ time, as people become more comfortable with this new way of thinking about security, I think customers will start to come to us right out of the gate with questions like, “What specifics services do I need, and how do I configure them to make my environment better?”

You’ve been involved in putting together the Security track at the upcoming AWS summit in Sydney. What were you looking for as you selected session topics?

We have ten talks in the “Secure” track, and we’ve selected topics to address as many customer needs as possible. That means sessions for people who are just getting started and have questions like, “What foundational things can I turn on to ensure I start my cloud journey securely?” It also means sessions for people who are very adept at using cloud services and want to know things like, “How do I automate incidence response and forensics?” We’ve also talked to people who run organizations that don’t even have a security team—often small startups—who want to get their heads wrapped around cloud security. So, hopefully we have sessions that appeal to a range of customers.

We’re including existing AWS customers in nine out of the ten talks. These customers fall across the spectrum, from some of our largest enterprise customers to public sector, startups, mid-market, and financial services. We’ve tried to represent both breadth and depth of customer stories, because we think these stories are incredibly important. We had a few customers in the track last year, and we got a great response from the audience, who appreciated the chance to hear from peers, or people in similar industries, about how they improved their security posture on AWS.

What do you hope people gain from attending the “Secure” track?

Regardless of the specific sessions that people attend, I want them walk away saying, “Wow, I can do this in my organization right now.” I want people to see the art of the possible for cloud security. You can follow the prescriptive advice from various talks, go out, and do things for your organization. It shouldn’t be some distant, future goal, either. We offer prescriptive guidance for what you can do right now.

Say you’re in a session about secrets management. We might say, This is the problem we’re talking about, this is how to approach it using AWS Identity and Access Management (IAM) roles, and if you can’t use AWS IAM roles, here how to use AWS Secrets Manager. Next, here’s a customer to talk about how they think of secrets management in a multi-account environment. Next, here are a bunch of different use cases. Finally, here are the places you can go for further information, and here’s how you can get started today.” My hope is that the talk inspires people to go and build and be more secure immediately. I want people to leave the Summit and immediately start building.

We’re really proud of the track. We’ve got a range of customer perspectives and a range of topics that hopefully covers as much of the amazing breadth of cloud security as we can fit into ten talks.

Sometimes you make music and post it to Soundcloud. Who are your greatest musical influences?

Argh. There are so many. I went through a big Miles Davis phase, more from listening than in any way capable of being that good. I also draw inspiration from shouty English punk bands like the Buzzcocks, plus quite a lot of hip-hop. That includes both classic hip-hop like De La Soul or A Tribe Called Quest and more recent stuff like Run the Jewels. They’re an American band out of Atlanta who I listen to quite a lot at the moment. There are a lot of different groups I could point to, depending on mood. I’ve been posting my music to Soundcloud for ten years or so. Long enough that I should be better. But it’s a journey, and of course time is a limiting factor—AWS is a very busy place.

We understand that you’ve switched from playing cricket to baseball. What turned you into a baseball fan?

I moved from Sydney to Melbourne. In Sydney, the climate is okay for playing outdoor cricket in the winter. But in Melbourne, it’s not really a winter sport. I was looking for something to do, so I started playing winter baseball with a local team. The next summer, I played both cricket and baseball—they were on different days—but it became quite confusing because there are some fundamental differences. I ended up enjoying baseball more, and it took a bit less time. Cricket is definitely a full day event. Plus, one of the great things about baseball is that as a hitter you’re sort of expected to fail 60% of the time. But you get another go. If you’re out at cricket, that is it for your day. With baseball, you’re engaged for a lot longer during the game.

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