Ashish Rajan: [00:00:00] Welcome to cloud security podcast today. Our very special guest from us. Her name is Merritt Baer. She works for Amazon and I would not try and introduce her because he’s an amazing lady. I’ll let her introduce herself like a merit. Thank you for coming on the show. 


Merritt Baer: Thanks for having 


Ashish Rajan: me. So for people who don’t know you, how, who is. 


Merritt Baer: Well, I’m a principal security architect at AWS. And I’ve been at Amazon for a little over two years now. I came from us government. I had been doing security on behalf of the American people, working in all three branches of U S government, but I’m not in their, it shops in the security as a vertical world. 


Came to Amazon initially as a principal security architect in global accounts, which is our large accounts around the world, basically fortune one hundreds. So you know, automotive oil and gas, healthcare and pharma, And counseling customers as a solutions architect to the specialist in security. 


And then a few months ago moved to a role where I do strategic initiatives in security and [00:01:00] youngest, emerging tech, including worldwide, rapid prototype. 


Ashish Rajan: Honestly, worldwide rapport diving sounds quite interesting as well. One question we start off with what is cloud security for you? 


Merritt Baer: So I mean, I think to some extent we, we know what security is as a, as both a layman term and a term of art. 


Right. But I think there are a couple of sea changes that happen when we are talking about security in the cloud. Security in the cloud starts with a shared responsibility model. So, we are talking about the basic value proposition of cloud, which is of course that your cloud provider owns and operates and maintains the large scale physical infrastructure. 


So those racks and stacks of servers and data centers, you know, the premise that no one needs to build and maintain their own data centers anyway. And so AWS manages the security of that physical infrastructure from the concrete floor up through layer four of the stack, which is the hypervisor. 


So we’re talking about everything from, you know, guards and gates to HVAC systems. But it also means that in our case, for example, we have custom hardware. [00:02:00] So I’ll have AWS two, which is our base. Mode of compute runs on the AWS nitro system, which is custom hardware that we developed to after acquiring a company called Annapurna labs in 2012. 


So really cool security properties that come with that, in sort of all of the CIA confidentiality, integrity, availability, triad, and for folks who were interested in, in hardware and security aspects of. Yeah, I encourage folks to go on YouTube and look at reinvent and reinforce talks about AWS nitro. 


Another element that we do security for folks in, is in using automated reasoning. So we can verify that our crypto is correct and we can verify their, our boot code is correct using mathematical logic. So knowing now that infrastructure is code, being able to prove things with mathematical certainty, these are the kinds of things that we provide as a cloud provider that help a customer and entity to, increase their security five. 


A lot though, of what your audience is going to be interested in [00:03:00] is on the customer side. Right? So the security in the cloud, not the cloud. So once you are storing and we’re using cloud assets, how do you protect those? And for that, I really think there are a lot of defining characteristics here. 


We’re talking about, the way that cloud enables you to do better work in general, you know, Some folks move to the cloud because of security, but a lot moved because their development teams are the ones pushing for it. And so just being able to do more, so moving to a dev sec ops model, for example, where instead of having your security teams siloed, you can integrate security into every aspect of what you do. 


So moving from a. Waterfall to an agile development methodology where instead of long, you know, 6, 9, 12, 18 month timelines on your development goals, you’ve got short sprints. And of course, that, that lines up with the cloud model where you can, by. And only pay for what you use on demand and be constantly reassessing your development goals. 


So injecting security or [00:04:00] infusing, you know, everything you do with security is something that is sort of inherently cloudy when we talk about that kind of model. And then the ability to automate. So the fact that everything in cloud is an API call. The fact that everything is you know, logged. So. 


All API calls, even attempted ones that don’t go through our allowed denim CloudTrail log, for example, all of these elements are part of what is inherently security in cloud and what defines I think the gains that you could make. 


Ashish Rajan: Sure. And I think you’re absolutely right on, on the security in the cloud is quite different to security, I guess. 


On the cloud, I guess, on the cloud, in the cloud, we 


Merritt Baer: say you get the idea. Yes. Layer layer, whatever, zero the concrete floor up through layer four, or what AWS owns and maintains. And then layer four up there, layer seven, which the customer. Of course, that makes sense. Right? Because the application layer are the ones where customers are making architectural decisions and they know the applications they’re using it for, you know, for those who kind of wish that AWS could just secure it for you. 


[00:05:00] You know, there’s no without knowing what you’re trying to do. So some of this, you know, a lot of these decisions, for example, having an S3 bucket open to the world, that might be a deliberate decision. There are lots of use cases for that, like hosting. Yeah. And so those architectural decisions, should be used with a security awareness, but we can’t do it for you. 


