Extending Security Ownership Across Your Organization

Clarke: (00:05)
Megan, thank you so much for joining me today.

Megan: (00:07)
Yeah, absolutely.

Clarke: (00:08)
So, could you tell us a little bit about your background and how you came to AWS?

Megan: (00:13)
I've been in different security roles for over 15 years, starting as a network security specialist for a hospital. And then, joining a global retailer based out of Seattle and helping do different security engineering and architecture roles. And then actually, we became a customer of AWS in 2014 and I helped set the cloud security strategy and implement the security controls there. And then, I joined Slalom and I was a part of their dev sec ops team and helped customers all around North America do the same thing —set cloud security strategy and implement security controls. And then, I joined AWS actually as an enterprise solution architect for Pacific Northwest and then joined the security specialist team.

Clarke: (01:02)
That's awesome.

Megan: (01:03)
So, I've been here about four years. Yeah.

Clarke: (01:04)
Great.

Megan: (01:04)
Thanks.

Clarke: (01:05)
So, you started off, I believe with a computer science background. What attracted you to security?

Megan: (01:12)
It was actually interesting. I was on the mechanical engineering path initially and I had an internship at Boeing for three summers and I got to work with the 767-400 line tooling engineers. And I asked them, if they were going to school right now, what would they study? And they told me computer science. And so, I was like, "Okay." And resoundingly, all of them said that. So I said, "Okay, I'll take a computer security or computer science class." And I loved it. It was really fun. It was solving puzzles, right?

Clarke: (01:47)
Right.

Megan: (01:47)
And, half the class dropped out because it wasn't their thing. And I just kept going. And, one of the elective courses was digital security and that sounded so interesting to me. And I took that course and I was hooked. I thought it was really interesting. It's just more puzzles to solve, constantly changing. And so, yeah, I actually built IDS as my senior project for my computer science degree. I built a little program that would analyze network packet captures and determine nefarious network behaviors. It's really fun.

Clarke: (02:21)
That's awesome. It's led to a great career, obviously.

Megan: (02:23)
Yeah.

Clarke: (02:24)
So, in your role at AWS, you're a senior security solutions architect. What does that mean? And what are your primary responsibilities in that role?

Megan: (02:33)
I help customers with the security of AWS. I help give them guidance on how to build the foundation, set the guardrails, implement security controls, also helping them understand, “What is the operating model for cloud? What does that look like?” I also help educate customers at events, build workshops, builder sessions, as well as internal field. So, we've got some programs internally where we're having internal field essays, educate them on the different aspects of security. So, taking them from maybe 100 level security to 300 level, so that they can be more effective in those customer conversations.

Clarke: (03:20)
So, Megan, at AWS, we have a very strong security culture and we have lots of mechanisms to help enforce that culture. Do you have any particular favorite mechanisms?

Megan: (03:29)
Yeah, absolutely. So, one of the processes we have is filing a sev two. No matter who you are in the company, if you think there's a security issue, the process is to file a ticket — it's called sev two. And there's somebody on the other side of that, that's a security engineer that's going to help evaluate whether it's an issue or not, and take it from there. And, there's no issue if it's not a security problem. That's great. And it's blameless. So really, the idea is that we don't want anyone to feel worried or intimidated by thinking there's a security issue. We want to know about it. We want to react to it, in a good way, in a positive way. And this is supported at the leadership level, which is really nice. I think, many times where there's security training and speaking with your own leadership, it's like everyone thinks about it positively. So, I think that just kind of breeds a culture of transparency around security and openness that I think I've never seen anywhere before. I really appreciate it.

Clarke: (04:44)
Right. So, when you're speaking with all the different customers that you deal with at different levels throughout a customer organization, are there particular areas of focus that you encourage them to help them try to build their own security culture? Again, the sort of blameless security culture?

Megan: (05:01)
Yeah, absolutely. And I see this in a couple areas. I tend to encourage customers to kind of think about operating their security teams as like helping the business, helping the developers, where if they do help make the easy thing, the right thing to do from a security perspective, almost making a paved road so that if they're operating within the right model and there's transparency around those security requirements, they can accelerate and they don't hit a ton of blockers, so to speak. And I think, that breeds this nice balance between security and development where they're partnering together. And I really enjoy seeing that work at customers. I've definitely seen it in a couple customer cases. And I think, this just provides a nice way to operate from the security side and the development side where they're partnering and helping each other out.

