Episode #131: Security in the Cloud with Merritt Baer and Megan O'Neil
April 4, 2022 • 47 minutes
On this episode, Jeremy and Rebecca chat with Merritt Baer and Megan O'Neil about how to think about security choices around services and resources in the cloud, the need for leadership and education, how serverless extends the shared security model, and so much more.
About Merritt Baer
Merritt Baer is an emerging tech and infosec expert. She builds strategic initiatives for security and emerging technologies. She currently is a Principal Security Architect at Amazon Web Services (AWS), where she provides technical cloud security guidance to complex, regulated organizations like the Fortune 100, and advises the leadership of AWS' largest customers on security as a bottom line proposition.
Recently, Merritt served as the Lead Cyber Advisor to the Federal Communications Commission. She also wrote and implemented civilian cybersecurity strategy at the Department of Homeland Security's Office of Cybersecurity and Communications, the nation's cyber firehouse.
Merritt is a double Harvard graduate with experience in all three branches of government and a strong publication record. She is a leader in computer security, an Internet law and business expert, and a technology entrepreneur.
About Megan O’Neil
Megan is a Principal Security Solutions Architect at AWS. In her more than four years with AWS, she has had experience in threat detection and incident response, as well as in enabling customers to implement sophisticated, scalable, and secure solutions that solve their business challenges.
Megan’s expertise also includes collaborating with internal teams to design and develop secure solutions across multiple technologies and platforms, as well as providing strategic direction on enterprise security architecture and the implementation of appropriate safeguards and controls. She is also well-versed in assessing current and planned applications and systems, identifying security architecture issues and designing solutions for gaps.
Transcript
Jeremy: Hi everyone. I'm Jeremy Daly.
Rebecca: And I'm Rebecca Marshburn.
Jeremy: And this is Serverless Chats. Good morning, Rebecca. How are you?
Rebecca: Good morning, Jeremy. I'm doing really well. I just taught a yoga class and now about to have a really great conversation about a topic that I'm not going to give away yet. How are you doing?
Jeremy: I'm doing well. And, it's funny. Cause we were chatting with these guests before we started recording, and they both own pugs. So apparently that's something that brings them together. I actually just brought my dog. I had to bring my dog to the vet. He has to have surgery.
He has a lipoma or something like that. It's like a fatty growth that has to be removed but, I think for me, and then I don't know about, I don't know if you have pets. But for me, the security of my animals and making sure that they're safe is the number one thing. You know what the number one number two thing is for me though?
Rebecca: The security of your guests?
Jeremy: No, the security of the cloud and all of my cloud applications.
Merritt: Serverless technologies?
Jeremy: Oh, somebody just chimed in its Merritt Baer. Oh, so here's who we have for guests today. We have two amazing guests from AWS, both who are cyber security experts. We have the principal AWS office of the CISO Merritt Baer. And then we also have principal security specialist SA at AWS, working with customers every day to define their cloud policies, Megan O'Neill. Thank you both for being here.
Merritt: Yes. M and M, the duo.
Rebecca: M and M will you... will both m's Megan maybe you first and then Merritt. Tell us a bit about yourselves and your pugs, and then a little bit more about what you all do at AWS and what your day to day is when it comes to securing the cloud.
Megan: Awesome. Well, I'm excited to be here. Thanks for having me. My name is Megan O'Neill. I'm a security specialist, SA solution architect at AWS. I've been at AWS for four years now and been in cybersecurity over, oh gosh, I'm gonna date myself here, 15 years. In security engineering, architecture, previous roles.
I actually started my cloud journey as an AWS customer in 2014 for a global retailer based out of Seattle where I helped them set their cloud security strategy and implement controls. And it was so fun. It was just very organic. We actually, a few guys were working on an AWS environment and they kept coming over to my desk and being like, 'Hey, here's what we're thinking for our AWS VPC, you know?'
And so we would like whiteboard it and threat model it on the fly, and it was so fun to learn AWS. After a couple months, I was like, 'Hey, do you have an opening on your team?' And it was just so organic. I moved, I was the first security person on the cloud center of excellence team and we just kept going from there and building it out.
And, so I really enjoyed that. And I did that for four years before then working for a large consulting company to help other customers with cloud security across North America. So that's kind of my history. I'm based out of Colorado. I'm in Golden. And we go up skiing all the time. I'm actually learning snowboarding right now. Which is painful, but super fun.
Jeremy: I I usually ski around all the snowboarders sitting in the middle of the trail.
Megan: That's me. That's me. I'm like, why am I doing this? I can ski. Oh, I like a challenge, so I know I can do this. I just can't give up. So yeah, I took a couple of snowboarding lessons last week up at a Breckenridge. I was on vacation. It was so fun, but ya and then, you know, pugs. Yes. I have been a pug owner for 20 years. But my...
Jeremy: Not the same one?
Megan: No, another. So I had a black pug. Her name was Indi. She was amazing. And then, you know, I just fell in love with the pug. So now I have Rosie, she's six years old. She's a fawn pug. She's quite the character. if she was in my, I booted her out of the office, obviously. Cause if we get any knocks at the doors, she, you know, she's like, 'I protect the family' barks a lot. But she's a character. Yeah. I bring her on every once in a while. If it's like an internal meeting and people love Rosie.
Rebecca: So you're saying that Rosie is also into security.
Megan: Yes, absolutely. Yep. She'll tell us if someone's within like 20 feet from the house.
Rebecca: that's very fitting. That's very fitting.
Megan: Yeah.
Jeremy: So Merritt, you are also a pug owner, but you also know some things about security as well.
Merritt: That is true. We have these things in common. Yes. So I'm a principal in the office of the CISO at AWS, chief information security officer. So we are, as the name would imply, you know, kind of a scaling function for the CSO who now is CJ Moses. And until recently was Steve Schmidt who went up to do an umbrella role.
And we are doing a mix of things. So we take care of the security of AWS, as a shop that runs on AWS. But we talk to customers and see sort of CISO conversations and, you know, helping to establish customer relationships. And then taking the empathy from both of those, we try to inject some security awareness and kind of default behaviors into the ways that our services and products get delivered.
Of course we are a technology company, right? So what we deliver are goods and services. and so making sure that security is embedded and is kind of accounted for which increasingly in cloud is not just clean code, right? It's also architectural decisions. It's how will customers interact with this?
And how does this interact with other services? I came from US government about four years ago, actually, almost exactly four years ago. And yeah, I have worked in all three branches in government and yes, big pug fan and also a big rescue fan. Mine is whatever conglomerate of puggy things.
Rebecca: So you've been in cybersecurity. You said that you came about four years ago from the government. But I think you were there as well for at least four years. So you've been in cybersecurity for, I think at least eight years if I do my math right? So maybe we can just start with an overview of the current security landscape. Like what do you think is the same as eight years ago? What's change?. How much more sophisticated have attackers become? Where do you usually start to level set the field around what security is today and where it's come from?
Merritt: Yeah, I actually, so I was the same year as Mark Zuckerberg at undergrad at Harvard. I made the cardinal mistake of graduating very unhip these days. But it was very evident to me that like these questions around how we want to live, we're going to be important. And especially the relationship between, you know, companies, governments, and citizen consumers, and that security was one of these ways that we define those perimeters, right?
You know, literally and metaphorically. And so I've been in the security world for, you know, eons. But I think that the reason that I care is that there are high stakes around how we construct those relationships, which are really intimate and increasingly intimate. So, you know, to kind of lead into your second part there about, you know, what the threat landscape looks like now, of course we could talk about like what current amplification attacks are taking shape or what, but like, I think ultimately what I see is that there's a lot of luxury in the way that we interact with threats today versus the kind of like server babysitting we had to do 15 years ago. And the cloud is a big part of that. So there is, of course there are always risks.
I mean like any technology is human made and I mean, I could easily say man-made because there was a lot of that, too. Right. but as a, you know, which I say deliberately as in there are going to be imperfections, are going to be corners not seen and things that, you know, like sort of like the beauty and the project of working in tech and in security is the knowledge that like, there is no perfection.
We are in this process driven journey. But at the same time, I think that the kinds of things we see in security today, if you are in a digital transformation, which I hope folks are, you know, as we increasingly believe that folks are moving to the cloud. It's a matter of when not if but that folks are interacting with, they're kind of threat modeling in a way that is increasingly codified.
So you're able to do infrastructure as code. And by that, I mean, you know, cloud formation templates or Terraform, or what have you, that then allow you to embrace this kind of ephemerality and immutability that then allow you to do seamless backups and do auto remediations. And that then allow you to reason about what you have constructed.
And some of you are doing security as code because you are doing infrastructure as code. And those are things that, I mean, even just the ability to have really, tactical and knowledgeable insights around your formations like that at one point required you to go around and do manual checks everywhere.
And now you can reason about those. And there are tools for that too. We have an automated reasoning group, for example, that uses formal methods. But it's just, that's just one example of the ways in which, I think, as we look at security from a landscape perspective, we get a lot of luxuries now to be working in those higher layers of the stack and to be doing, you know, infrastructure in there for security as code.
Jeremy: Yeah. And Megan, you know, you said you didn't want to date yourself, but I was reading like ethical hacking books back in like 1997. So, a long time ago. And I, for the longest time, maintained my own co-location facility, where I had servers and I was doing all of that stuff. And it was horrible and I hated it, but it was also a good learning experience.
Especially the number of times that we did have attacks that we had to mitigate at some point. But I'm just curious. Cause I think, you know, Merritt, you mentioned some really interesting things there about the ephemerality of it, but also there's this whole thing about the elasticity of the cloud, right? And so now if something gets compromised, it's not taking down somebody's Linux server in a, you know, in a co-location facility somewhere. It's potentially being able to launch thousands and thousands of instances across, I don't know, 25 regions or whatever AWS has now or whatever. other Cloud vendor you're using. So I'm just curious the amount of, or that attack vector, I guess the scale of it. Like where have you seen from, you know, 15 years ago when you first started sort of where you are now? Like the threat of that scale, I guess?
Megan: Yeah. I mean, it's funny too, because when you said, you know, back in the day, having, you know, figuring out attacks or like seeing those attacks within like a colo facility, you know, I remember I used to manage firewalls for a large company and we would literally, if there was like a DDoS attack, just all the CPUs on the firewalls would go up to like 97% and we would literally cross our fingers.
Like, please don't go down. And today it's much different, right? If you're seeing like a DDoSs attack on a system in the cloud, for example, and you maybe don't have DDoS protections there. What does that look like? Of course DDoS protections are available. So I would always recommend that customers have that in place.q
But actually spinning things up, you know, it can, you know, if you have an unmonitored region, for example, and you don't have your threat detections enabled so you're not seeing unusual behavior. They'll maybe find the biggest instances that will run Bitcoin mining, for example, but that's like worst case scenario. O bviously we don't want to see customers experience anything like that. And we have many services that help them to prevent those types of attacks. And actually, a lot of it is education and like what types of policies you can put in place to only allow specific regions to operate. So, you know, developers can't accidentally pop in a different region in the console and start building, and then you're like, 'oh, I shouldn't be in that region' or no one can do that, right? So it's almost like setting up those guard rails to make sure that kind of stuff doesn't happen.
Merritt: Yeah, I think. So, Meg alluded to a couple of services that are probably worth saying out loud. One is AWS Shield, which can protect and absorb DDoSs attacks, with what feels like limitless flexibility. And then the other is GuardDuty, which has crypto mining indicators. So like, if you haven't turned on GuardDuty, do it.
Folks frequently ask me for Amazon's custom threat intel. And the answer is: you have it. It's in GuardDuty. You know, you're consuming it today hopefully,. You know, like, it doesn't make any sense from a financial perspective to be Bitcoin mining in AWS unless you're having someone else foot the bill.
So, you know, make sure that you are putting actions on those GuardDuty findings and, you know, as Meg alludes to like, you know, that regional flexibility is a huge enabler for businesses. This isn't, I always have a little bit of, and I'm not poking at you specifically Jeremy, but I have like a pet peeve around people taking what are technologies that matter a lot for, you know, availability, which by the way, is one of the CIA triad and saying, but isn't this a security compromise? Like, yeah did you want to do business? I mean, sure, there are ways that can be weaponized, but like, let's look at how we minimize that risk. And meanwhile, appreciate that it actually gives us a lot of flexibility to get stuff.
Jeremy: Yeah, and I totally agree. And I'm not suggesting, I mean, the, the whole point of infinite scalability or close to it is the magic of the cloud, right? So, of course, there are going to be bad actors that take advantage of it. But like the other thing maybe you didn't mention was, there's a control tower and you can do the SCPs the service control policy.
So you can just basically say, 'you can't spin up, anything in this particular region' or something like that, which I think is super helpful as
Merritt: And there's a couple, control tower helps you establish your footprint essentially, but AWS organizations I think is what you're thinking of, where you have SCPs that you delegate down and increasingly actually, not necessarily down but flat. You can delegate 'thou shalt nots' around so, for example, open resources, or whatever. And you can, of course, always use tagging and ABACs, what is it?
Megan: Attribute-based access control.
Merritt: Attribute based access control via tagging to enforce those and to codify them. Right? Cause we're, we're really talking about are things written in, whatever, JSON or other kinds of codification languages that say, I want to see, 'if someone needs to do this they need to ask me for an exception' and there's kind of this healthy friction and then unhealthy friction between dev teams and security teams, right? And I think healthy friction is like, tell me why you need it. Cause I don't think it should be available to everyone. Or I'm seeing that this team is bumping up against this guardrail all the time.
Maybe our guardrails are out of whack. You know, our security metrics point to this being a pain point. And unhealthy friction is just the security team being like, we don't like it. It makes our life a little harder and we don't care that your business goals are different, right? So I think there's, you know, I think healthy friction is always intended to be there.
Rebecca: So I wish we usually don't play the videos, but I almost feel like we have to, because I wish the listeners could have seen when both Megan and Merritt, you said the same. What was that attribute? You said at the same time.
Megan: Based access control.
Rebecca: Yeah. You both looked at each other through this digital camera and then you both nodded at the same time, like I got you. So let's talk about making choices around services and resources, and this is also making choices around job functions and role focuses. And I think it gets to that idea around friction or where it exists and doesn't, and sometimes like, you know, developing the code and securing the code is like one person's job when maybe it just should not be. And before we get there, there's a quote Merritt that you are well-known for saying,"If it's not someone's job, then it's a hope and hope is not a plan." And I have to say, I had not heard this quote before around hope not being a plan until two days ago in our VP of product at the company I work at, Common Room, had essentially we were talking about, you know, releasing a feature and she was like, you know, and 'hope is not a plan.'
So we're going to do X, Y and Z. And honestly, the chat went very, people were like 'what a quote!', 'That quote is lit. Wow.' Like that's a great quote to start off the morning. Hope is not a plan. So it's been really great to hear that twice. And I wonder now if my VP of product has borrowed it from you and I'm going to ask her.
Merritt: I take very little credit for it. I think it's kind of an Amazonianism, cause I have also heard it from Eric Brandwein. and that's usually who I attribute it to. But it is, I think the idea is that good intentions are not enough that, you know, we believe that humans are, you know, as Anne Frank would say 'inherently good at heart' or something, you know. But that's not enough, right?
That ultimately there needs to be mechanisms to get the job done. And that mechanisms allow us to also scale and to be able to, because we can not only be able to hand over to the next person, sort of a playbook of what we've been working on, but also to allow us to automate away. Because if it's a mechanism that, so for example, our SIM system, initially every SIM gets answered by a human and then increasingly gets answered by a robot.
Because we realized that there are things we can automate away. And then meanwhile, we hire people who love automation. You know, security engineers who can code, which often means we hire devs to be security engineers. Which means that one of their goals is to never close a trouble ticket until you've scripted a remediation, if it can be scripted, you know?
So it becomes this whole, one of the big questions I get is like, how do I build a culture of innovation, a culture of security, a culture of... And it's like, you build a culture of what you repeatedly do. Culture is what you do on purpose over time. And I think, you know, if you want to do those behaviors, then you exhibit them. You know, like, and the way to exhibit them is to create mechanisms to encourage and foster and kind of, you know, grow those.
Rebecca: Yeah. And so I love this idea of like, you're talking about how hiring developers who then become security engineers at times, right? They hold both those, they wear both those hats, I guess, if you will, or they merge into one. And I think this goes back to some recent conversations we've had with guests.
Like our last guest, Tom McLaughlin, was talking about developers doing all sorts of things.
Merritt: [inaudible]
Rebecca: Yeah, and like he was talking about, you know, dev and ops, and then you mash them together and they're dev ops and they need to make a lot of choices around services and resources, and then the security of their applications depends on it.
And so I'm wondering what you think about what both of you, Megan and Merritt think about, especially, as you're seeing probably customers work through this and their cloud policies, how do you think about the level of power and/or burden that's on developers when it comes to building apps that are performant, reliable and secure. What are some of the safeguards they should be thinking about if there was a time when they weren't in charge of security, but now they're in charge of, like, app from end to end. And also how do they build in all those things? So not just coding and then, like, throwing it over the wall and someone else is securing it. It's all those things in one. And so yeah, if you could tell us a little bit about like, how you see this happening in the real world and whether or not it's the right amount of like mental air quote burden to put on someone or how you're seeing that play out in real life.
Megan: Yeah. I mean, I definitely, I think there is a bit of a burden there, but I think there doesn't have to be. And this is where, you know, back in the day when I was a customer initially of AWS, as a security person, not the developer, I was like, 'okay, how there's one person like at this company that is now responsible for security, that's on this CCoE team. So how do I scale my knowledge?' And I immediately went to, 'Well, crawl walk, run. I'm going to create a checklist so that developers can self-service their own security assessments. And so we can be super transparent with their requirements. So I think part of lowering the developer burden initially is just being transparent around 'what are the requirements that are out there that we expect as security practitioners, them to get right?'
And then what are, like, building out internal Wiki of what does good look like? What does bad look like? Why is this bad? You know, because we can't assume that they all have security background, most of them don't. And then how do you do that in cloud? Right? And what, you know, for example, an AWS security group is very similar to a firewall.
It's a stateful source, destination, port protocol. Many of them don't know IP addresses. So opening things up to the world, for example. So, I think starting with those requirements being transparent. And then codifying, and Merritt's mentioned this multiple times, is like setting those guard rails so that those accidental things, they're not meaning to open things up or meaning to make public resources.
It's usually by accident. So, like, let's enable our environment as security practitioners, so that, that cannot happen. For the most part, some of the high risk things can't happen with things like service control policies, you know, not allowing those type of changes within the environment in AWS. And then, what I would love to see more development teams do is create a library of common security patterns. For example, authentication authorization for, you know, serverless, for example, Lambda, authorizers, that sort of thing, that have been approved and reviewed by the security team where it's possible and that are known good practices.
So they don't have to reinvent the wheel every time. And just continue to build out those libraries and code in, literally, in a code repository. So that, you know, other folks, maybe juniors or folks that are new to cloud have some things they don't have to reinvent the wheel. I think the more we continue to build that type of developer experience out so that the easy thing is the right thing to do is going to make everyone's job easier and less security issues, you know, in the future.
Merritt: Exactly. I think we sometimes use the phrase, like 'making the secure thing to do the easy thing to do.' Which is hard., it turns out. But I always think, and of course, you know, never like this is no victim blaming, but every time that an entity says, 'oh, well, an intern did that.' It's like, 'why would the intern have privileges?'
That's on you. You know, there needs to be leadership. There needs to be guardrails. There needs to be paved roads. You know, there should be, it's not to say that you won't have a bad day. We all have bad days. And we have mechanisms to look at what happened and whether it was a known risk, an unknown, an accepted risk, an unaccepted, and to get better over time, right?
You solve problems, you know, one piece at a time. But I do think that, you know, something Meg's getting at here is this, like, need for leadership in terms of, I think, sometimes we see, folks kind of shy away from the technical mechanisms that are very available to them to enforce their, you know, literal dicta.
Like if you believe in math, code will run. And so there's this beauty in the ability to, you know, delegate those down. And meanwhile, I think, you know, Rebecca, you mentioned, you know, hiring devs to be security people, which I think is a brilliant practice and frankly, who are security people? There are people who like to do security, like, it's time to embrace a very broad view of what a security person is., looks like, comes from, you know, does. Because we are all, you know, we are all security people. But I also think that, you know, there is a deliberate delegating down and democratization that we employ, for example, in our, you know, I always, the dev sec ops is sort of like the cybersecurity as a term where, like, everyone hates it and no one has a better version. But in our...
Jeremy: It's like the term serverless.
Merritt: serverless. Yes. And if I get one more clever person saying it's 'someone else's servers' or 'someone else's computer' is the cloud, like, okay. But you know, at the same time there is a real, there is an articulation of that that manifests in the real world, right? And it takes the form of having your dev teams deliver with security embedded in what you do. And I think it is inherently wedded to this transformation of cloud, because you're talking about software layers. So you're talking about folks who are architecting. And, you know, as much as we think that the console is not being used, it's sort of like the perimeter, right?
The console is dead, long live the console. You know, folks are clicking a button to spin up resources in a region in Sydney and/or they are, you know, copy and pasting code that they know has created fairly secure configurations from their previous, you know, Terraform stuff. And, you know, they're taking advantage of the economies of scale that you get when you're working in these software layers.
And I think that is the beauty. Like, yes, there are obviously inherent risks with all of that, but the risk is the convenience and vice versa. And I think that that is actually a really good way. And what we do internally is we have, right now, it's like a one to eight ratio in our, you know, two pizza teams that are doing those deliverables, the dev teams. We have a security person embedded in there. And what we have found is you don't have to hire a person who says they've been into security for 15 years, like Meg & I. You just hire or have a smart person and you say 'you're going to be wearing a security hat'. So every time that they try to create an internet facing endpoint, you're going to be the one who goes 'ahh!' or if you see a star policy you're going to go, 'Hmm.'
And, you know what, everyone can do it. Like, it is not some kind of kiss, you know, the stone that makes you a security person. You think through with that sort of, like, head and that's how we. confront this as an area of work that will always be a pursuit.
Jeremy: Yeah. And you mentioned, you know, the need for leadership but I also think, you know, the need for education is huge. So whether that's, you know, just cloud in general or, you know, dev cyber security, whatever term that you dislike there. You know, it's, again, totally, totally understand that. Especially people would say like anything with the word cyber in it. I never really liked that
Jeremy: You know, so when you start thinking about people getting into this field or somebody coming from the dev, you know, a dev role into a security role or something like that, something I heard you say on another podcast somewhere was like, sort of your pet peeve for acronyms, which I am sort of the same way.
I mean, we joked before when we were saying ABAC, but I think for new people coming into any type of new function or new role or something that has a little, slightly different context to it, acronyms are really, really hard. We joked before, like, you know, a marketing person saying SQL and meaning sales qualified leads as opposed to structured query language and that becoming very confusing, but I'm just curious, and maybe both of you could take a shot at answering this, but if you are new into cyber security or you're, you know, a dev and you want to get into this sort of role. Like, what are the, what are the first steps? Like where's the education there? Where's that path for you?
Merritt: I'll take this one first and let Meg put the foot stomp on it. SInce she has, as she kind of alluded to earlier, really good real life. I've always been the security person in the room. And I think that one of the things that I love doing, I mean, I think that one of the reasons I am a security person is that I love doing that part where I talk to smart people trying to get stuff done, and then I help shape their understanding of what I'm looking for in the world. But I think that this is where, I guess from my perspective, there is every CISO who I talk to ,complaints of a talent shortage. And I think they just aren't looking with the same eyes. You know like they're super smart, interesting, qualified folks who, you know, could take advantage of resources, you know, who you could develop internally. Who, you know, like, especially in cloud, even if you have a computer science degree, it's probably not going to have an AWS aspect or maybe today it does, but it definitely didn't 10 years ago, you know?
Jeremy: I don't think it does anymore. Yeah. I still don't think it does, yup.
Merritt: I think there are so many interesting folks who, and I have made it deliberate in my world too, you know, and I will, we'll give my contact info throughout this, but I'm happy., this is also my little, call to arms. Feel free to reach out to me personally, I will refer you for Amazon jobs that will brainstorm other things in my network. If you were an artist or an architect or a first grade teacher. If you are not a, you know, typical profile of who shows up in tech, great. We need you, you know, just remember that the landscape of what we have constructed here, it's sort of like thought skeletons from people who came before. And as incredible as the internet is like, this is not like a black hole that, you know, NASA is like, this is out here, whether we know about it or not. No, we are building these and we are the ones who are constructing some of these kinds of limits or lack thereof, right? And I think there's a lot of sweetness in recognizing like 'who but we, thought from a security hiring perspective, you know, we are, the water is warm and it's really critical that we have diverse and, and kind of misanthropic thinkers of all kinds who are ready to get in and question why things are done that way while still recognizing that this is a business enabler.
But I think that there is just so much room, whether you're a dev today, or you want to be a dev tomorrow, to, you know, help build yourself up. And also, you know, if you are in a leadership position now to be able to, think through avenues, to upskill folks who work for you and hire folks who may look different or not have gone through the rituals that you would expect before they get hired by you.
Megan: That's, I love that Merritt. I think, you know, the other thing, the other aspect of it is, well, which you already mentioned is that, you know, if you're a curious person and you like, you know, you're analyzing a problem, this is we're just analyzing problems and trying to solve these problems, right?
And I think, a lot of the things I've done, is like, you know, I came out with a computer science degree in 2004, right? And then I did all this other work when I was, a new problem was set in front of me, and it's just like, dig in and read about it. Like PCI, what the heck is PCI. I actually opened up the payment card industry, data security standard, and read the whole thing front to back.
And then it's like, when you actually get down to it and start talking about it, it's actually up to the interpretation of the assessor when you're going through these onsite assessments. So you, really, it's making sure that you're educating yourself and diving into some of these problems and you just learn so much through that.
And through mentorship, I've had mentors my entire career. And I think that's really helped a lot too. And it's just, how do we break down these problems and try and learn more and dive deeper into them so that we have a really good understanding of them? You know, I've been working with Merritt, she's been mentoring me this past year and it's been so great.
Just to see, you know, we do things differently. She has a different approach to things and, it's really opened my eyes and helped me. And it's also empowering when you have a mentor, because I feel like, you have someone to talk to you if you don't know how to solve a problem. And especially in COVID times, oh my gosh, we feel so isolated, right? And so when you have someone that you can, you know, do a quick fly down to Miami and do a recording with and chat about it. It makes the tough stuff seem that much more fun and exciting and keeps you interested in your job and you just learn so much more. So definitely recommend getting a mentor through the process and just don't be scared of the hard stuff. Dive in. Read the specs. Read the GDPR spec. Like, seriously, it's not as complicated as you would think. And then as you're reading these things, you're going to have questions. So you can just, you know, jump on a slack channel with your mentor and be like, 'Hey, how do, how do you see customers approach this 'problem? And, you know, the dialogue continues.
Jeremy: Well, congratulations for making it through that PCI document. Cause the first time I went through PCI compliance, I think I fell asleep like six times trying to read it.
But,
Megan: the thing, right? Reading documents is boring.
Jeremy: Maybe I'm just not as excited about it, but it's good that we have people that are excited, like you.
Merritt: I think Meg's point is look, these were just written by other humans who may not even be smarter than you. You know what I mean? Like it's, and meanwhile, when you know, I think, Meg and I loved to work together because steel sharpens steel, like we were never assigned to, I was never assigned to mentor her.
It was just like, we get stronger when we learn from each other, like being willing to say 'I would love to hear what you think about this or how you would approach this.' We'll help a person to, you know, feel even more empowered that maybe you were onto something. And I think, although we're, I guess, doubling down on this, like, there is a lot around security that feels sort of secretive or intimidating. I encouraged folks to just remember, again, everyone had to learn it at some time and also, you know, some of this stuff that's super fascinating, like cryptography, like the pyramids and the stars. These are things that we have, you know, wrestled with that are worth falling in love with. You know, like there's a lot of beauty there too. It is not just sort of unsolvable problems. It's really kind of inspiring and igniting.
Rebecca: I was actually sort of on the other side of, I was like, wow, you're making this sound really fun rather than boring. It's It's almost that way when sometimes you read a book and you think maybe that book is boring and then you have, you know, a teacher or a mentor or a friend that says like, 'oh, but did you read it in this way? Or did you notice this part?' And then you're like, wow, that is really cool. And it totally opens up that it actually can be, that you're reading it in a way that was boring, but it's because of the voice in your head rather than seeing it for what it is. So anyway, I'm kind of sold. So you had said the water is warm and also hopefully the servers are warm.
Rebecca: And, with that in mind, we only have about 10 minutes. I want to dive into a little bit about serverless itself and you know, the initial move to cloud was followed by all this like, fear, uncertainty, like FUD around security and honestly that still exists, I think in a lot of ways. And then perhaps with each new paradigm, new security concerns are raised.
And so I'm wondering how you've seen trust in the security of the cloud change over time? And then how you've seen trust and security in the serverless corners of the cloud changed over time since it was introduced at the end of 2014?
Merritt: So I think one of the things that I try to do in CISO to CISO conversations is remind them of all the stuff they had to worry about before. All the things that they inherit from us or whomever their cloud provider is.
But in particular, I know about AWS' practices, right? So for example, our nature architecture, where you've got basically like a hypervisorless hypervisor. There is no way to do things with, you know, remote code execution or side channel attacks or other that, you know, like there are beauties from a security perspective, not to mention the unprecedented uptime, the ability to do, you know, patching without any downtime.
Like there are things that we have invested in for years that are now just part of what you feel, but don't think about, I would say, from a security perspective. And frankly, even just inheritances that are how our platform operates. So your security services like GuardDuty and Security Hub and WAF that we've alluded to are obvious, you know, security inheritances in the sense that you can consume those and get to hear any benefits.
But even looking at something like, you know, backup and restore, the ability to clone databases and consider that a canary at the ability, you know, like there's so much sweetness that comes along with the ability to construct and really have your focus be architectural instead of, and I guess this will sound odd, but instead of code based,right? Like we have written the services, they go through our AppSec process, they go through all these things to then be delivered. And so, you know, you alluded earlier, Rebecca, to like, you know, folks who used to create software and throw it over the fence, right? That's just not true for cloud. Like, what we're selling are actually the services themselves and so there is not this like, 'good luck.' The shared responsibility model exists because we don't know what you're doing with your data, because it's deliberate that we don't look at content layers. That's why KMS has no send me your plain text keys button, like that was on purpose.
But at the same time, there are ways that we hope to, as Meg alluded to, you know, educate folks so that they are building security. We definitely care intimately about that. And so, I think, as we move into, so serverless is kind of one of those inheritances, right? Because you now are dealing with codification of what you're working on instead of having to deal with the kind of. literal mass of it. And we see folks embracing serverless for all sorts of things, right? For billing, you know, benefits, but also for availability for remediations, you know. Your Alexa is powered by a Lambda function. And you can write those raw, you can grab them off GitHub, you know, there's a lot of packagedness and then a lot of accessibility around if you want to tailor those for yourself.
And so I think there's a lot of beauty in that. And of course it's imperfect. All technologies are as we have, you know, referenced. But I think there's a lot of promise as we move into this kind of, or are already moving into this kind of like, you know, software defined and software, which means codified defined kind of world. There's so much room for promise there.
Megan: Yeah, I love that. And I think, when I talk to customers and I've seen like the transformation happen, you know, first starting AWS four years ago, A lot of it was just customers not being educated or not knowing some of the common patterns out there that they can use. And so a lot of it is education.
A lot of it's like, I think what a game changer for me personally, back when I was a customer was attending re:Invent because all that is is sharing those common patterns and just, actually, it was really cool. You know, I went to some sessions where it was actually AWS security up on stage talking about how they do threat detection at scale. Which, talk about scale when you're Amazon, you know, and AWS and they're sharing the details of implementation.
They shared that they hire developers. Like, you know what we were talking about earlier, folks that were interested in security, but that could build the systems because you have to build them yourself. A lot of those commercial products don't necessarily scale to the size that, you know, we need. And that really helped me educate me on some of the things how, like, how to think outside of the box on how to tackle some of these security problems or, you know, serverless
Merritt: Meg, was that a box metaphor?
Megan: I mean, maybe. I don't know. Yeah that's good. You know, and I think the other thing there is like that's literally my job as a security specialist solutions architect is. I actually right before this got off of a call, where we talked to the CISO and it's like, 'Hey, what are you guys working on? What are your concerns?' What are you struggling with? They don't have to pay me. Seriously. I'm a free resource to customers. Now I do have to scale across, you know, North America. But, you know, my job is to literally like work with customers, help them get through concerns. And some of that is education.
Like, what are the best practices for this? Hey, we have this issue. Oh, we didn't realize this service could do this. And so a lot of it is actually, is education. And then, and I love to also see, you know, customers open sourcing tools that they've built to solve some of these problems. That's just, again, creates more patterns that are available for other customers to solve these challenges as well.
Jeremy: Awesome. All right. So we're basically out of time, I feel like we could, I mean, I honestly have. maybe like 300 more questions for you, but we're going to have to just limit, just one more. And so I think just we've talked about a lot of things. We mentioned, I think we mentioned audit trail , WAF, we mentioned a couple of other things, Lambda,. You mentioned automated remediation scripts, things like that.
So just quickly, what are sort of the, maybe the top five tools or whatever, the top tools that somebody building an app, a serverless app on AWS, what are the sort of the top security tools that they should use? You know, just throw it out there quickly.
Megan: GuardDuty, CloudTrail, Security Hub, identity and access management.
Merritt: I'm going to be one of those annoying people who refuses to answer the question you asked, but answers a different one. I mean, step one is maybe use a managed service, right? Like just have us manage it for you. Step two is, think about, like, they probably won't even notice all the serverless, right?
Event Bridge is CloudWatch, you know, doing Lambda's under the hood config rules. It's config doing Lambda's under the hood. Lambdas, you can write yourself, you know, like there are all these ways that I think basically I think the real core is one: taking advantage of managed services and being conscious of where your responsibilities lie in the stack. And, two: automation, right? And that takes various forms, but it's going to ultimately be Lambdas under the hood. But it'll feel seamless to you. And that's the beauty of a lot of this is that you don't have to reinvent that wheel.
Rebecca: Megan, is there anything you wanted to add?
Megan: No, I think that's great.
Rebecca: Well, before we, release everyone back into building very secure applications and building a very secure cloud, wanted to understand where listeners can learn more about each of you, Merritt and Megan. And then also of course, we'll put these in the show notes, and Merritt, if you want to talk a little bit about, you know, Tech and Roses and, you know, giving back to women in tech and what it is. And we'll also put that in the show notes, as well.
Merritt: Sure. Yes, folks. Thank you so much for tuning in. Feel free to contact me. I'm on Twitter @merrittbaer. And, yes, you know, I worked on building what I call an expert network of women in technology, which is intentionally, supposed to kind of allow us to ask hard questions around, you know, whether to take this job, whether we can upskill ourselves, how to ask for more pay those kinds of questions for, you know, senior career folks. So if you're someone who's interested, feel free to reach out to me. As you can tell, it's something that I feel passionately about and I think, while really strong inroads is important, we have more avenues for junior folks and fewer for senior folks to be able to talk to each other. So that was where I wanted that to play in and shout out to Deborah Liethen who co-founded that with me, who is a queen. So thanks so much for having us, and I'm happy to share my contact info aftewards.
Jeremy: Awesome. And Megan, you?
Megan: Yeah. I really appreciate the opportunity to come on here. and you know, I really enjoyed this conversation. I hope that this, you know, gets other folks out there motivated to maybe dip their toes in the security pool and join us. I'm on LinkedIn, Megan, O'Neil.
Definitely please reach out. You know, I'm here to help folks as well. And you know, again, thank you so much for that.
Jeremy: Thank you both for being here and thanks again.
Merritt: Thank you. We'll see you soon.