Ashish Rajan: Sure. Sure. And I think so I’m going to say it, say it again, just for the, so that’s right. So security off the cloud of AWS security in the cloud as the customer, very different what the board or the things have really different lens to it. And to your point about security in the cloud, do you see multicloud as a thing coming up. 


Merritt Baer: Yeah. You know, most customers, if they are doing a lot of cloud have multi-cloud I hesitate to use the word strategy, because I think it often ends up being sort of an accident. I think, you know, development teams from different parts of an organization often end up moving forward in different directions. 


And so they ended up with multicloud. Even if it hadn’t been a coherent decision, but yes, I do see it common. Right. 


Ashish Rajan: And so just to clarify for you multi cloud, Different cloud [00:06:00] providers or is it because some people say multi-colored is SAS and my AWS, or some people say SAS, only some people say it’s the different cloud providers like Amazon Azure or GCP and hybrid. 


Like what, where does multicloud for you in this country? 


Merritt Baer: I think of multicloud being, yeah. Either you’re using more than one cloud provider and or maybe your own, cloud. 


Ashish Rajan: Oh yes. Perfect. And in that case, do you, how do you see security evolve? And maybe it could be a customer use case as well, where you would have seen a customer do a great job at it. 


I feel like scaling security across multiple AWS accounts and net in itself could be a challenge a lot of times. So. Maybe first question could be, how do you see people scale security across say hundreds of AWS accounts? Who does it effectively? 


Merritt Baer: Yeah, so I think there were a couple of questions kind of nested in there, but I do see customers face of the challenge of trying to do multi-cloud security. 


I think that for those who have not yet made a decision, it does make sense to pick one cloud and go with it because you benefit from the [00:07:00] visibility from the, you know, tactileness or whatever the right word is for being able to, execute on your decisions in a more uniform way with one provider and the kinds of mechanisms that. 


We’ll have, that being said, as I mentioned, there’s lots of folks who are dealing with multiple environments, both because they perceive competitive issues. And because I think development teams tend to kind of run. And I think that if you’re managing security at scale, you know, there’s a lot of different elements here that will be helpful to you. 


Doing more cloud native approaches, which involves a lot of automation. So making front end decisions about your security. What are you going to be at your protective detective and reactive controls? And by that, I mean, protection is things like identity and access management. So what, what are some actions that you are just going to allow or not allow and then have the political will to standby, detective being, what are you going to allow, but put, alerting and alarming on and maybe, you know, customized thresholds around for sophisticated. 


And then and, and some examples of that in [00:08:00] AWS would be CloudTrail, which I mentioned as API calls, cloud watch, which monitors things like CPU usage, guard duty, which is the identity IDs IPS. You know, there’s lots of examples of this config, trusted advisor, et cetera. And then reactive or remediate controls. 


So at, on AWS, these usually look like a Lambda function under the hood. And some of these are just Lambda functions, but they’re also things like CloudWatch events, config rules, things that you can explicitly configure to go in. And when you hit a threshold, go take an action remediate on, on those controls. 


So the way to scale. It’s the same problem that AWS frankly, internally deals with, you know, Amazon is a large enterprise. We built AWS to serve Amazon. Initially in 2006, AWS basically came to market. After we recognized internally that we had developed as core competency in building and maintaining and securing large scale physical infrastructure. 


So what we do is we try. Minimize that gray area of [00:09:00] decision making. So make as many decisions ahead of time as you can, and make them coherently and uniformly and have your architectures reflect those kinds of best practices so that you aren’t in the moment, leaving it up to one human decision-maker. 


To try to make those judgment calls and, you know, cloud is especially enabling of those kinds of things because of the ability to interact with infrastructure as code means that you can do security as code, you know, the ability to enact Automation across the board. And, and then I would say that the final piece here, or one of the, one of the later pieces, if you will, in kind of thinking through this is how to enact things like escalation as a culture, you know how to catch up your cultural elements with this, how to make sure that your executives buy in so that you escalate all the time. 


And so that it’s not up to one person to decide when you escalate so that you do it as a matter of. 


Ashish Rajan: Oh, so to your point, escalating it throughout the leadership health. In scaling security to your point about the cultural aspect, because you may have the best automation in the world, but if there is no support from leadership, then it’s kind of pointless, 


Merritt Baer: right? 


So [00:10:00] leadership needs to buy in from the start. And I think it is the security community at your organization’s job to get that buy-in right. So get them to connect the dots between that AWS abuse, email, that flags for you, something is wrong and you know, what kinds of actions you’re going to take around it, which should include an escalation. 