Clarke: (06:00)
So, security not being the department of “no,” but actually trying to help them out and be successful?

Megan: (06:05)
Yeah, for sure.

Clarke: (06:07)
From a customer leadership perspective, what can the most senior leaders at a company do to help foster that security culture that we're trying to build in customer relationships?

Megan: (06:20)
Well I think, it's much different than the traditional days, right? It's not just the security team that's responsible for security — it can't be. Developers need to own a lot of that. I actually like to walk customers through, "Hey, there's the shared responsibility model between AWS and the customer," but you extend that shared responsibility model of all the different security controls and aspects of security for cloud across the rest of your organization and make it transparent to everyone what they own.

Clarke: (06:53)
Right.

Megan: (06:53)
And then, help make those things easy to do and easy to get right. So, actually extending the shared responsibility model within your own organization, so it's tangible to everyone I think is a really effective way to go.

Clarke: (07:05)
That's awesome. So, many of your customers I'm sure have far fewer security experts than they would like to have. What are some of the things you've seen that security teams can sort of expand their focus and influence throughout the rest of their customer organization?

Megan: (07:22)
Well, a couple things. I think, first of all, we don't always find the right practitioner that we're looking for the job. And so sometimes, that means broadening the horizon a little bit and thinking, "Hey, if you have security folks that don't necessarily know cloud, but they're interested in it, get them on a path to get there." And if you have developers or DevOps folks that are interested in security, but don't necessarily have the background, put them on a path to get them there. Provide some of that training. And I think, there's a lot of tools out there that do that. One of my favorite ways is to watch previous re:Invent videos, re:Inforce, put on a 30-minute, 45-minute session on security foundational best practices. And a lot of the videos out there that are with customers specifically are really good examples of how customers are doing it, that get us thinking outside of the box that I think can really help. Additionally, the AWS solutions architect associate or professional certificate is a really good way to get those foundational concepts. And then, of course, the security specialist certification is really good.

Clarke: (08:39)
So, the last 18 months or so, have been difficult on everyone. We've had the pandemic, more people working from home. Has the pandemic sort of led to an increase or decrease in people's cloud adoption? What are you seeing in customers?

Megan: (08:54)
Yeah, absolutely. I've seen several large customers have to increase their adoption of cloud to handle how things have just changed. The online retail business just really blew up because brick and mortar had to close down. And I think, we saw some interesting patterns from that. And I think, we have some lessons learned from that for other customers that is depending on how they went about building their initial foundational security and their multi-account strategy. If they were able to leverage automation for that, they did really well because they could just build more accounts and implement automation. They already had the automation there to build out those security foundations and their controls were just there. Whereas, if that wasn't automated, sometimes we would, of course, help them build out some without automation and get them ramped up as soon as possible. But if it was done manually, it's just painful and it's slow. And so, I think, making sure that everything is ... All those guardrails, your multi-account is automated, is going to be really important. And this was just a very good example of how the real world kind of forces that. I know when I started as a customer of AWS, we had two dev teams just playing around. Six months later, it was 20 dev teams, systems were in production, and everyone else wanted to get onboard to the platform. So, I learned that lesson early and I think a lot of customers had to go through that lesson.

Clarke: (10:31)
Because then you had to do rework to actually meet the security bar that you wanted to have.

Megan: (10:35)
Yeah, exactly.

Clarke: (10:37)
So, on somewhat of the same tangent — security teams, security teams within customer accounts. Is there a way that sort of security can lead the way to the cloud for customers?

Megan: (10:50)
I think, I've seen this with customers where a lot of times security is the last one. But they don't have to be. I think, if they can take their security framework that they've adopted on-prem and take controls and update them for cloud, do some mapping and essentially get those guardrails in place ahead of time, that's going to be much easier. They're going to be prepared for people to deploy. And, if there's no one pushing you, that's great. You can have kind of the metrics defined. You can have the automation set up without having someone knocking at the back door like, "Hey, let's go." And I also think, it gives us this opportunity as a security team to be transparent about the security requirements, help the developers understand how they need to build and what spec the security team is expecting. And I think again, that goes back to bouncing the relationship between developers and security and just ... It's a more effective, efficient relationship and it's just going to help implement the business features that the developers are trying to do.