Yeah. We do not think of escalations as a negative. We think of them as the course of doing business. But what that means is that at AWS, you know, our socks are 24 hours. You know, operations team is a person with a cell phone, because we’ve automated so much out of it. And because the escalations will kind of run their course. 


So we catch things as they go. And we don’t wait for someone to feel embarrassed about it, or to wonder if it was there. Or to not understand what the alerting means. You know, we just escalate as a culture. And I think that means that your executives need to understand the importance of security. A hundred percent of executives will say they care about security, you know, but actually getting them to put some meat behind that, to commit to you know putting political will behind your security [00:11:00] team, if they need to put in place, for example you know, dev and test pipeline. 


To separate your operational assets from your research and development assets. That may mean that there are a few restrictions on what your developers can do from time to time. And they have to put in a support ticket to move things into production. Let’s say, you know, some developers are going to feel frustrated with that and that tension will need to be supported. 


I mean like your, your executives need to buy into the importance of security. From the ground up and, and your security team should be invested in continuing their commitment to the importance of security and getting, you know, getting them to understand the importance of being the person who answers the phone. 


Ashish Rajan: Sweet. And to your point about, I guess you would have seen a different breadth of people doing security in AWS, in different sizes and probably in different maturity level as well. What’s an example of a low maturity versus a high maturity. 


Merritt Baer: So I hate to say low maturity versus high, because I guess that sounds so valued judgment E even though that’s probably fair. 


So I would [00:12:00] say that, you know, you, you see organizations that have different characteristics over time. And I think that organizations that are kind of, you know, box huggers that are still not embracing the benefits of cloud are ones whose security strategies reflect that culturally as well. So. 


For example, you know, doing everything manually, having not taking advantage of the fact that you can push updates automatically that you can push them instantly, you know, being trapped in kind of the old cycles that used to take. Time. And instead of, you know, the more sophisticated or, which are, you know, everything from startups to really large customers like Netflix and Airbnb and Pinterest are folks, you know, so you can do this at scale, but they are folks who are really leaning in and embracing this culture of innovation, but with security as a part of the, you know, the DNA of what they do at edit AWS, security is job zero by which we mean, you know, there’s no tacking it on after the fact. 


So I think that that perimeter based [00:13:00] mentality is associated with these kinds of legacy thinking places. And I think the more you can grow up your mentality and embrace the gains that you get from cloud, that will be reflected in your security approach as well. 


Ashish Rajan: Right. And I think that I’ve always found the F the common that, or an Amazon securities is job zero. 


Very interesting. What are the examples of this that you’ve seen where you feel that oh, yeah, they definitely think it is clouds. I mean, it is jobs zero, because you’re, to your point, alerted a lot of leadership, say, yeah, we do security. I understand security, but how many actually go down the path? 


Merritt Baer: Well, so, I mean, I think that. 


We, I can say personally that we use, mechanisms that are processes that reflect that cultural belief. So one example is you don’t close. So most folks are captive to some kind of. Security ticketing system. We are no different. We are no better. However, one thing that we do is you don’t close your security ticket until you’ve scripted the remediation. 


So the idea is that you only solve a [00:14:00] problem once that you never have to solve the same problem twice that you then automate around it. And then that’s why we can have the person with a cell phone. The SOC, versus a whole team of manual operators. So that’s one example, but you know, I think the point is that it is communicated from the top down that folks are not free to ignore the security team that even that which is perceived as being kind of, a holdup to development needs to be a, let’s get to. 


And you know, our security folks then of course have that culture to where we are builders. And I think we don’t perceive ourselves as being, it, you know, locking horns with the rest of the org. We perceive ourselves as being enablers and trying to make the secure thing to do the easiest thing to do. 


And, you know, we, although there are those two sides of the customer responsibility model. We care deeply about what our customers do. And Amazon is one customer of our, you know, one large customer of ours. So we get their feedback as a large user and also as a, you know, a set of inputs into what we decide to [00:15:00] do. 


So it is kind of. You can have big and small examples, but I think the idea of creating a place that lives by, you know, that mantra of prioritizing seniority does not mean that you need to be a place that locks everything down. We tend to actually. The posture that we allow folks to run pretty far, but we put lots of alerting on their use of resources. 


You know, we try to make it as transparent as possible that the times that they are using resources, any time they change a configuration from a default secure position, for example, they’ll get alerting in internally and we try to like live and breathe the kinds of advising that we would give to other. 