Clarke: (12:10)
Right. I would imagine there's a certain level of confidence and trust that is built once you see the security team go into the cloud ahead of you and as a developer or product owner, you're like, "Well, I really don't have any excuse anymore if the security team's doing it."

Megan: (12:25)
Exactly. And I think, one of the things I've seen work really well with customers if they give those security requirements and they give examples, like an internal Wiki side of, “What's a secure identity and access policy look like?”, “What's a secure security group versus what's the bad?” and actually tangible examples — that goes really far. And, here's exactly what we're talking about. No action star against resource star for your access policies, that sort of thing. The other thing is that when security teams make themselves available…so if a development team were to become blocked, for whatever reason…So, for example, if a customer is struggling with a specific security requirement, if the security team has made themselves available through office hours once a week, or a slack channel, that can really just make the whole process easier for developers. They have a go-to team. Many times they develop friendships with these folks so that they don't necessarily, they don't have to sit there and be blocked for 24 hours or anything like that. They just can just do a fast feedback loop. And maybe, that's also going to be a feedback for like, "Hey, our documentation’s too complicated,” or “We need to specify something," or if we're asking folks to bootstrap a security agent on a host, why don't we just write a script for them and make that script available in a code repository?

Clarke: (14:02)
So, with everything you just shared there, I'm also hearing some skills that maybe your average security team may not have. So, if we look at sort of traditional security teams, they've been running the IDS and different network services, patching systems, whatever the case may be, but I'm hearing from you and please correct me if I'm wrong, security teams now have to really understand how development cycles work and maybe even how to code themselves?

Megan: (14:33)
Yeah, absolutely. I think we didn't ... Depending on the background of the security practitioner, you might not have a developer background or a CS degree and that's not required, but I think a little Python programming never hurt anybody and cloud formation is pretty easy to learn. Ansible, it's just a YAML configuration file. And I absolutely think, operating similar to a dev team, using the agile practices with a backlog, a product owner that's managing a priority from a security perspective, is just going to help. Number one, understand how developers work, but also it's actually a really efficient way of working. When I was a practitioner, that's how we did things because, especially from a security perspective, things are changing so fast, business requirements change fast. All of a sudden you have to scale up, change the way you were operating. So, it helps you kind of reprioritize efficiently on a regular cadence, what the priorities should be.

Clarke: (15:39)
So, almost running security as a service inside of an organization?

Megan: (15:44)
Yeah, definitely.

Clarke: (15:46)
Great. So, let's switch gears a little bit and focus on some of the things that are in the news as of late. So, ransomware is, you don't have to look very hard and you'll hear about one ransomware story after another. What are you seeing with customers and what kind of advice to you giving them in regards to ransomware mitigation techniques?

Megan: (16:11)
I have probably had over 20 conversations directly with customers just over the past two months about ransomware. And, I love having these conversations because they're like, "Hey, we want to understand what AWS's messaging is." And that just tells me that they think of us as a partner, which is awesome. So usually, what I do is I have a top 10 best practices because there's no silver bullet for ransomware. You really have to have a strong security program, strong security controls, and make sure that they're operating efficiently. But there are definitely some key areas to cover, so we walk through multi-account strategy, least privilege access. The one area I really harp on is, do you have static, long-lived IM credentials anywhere? If you do, it's time to look at those with a magnifying glass and determine number one, do they still need to be there? Can we re-architect? And if they really are required — because in some cases for hybrid access, they are needed — let's minimize the access attached to that credential so that they can do very little in the environment and then monitor when it's used and just keep it as a risk. Put it on the risk register. Don't let it go away. And if there's opportunity to get rid of it in the future, get rid of it. It tends to be one of the top risks we see and we want to make sure we're proactive in helping customers prevent bad days, so to speak.

Clarke: (17:44)
And, from what I understand, ransomware mitigation is really just doing the security basics very, very well. Is that a fair assessment?