Ashish Rajan: Yeah. And that that’s the most amazing part because there’s always every time I’ve spoken to someone from Amazon, they’ve always either had a real life example of security incidents, but also have seen it done at scale, which is kind of one of the reason I kind of have been a fan of. I feel like cloud allows you to have that automation scale security, which I don’t think it was possible in the regular data center world. 


So it’s an awesome onset. I was gonna ask in terms [00:16:00] of doing security and I guess monitoring threads, and you kind of mentioned you’ve moved into the the rapid prototyping space is in that space. Is that. Like a specific industry or is that, I don’t know how much you can talk about it, but it’s more, I’m curious in down. 


So do you see anything interesting in that space from a security perspective? 


Merritt Baer: Yeah. So there are some interesting challenges in that space. We are working through. Working in code development you know, processes with customers, which is interesting. But basically the rapid prototyping team is not an R and D team. 


So we’re not coming up with net new technologies, but we’re coming up with new applications or exploring ways that we could build with the customer, given their use cases. So we’re working on. You know, at a cultural examples in, let’s say agricultural IOT sensors, we are building in the AR VR space with retail. 


So, you know, trying on clothes remotely, there’s tons of, kind of interesting current examples and they are constantly changing. And now with the. You know, emergency, we are looking at how we can help, but with folks who [00:17:00] are prototyping and in that space as well. And so I think it will continue to be a space where substantively we are, looking at what’s coming up the pike and we are trying to think through how we put together the technologies that we built to respond to and think through the ways that we can co-develop with. 


In terms of security considerations, that’s all the ones you would imagine, right? Everything from, how do we vend to accounts for folks to kind of tinker around with both on the AWS side and with the customers to, how do we maintain the lifecycle of security on the products that we co-develop, and then do a smooth handoff of responsibility for you know, to customers for those prototypes that we’ve developed so that they can continue running and scaling those, and you know, security. 


An element of the kinds of viability that we are trying to ensure when we’re doing 


Ashish Rajan: so, is it easy to make them understand? And I imagine people who are doing prototyping of as a, a COVID solution or something else, is it easy to make them understand the importance of security or doing security foundations in the. 


Merritt Baer: Yeah, it’s an interesting question because I think we see [00:18:00] anytime there is an urgency it’s always tempting to say, we want the fewest number of defense dependencies. Therefore we’re gonna, you know, think about security later. Right. But I think there’s something inherent here about cloud two that I want to come back to, which is that your architectural decisions will be reflective of your security. 


So ensuring that, you know, as you go through your vending accounts in a way that is consistent or your, let’s say the way that you’re storing data that comes off of sensors, that you’re putting that, into a lifecycle storage system. So you’re moving from hotter to warmer, to cold storage, both for, you know, billing, but also for security sort of retiring. 


That you’re doing encryption at rest. And in transit that you’re doing, these are all good protocols for how to, you know, develop how to, how to live at your development goals as well as your security goals. So I think the most successful folks are the ones who do we that in from the start. But it can be. 


For folks who are still caught in that perimeter mentality, it feels like it will be an extra [00:19:00] cost or it will be antithetical to innovation. But I think for folks who who sit in with it and who fully embrace those kinds of benefits, we’re talking about where you can scale up and down, you can have a femoral attributes, you know, like security and cloud is different. 


So if someone pops your web server and you kill it and spin up a new one, you haven’t solved your. You know, so thinking really more holistically about your architectures and how you’re going to get to those root causes. But of course you have more tools to do that as well. So using infrastructure as code, as I’ve mentioned, means that you can have security as code. 


So you can have cloud formation or Tara forum or whatever templates you’re using. You know, you can look at what are some of the architectural best practices you can have, defense in depth, so you can have least privilege and you can enforce that. That is, or Validate that that is what you are enforcing by doing the kinds of tests architecture is, and, even mathematical enforcement that you can do with automated reasoning, for example, with cloud, whereas you couldn’t necessarily do this when you were just building and maintaining your [00:20:00] own servers. 


Ashish Rajan: Yeah. And to, to your point maybe if you go a layer deeper on that one, because a lot of times our devs would say, well, How would it be a security problem? And we have, the instance is no longer there and we’re killing all the containers. A moment is something wrong. I’m curious to know your opinion on how does security work with those kinds of scenarios where the right. 


It doesn’t exist anymore after that. How do they best prepare for this? Because to your point, a lot of the audience may already be in that perimeter based security. They already have accounts being vented out without any security guardrails or security definition. It’s almost sounds like, oh, it’s a mess icon. 


I don’t know where to start. So what’s your recommendation for people who are already in the middle of, I guess, an environment where people have been creating resources and deleting them, you know, ongoing the affirmer resources. How do you, what do you recommend for someone to start? And then. 