Megan: (17:52)
Yeah, it is. Patching isn’t a new concept. And you can actually do this in AWS in many different ways. You can do rip and replace with auto scaling group and relaunch your systems from your CICD pipeline. You can use Systems Manager. Systems Manager is like half operations, half security tool at this point. It's amazing what you can do with it. So, yeah. There's a lot of options. And, we talk about those as well. I think, the other one that customers have asked me about that, I think this is a good conversation to have is, "Hey, we used to do air gapped backups with on-prem. We literally had tape backups, put them on an iron mountain truck so no one could touch those backups. How do we do that in AWS?" Well, everything's an API, so it's connected, but there's ways to, if you look at the security, the security boundary as the AWS account, you can create a separate account with a different…and send your backups to that account. You can do automation with push pull type mechanisms so that you have a landing account for the backups. And then, a separate account where you pull from a known good source and you can use things like S3 object block, which is write once, read many worm on that S3 bucket, and some really strong security and controls, minimized access even to fewer administrators of the account. And then with AWS Backup, they just announced, I think two weeks ago, or just recently, AWS Backup Vault Lock which allows you to do similar, the write once, read many, applied to that vault. And so, basically, what that does is prevents you from making changes to those backups after it's done. So, you can't delete anything. So, with AWS Backup Vault Lock, you can set policy, access policy and prevent people from making any changes to it. So, it's essentially similar to S3 object block in the fact that, that data is stored there, it's off limits for a certain period of time.

Clarke: (20:05)
Got it. So, in addition to some of the tools and the best practices that you mentioned, one thing I didn't hear was incident response preparation. How important is that and what should customers be doing in that area?

Megan: (20:19)
When we have these ransomware discussions specifically, I always ask customers, "Have you actually done a tabletop exercise of a ransomware security event?" Because, tabletop exercises are so critical. If you've never worked in incident response, it can be a stressful situation. Tabletop gives you the opportunity to work through a lot of the issues that you don't need to deal with during an actual event where you just want to be focused and doing your investigations without any issue. And the tabletop exercise, you're going to go through this practice of essentially, how do we know the event happened? Do we have access to all of our AWS accounts to do the investigations we need? Where would we see the event? Would it come through our security operations center? Do we have a playbook that outlines all the activities those folks need to do so that they can respond consistently and have the data that they need to make those decisions? And then, are we pulling in the right stakeholders? Because if we do have a security event, we need to know how to communicate with our customers, with their customers. And, it just works out a lot of the kinks and our pro serve team can come in and help customers do that as well. We've done this several times and practice makes perfect, right? And so I think, that's just something that whenever there's fear about a certain scenario, it's like, "Well, practice." And then, it's not going to be as scary. It's just as simple as practicing and getting better at something.

Clarke: (21:55)
So, you mentioned other stakeholders. So, this is not just a security team exercise?

Megan: (22:00)
No, not at all.

Clarke: (22:01)
What are some of the other stakeholders that should be participating in these tabletop exercises?

Megan: (22:06)
Yeah. Well, definitely, legal usually gets involved, usually a privacy team, security management, and depending on the type of exercise, the incident that you're working through, could be your help desk, it could be application and development teams to help understand if we were to do any type of mitigation, for example. What would the downstream impacts of that be?

Clarke: (22:36)
Do you see, I mean, all levels of a customer hierarchy get involved? I mean, would the CEO be on any of these tabletop exercises? Or what levels? Where does it stop?

Megan: (22:50)
Yeah. I think it's also too who wants to be involved and kind of understand the process because when you actually go through a security event, it's usually confidential. You want to make sure that only the right people know about it, that need to know about it so that the communication can happen in a calculated manner. But for an exercise, there's no reason not to involve folks that want to be involved. And, if the CEO's interested, absolutely bring him in.

Clarke: (23:21)
Awesome.

Megan: (23:22)
Everyone can learn something from it.

Clarke: (23:24)
So, another big topic that's in the news these days, and what customers are always asking about is the concept of zero trust. What does zero trust mean to you?

Megan: (23:34)
Yeah. Well, traditionally, for access and security controls into our environment, we relied heavily on the network perimeter. Whereas today, what we want to do is actually authenticate and authorize calls at the API layer. And so, what that means is, whether it's a user getting access into our environment, or API to API call, we want to make sure that it's authenticated and authorized each step in the path for that network communication.

Clarke: (24:10)
Megan, thanks for joining me today.

Megan: (24:12)
Yeah. Thanks. This was really fun.