Merritt Baer: Yeah. So, I mean, we get customers frequently trying to sort of wrap their arms around what is already out there. 


And we. Recommend sort of a carrot and stick method with [00:21:00] your employees where you encourage folks to sort of validate what they already have out there. Including just the accounts that they have. Because we, you know, like we may not have. Certainly AWS treats individual accounts as customers. 


And we may not realize that joe@comcast.net is building in a customer’s environment. And so, you know, customers should try to get arms around that by doing some of the you know, tools that you have for getting our arms around accounts. I think that there are elements of. AWS is a services that help you try to do that. 


So one would be to use AWS organizations. This is a top-down way to have your folks build out and you have what’s called SEP is I think it’s service control policies. And that, that third I can I know that’s the acronym. But anyway, you can whitelist and blacklist services, for example. So you might want to white list cloud trail so that none of your employees can turn off the logging and monitoring. 


And then you know, let’s say that, you know, they don’t need to use SageMaker, which is, you know, our AIML out of the box solution. Well then maybe you just [00:22:00] say, you don’t need to use that and we’re gonna, we’re gonna put that on, like, do not allow. So that’s one way to do it. You know, you should always be doing, SSO and Federation and multifactor authentication and, you know, getting some of those large scale, best practices for identity and access management at scale. 


And then we have tools like within the automated reasoning group, there are a couple of tools that may help, One is called Zelkova and it will compare I am policies and tell you which one is more permissive. And another is called Tyrus. This will do network reachability. This is now part of inspector. 


And it can tell you without sending a single packet over the network, what are some of the potential. So things like that, you know, use math and logic and the formulas themselves of the policies to be able to tell you about your network. It reasons about the possibilities of what someone could do. 


Ashish Rajan: That’s really interesting. And to your point about. I guess a feeling trapped with services. It’s a very common thing that I hear and develop like, oh, you’re trying to control what we’re trying to do. [00:23:00] You’re trying to control creativity. How do we come up with new features? If you block all the services, how do you respond to that? 


I always find it really challenging to answer that. So I’m keen to know. And you have developers telling you that, oh, if you’re a blacklist or whitelist services, we’re we, we found. We find out that it’s bounded by like, oh, we can’t do anything. There’s no freedom for doing anything. 


Merritt Baer: Yeah. I mean, I think that these are the judgment calls that your security team is supposed to make. 


Right. And that’s why I mentioned the political will to enforce them. So this comes from the top. This should come from your executives. But it should be. Deciding on your security posture and your risk posture and the kinds of decisions you want to make around resources will be something that, that evolves over time. 


So your these are processes there’s, they should not be static and maybe you know, a development team that didn’t have need for one. Before now has a justification for why they do need it, then maybe those change. But but I think the idea that you use your security controls in kind of a fine-grained way to ensure that you’re responsive to the needs of the organization, but [00:24:00] trying to minimize folks going off the rails is what every sophisticated organization does. 


And, you know, the worst case scenario is that they have to put in a ticket. So I’ve seen people, you know, I’ve seen organizations make judgment calls. Like we’re going to allow you to build that insecure architecture, but send you a notification that we’re going to kill everything in 15. Unless you resolve it. 


And so it kind of forces people. And how much can you really have built in 15 minutes that you then list, right? But it, it forces people to then go to their security team and say, what was I doing that wasn’t conforming here, and, and kind of learn, and, and for their security team to learn about their use case as well. 


And. Those kinds of back and forth are constant and healthy, and we should expect to see those kinds of processes change. And meanwhile, you know, you can do plenty of work in that sandbox with you know non-production data, that would allow you to have a lot of freedom and, you know, like your R and D teams. 


Have more freedom than ever to be able to spin up and down resources and not have to pay for all of the compute power that they need. For example, if they just need it for certain periods of [00:25:00] time and, you know, there’s ways in which freedom as well. 


Ashish Rajan: Yeah. Or so, oh, I liked the idea then. So use a Sanford account for whatever experiment you want to do with SageMaker or whatever else, but the dev test. 


Is saved from it because that potentially has access to sensitive data. It may not be production data, but still sensitive company data, I guess, is that, 


Merritt Baer: I mean, anytime you are dealing with real data, I think that you’ll want to follow your InfoSec processes for an, and it’ll depend on the. Industry like how regulated and how sensitive that is, but any real data has some level of sensitivity. 


And so I think you’ll, you would want to ensure that you follow your organization’s protocols around that, and hopefully your organization has put in place protocols around that. Right. But you can be playing around with the tools themselves in, in yeah. Sandbox accounts and get an idea of what you want to build. 


And, you know, like you can be doing a lot without. The data itself and we certainly have trainings and we have credits, we give out for folks to get up on things and, you know, like there are [00:26:00] definitely tools to be able to play around and that’s something that we, we do internally as well. 


Ashish Rajan: Cool. And that’s a great way for me to move into our next segment as valid as MythBuster w what’s the most common cloud security myth or misconception you hear? 


Merritt Baer: I don’t, I don’t think you can make a blanket statement like the cloud is secure. However, I think it would be perfectly defensible and make sense for folks to move to the cloud for security reasons. It allows you really significant visibility. So you can see every API call that was attempted and who attempted it and what the outcome of that was, for example, it gives you the capability to, you know, throughout the security life cycle. 


To have tools that you would not necessarily have access to, or if you would have developed them in house, it would have taken a lot of work. So things like guard duty, for example, our IDs IPS we’ll, we’ll look for a nominal anomalous behavior. And it, it works on data sets that we, you know, like we, we have our own. 


Kind of special sauce that we inject into it. [00:27:00] And then it also looks for all the common vulnerabilities that we would expect it to look for behaviors like crypto mining, you know, from known, known bads. And then there’s things like Amazon detective, which came out recently, which allows you to actually proactively go hunt, or, and to do investigations. 


So that’s the kind of thing that would have taken a lot of resources, both compute and human until cloud. And, and now you can use. Kind of pre-packaged engineering resources that really allow you to make strides in your security program. Even just the idea that you could keep all of your security tickets for the last month or year, and as long as you’re protecting them and, you know, classifying the data and being defensive about how you maintain them, you and responsible, you could be running security analytics on those data lakes and extracting, like, what did we learn in the last month of security? 


So, you know, like these are sophisticated operations that customers are doing, and that folks really weren’t doing anything before cloud. That being said, I think that, you know, folks do experience burn when they moved to new systems and it’s totally understandable. Your [00:28:00] developers need to learn stuff. 


You know, it’s one way that. AWS has emerged as a front runner because, you know, we were talking about multicloud earlier. It’s, it’s a lot to have to learn more than one system. And I think that, folks generally will If you’re talking about partner solutions, for example, they will build it to be interoperable with one, maybe two, maybe three. 


And you know, some of the lower market share providers are just not going to have the same range of providers that we do in terms of partner network and the kinds of solutions that you find for security there as well. You know, like there’s a lot of ways in which we can walk through what this looks like, but certainly I think it makes sense that folks do move to the cloud for security. 


Yeah. Having said, I think the main driver is the innovation side. It’s the development side. It’s the, all the things that you can do with cloud. But but no one would do anything if they didn’t think they could. 


Ashish Rajan: That’s right. Innovation is definitely a key. And I think for me, as well as a key driver, for me, anchoring people to go into the cloud. 


One last question in this segment is what, what are people not talking enough about [00:29:00] cloud secure? 


Merritt Baer: That’s an interesting question. 


Ashish Rajan: What would you want them to talk more about cloud security? I guess that’s another way to say it. 


Merritt Baer: I think that I’m going to sound like a security person here and also a lawyer where I have a lot of great. But I think that it comes down to process. So I kind of referred to this earlier with culture around DevSecOps, but, We always referred to the fact that like, you know, good intentions are not enough. 


There has to be a mechanism. So our, we have a distinguished engineer, Eric Brandwein who has a quote that says, if it’s not someone’s job, then it’s a hope and a hope it’s not a plan. So, you know, one of the ways that Amazon. You know, in varying degrees of success, but has had a track record of entering a lot of different markets from, you know, becoming an online book seller to now be in a cloud provider and everything in between with ring doorbell and whole foods and Alexa and everything. 


The way that we have approached that is by being a process-driven place. And so I think that ultimately the gains that folks will get are when they focus on building that cultural growing [00:30:00] up as we were talking about. So focusing on automation, focusing on infrastructure as code, focusing on everything as an API call and all the kind of gains, and that enables you to have. 


Interactions from the command line there ways that I think folks who, if you have not yet taken advantage of those, those will be huge gains for your security team. And it’s going to be a process-driven acclimation and that’s not sexy. And it doesn’t have like the, you know, but I’m Ching making people eat their Wheaties. 


Doesn’t like make the headlines every day. But that to me, The growing up that needs to happen. And the folks that do this well, you know, Netflix and, you know, AWS ourselves, we do this just as a, we build a mechanism to make sure that it gets done. 


Ashish Rajan: Sweet. No, that’s a great answer. Am I right in saying, so you did a law degree. 


In cybersecurity or did he like the line to cybersecurity? 


Merritt Baer: So Harvard law doesn’t give degrees in cybersecurity, unfortunately, at least not yet. But but I was, so I was mark Zuckerberg and undergrad at Harvard. And this kind of [00:31:00] came for me by 


Ashish Rajan: hooker. 


Merritt Baer: I was, I, I was uncool enough to actually graduate, but a year in undergrad. 


So, you know, I was put on the Facebook before it was even an option to opt out. And. So in some sense, I saw these issues of like government and civilian, consumer and tech companies, or just companies writ large, you know, writing this future that we had collectively. And I felt like there were not enough folks who were really, thinking deeply and also had all of these kinds of toolkits, at the table. 


To be honest being a woman, I think it helps to have a Harvard law degree. If I’m, if someone is there being like, what about the first amendment? I can say, what about it? You know, it just, I think, you know, for folks who sometimes fight against the tendency to, under estimate. You know, folks who don’t look like the typical developer. 


For me, I felt like a lot of gray would give me some, 


Ashish Rajan: that’s an interesting point cause I had one of my previous guests she’s actually from Washington DC as well. She talks about, online security awareness [00:32:00] and we kind of got into this conversation and I’m curious to know your opinion on this. 


Is it important for a woman to be technical? If they’re in cyber? 


Merritt Baer: This is kind of a trick question. Because I think too, if I’m being completely honest, I think it definitely helps. I think because of the sort of hierarchy of, Of prestige in the security space. I think that being technical is a real asset, but of course, you know, how we define technical often revolves around already preconceptions about what is sort of woman’s work. 


So like project managers and project managers, product and project managers tend to get less. Pay less respect and everything because they are doing what I consider to be sort of like more feminine tasks. And I think while that is too bad, that is just kind of the state of play. So for women who are looking at this space, I would encourage them to get as technical as they are interested in, you know, to carve out. 


Time to make themselves technical. Of course it is not a requirement that you speak every language or, you know, code in every language. But I think any [00:33:00] technical skills you have will be an asset to you. And I think that you know, we can also collectively work as a community to ensure that we value folks who are in jobs that are not sitting and coding at a computer every day. 


That is a one dimensional definition of, you know, what. 


Ashish Rajan: Sweet. Well, I guess next section is basically a fun section, basically. Non-technical the first question for one section is where do you spend most time on many north working on cloud or technical? 


Merritt Baer: It’s kind of a trick question. Because a lot of what I do does kind of, I mean, like whether it’s, you know, going to drinks with friends to talk about ideas or whether it is, you know, reading up on stuff, but because I’m always trying to, self-educate, there’s never a point where I feel like I know enough and that’s one of the things that I, I love about this area, but it also makes me feel a little bit. 


Breathless about learning new things. I’ve always got things on deck that I want to teach myself. But when I’m not let’s say I bought I’m a, an amateur boxer. If I were 


Ashish Rajan: MMA boxer or is it like a 


Floyd made by the kind of boxing. 


Merritt Baer: Yep. Traditional boxing. And [00:34:00] I like to cook and go to wineries and I do work around, women in tech. You know, I’ve got a group called tech and roses that is like an expert network for women to be a resource to each other. And I have a 12 week old on Wednesday. So yes. 


Thank you. So all of those things are, are, you know, elements of joy for me as 


Ashish Rajan: well. I just want to quickly touch on the tech and roses. You mentioned for anyone who’s listening in I guess, is that a community or is that a meta. 


I guess. 


Merritt Baer: So I encourage folks to reach out to me if they would like but this is one that’s based in DC. So if you’re based in DC and you’re you identify as a woman in tech, then you are more than welcome to you know, inquire about joining, but the. I conceived of this group with another woman, Deborah , who is a former FCC cable media bureau, chief. 


And we put this together to be not a mentorship kind of relationship, but really an expert network for us to be a resource to one another. So we talk about current events, but we also talk about like how to negotiate. Pay or how to, figure out what to [00:35:00] do if your boss has a creep or, you know, just things that are strategies for survival, I would say. 


And I think, and because of that, it is a fairly small group. We’re usually around six or eight women who meet once a month and now virtually. In DC in person, but I encourage folks around the world. If you think this sounds like something that would be a value of us to you, I’m happy to kind of share sort of like lessons learned. 


We’ve been doing this for four or five years now, in terms of like what works and structuring the time and deciding how to, you know, get membership and, and maintain it in a healthy way. And, and those 


Ashish Rajan: kinds of. That thing that I’m sure a lot of people in the audience would love to hear more about that, but I’ll let them reach out to you separately for it. 


The next question is what is something that you’re proud of, but it’s not on your social media. 


Merritt Baer: That’s a good question. So. I am going to use this to plug for I’m working at Amazon, but I’m, I’m kind of proud of how I came to be there, which is that I am an adjunct at university of Maryland university college, which is, a, a school that does a lot of online courses, [00:36:00] especially for nine 11 bill. 


So military veterans, and the. I got recruited into Amazon. The way that I got recruited was through a former student of mine. Who’s like a mid fifties black guy in Amsterdam who had taken one of my classes and reached out on LinkedIn and said, you know, have you ever thought about working for AWS? And I said, I’m a business person put an offer on the table. 


So anyway, I did a call with the hiring manager and kind of started the process. But I guess my point is I think I’d like folks to. Embrace the fact that they might not look exactly like a job description or not conceive of themselves being exactly a software development engineer. There’s lots of different types of roles at Amazon. 


And I am proud of the fact that I. Not only kind of lived that model, but I am an advocate for it. So I have offered often on Twitter and continue to offer that if folks are interested in talking about jobs at Amazon or even more generally, I will commit some amount of resources to Referring you with, if you send me your resume and the job numbers you’re interested in, [00:37:00] I will refer you for Amazon jobs. 


And if you’re interested in talking about other roles in technology, I will, you know, set aside 15 minutes to talk to you and to kind of help talk through what some of those options could be. 


Ashish Rajan: That’s an interesting one. And just on you become being a business person before joining AWS, I find that a lot of people who used to be business owners had joined AWS. 


It’s just super bizarre for me. Like why would you move that way or why that transition? Like what was your reasoning? 


Merritt Baer: That’s funny. I actually think it makes perfect sense because although AWS is like this huge organization and Amazon is even larger. A lot of us, you know, there, the cliche is that we said we work on two pizza teams. 


Which of course, I always joke that like that could feed quite a few women. Thank you very much. But but I’m, I’m being kind of pat there too. Of course. But the, the kind of mentality at Amazon is that you are startup that you that there’s very little red tape. Can have ownership over ideas and build them out. 


And I am an example of that in the sense that like the job I’m doing is one that I scripted for myself and it is a job to cook up [00:38:00] ideas and build them out. And so that in itself, you know, looks a lot like entrepreneurism. But I think that, you know, there’s, there’s pros and cons to running your own shop and to working in small organizations. 


And, you know, Amazon has obviously a lot of pros and some cons, but I think that it attracts a certain, type of person who really likes to cook up ideas and run with them. And we have a process for that. Which for us revolves again, having a mechanism. Right. But for us, it revolves around writing. 


So you write up what’s called a PR FAQ. So, PR. Public relations frequently asked questions and you pretend like you’ve already delivered this thing that you’re cooking up. And then how would you write about it in the press? How would, how would you publicize the fact that you had created this and when, why should people care about it? 


And so folks will start a meeting with having people read this narrative and then start to discuss the merits of it. And that is a process that works at Amazon. You know, we put a lot of weight on being an effective writer and I encourage folks who are listing, you know, We’ve talked about technical skills. 


You know, one skill that is [00:39:00] just an non-negotiable is being a decent writer. So that’s, I think another characteristic that that is part of that thread of entrepreneurism, that we have those of us who have worked in business before latch onto, and we recognize as something that is important for me to be to in when we are at Amazon. 


Ashish Rajan: Final question is what’s your favorite cuisine or restaurant that you can share with the audience? 


Merritt Baer: Well, this is just mean now because restaurants aren’t open. I love a good Mexican restaurant, but that’s just because every time I go, I feel like I’m at a party. You know, something festive about a margarita. 


But I would say, you know, pretty much anything exceptional, like American farm to table. 


Ashish Rajan: That’s kind of the wrap for the show. Thank you so much for spending the time with us. I find it really informative. I’m sure the audience did as well. Where can they reach you on social for, for the questions? 


Merritt Baer: Yeah, so please feel free to overlay this over the interview as well, but I’m at merit. There is my Twitter handle. 


Naira bear Merr, B a E r@amazon.com is my email. Don’t send me crap, but send me your resume as, and job [00:40:00] questions. And you know, I, I put that out in good faith, I guess is what I’m saying. So, but I I’m happy to connect with folks who are also looking to connect. 


Ashish Rajan: Sounds good. Thanks so much for thanks so much for this. 


Really appreciate you coming on the show. 


Merritt Baer: Absolutely. Thanks for having me.

‍