Uncategorized

Ep #107 – An AWS Security Guru’s Recommendation for Securing your AWS Infrastructure

Thumbnail10747


Over 90% of security breaches in the public cloud stem from user error, and not the cloud service provider. Today, your host John Verry sat down with one of Amazon Web Services (AWS) own Temi Adebambo, to understand what is going wrong with public cloud security, and how you can eliminate your biggest risks.

This episode features Temi Adebambo, Head of Security Solutions Architecture at Amazon Web Services (AWS), to explain exactly what’s going wrong with public cloud security, how users can eliminate their biggest risks, and much more.

Join us as we discuss:

  • The 2 mistakes public cloud users make that cause the most security breaches
  • How using “higher-level” services can reduce your security burden
  • Ideas for baking security into your DevOps pipeline
  • The critical importance of “guardrails” for your team and how to implement them
  • The top AWS security tools all users should leverage

To hear this episode, and many more like it, we would encourage you to subscribe to the Virtual CISO Podcast on our YouTube here.

To Stay up to date with the newest podcast releases, follow us on LinkedIn here.

Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player.

 

See Below for the full transcription of this Episode! 

Intro Speaker (00:05):

Listening to the virtual CISO podcast, providing the best insight on information security and security it advice to business leaders everywhere.

John Verry (00:18):

Uh, hey there, and welcome to yet another episode of the virtual CISO podcast, uh, with you as always your host, John Very. And with me today is Temi Aden, ADA Babo. And I should have practiced that. How did I do?

Temi Adebambo (00:33):

Yeah. Aade Babo. That sounds about right. All

John Verry (00:35):

Right. All right. So I’m off to a good start. Uh, usually I’m not, so this is, this is a positive. Um, I always like to start super simple. Uh, tell us a a little bit about who you are and what is it that you do every day?

Temi Adebambo (00:48):

Uh, Timba, um, basically, uh, cyber risk, uh, uh, leader. I’ve been, uh, doing cyber risk for by the last, uh, almost 20 years now. And I’ve worked with various organizations, uh, in a consulting capacity and more recently, uh, with AWS as the leader for security, uh, solution architecture.

John Verry (01:09):

And if anybody is watching this as opposed to listening to it, Temi must have started when he was about four or five years old, uh, <laugh>. Um, so, uh, cuz you don’t look old enough to have been doing this 20 years Temi. Uh, you, you, it must it must be living good though, right? Right. I mean, what, what, what’s your secret? You know, collagen, I mean, uh, <laugh>. Well,

Temi Adebambo (01:29):

It, it is a combination of, uh, this is a combination of some of the things you said and, uh, and, and, and, and other factors. But, uh, I did graduate high school at 15, so I did start earlier.

John Verry (01:40):

All right. Thank you. I, I, I knew my eyes weren’t deceiving me. All right. So, uh, we always ask, uh, what’s your drink of choice?

Temi Adebambo (01:49):

Uh, lemon drop martini, actually, uh, that’s, uh, that’s my drink of choice, uh, when I’m at a, at a nice place where I could get one.

John Verry (01:58):

And when and when for the lemon drop, what are they throwing? Like a little lemon cello or something into it?

Temi Adebambo (02:03):

Um, it’s, uh, yeah, they, they, they usually, uh, use, well, you start with a very high hand liquor and, uh, a little, uh, lemon cello sometimes, uh, different, depends on where, where, where it’s been made. Um, but yeah, uh, lemon cello works.

John Verry (02:17):

All right. So you’ve inspired me. My, my neck, my next martini is going to be a lemon drop martini. I have, I have not, I have not partaken before. Uh, but I do enjoy a good martini.

Temi Adebambo (02:26):

Um, yeah, you can, you know, got some contra in there with, uh,

John Verry (02:30):

Oh, I love contra

Temi Adebambo (02:31):

Lemon juice. Yeah. Uh, just, I mean, people make it in dif different ways, but the main thing is absolutely lemon juice and, and, and, and some contra and a really good, uh, a really good, uh, vodka.

John Verry (02:43):

All right. I’m, I’m going with Titos, but, but, but, but I do prefer that, uh, that, you know, that’s my go-to from a, from a premium vodka at a very reasonable po uh, price point, in my opinion. Um, I agree. So, so thanks for coming on today. Uh, I, I’m excited. You know, like the world runs on aws, uh, and that’s where we see, you know, so many of the conversations we have with our customers around. So it’s great to talk with somebody from AWS and, and, and get the lowdown on some things. Um, you, I’m sure you’re familiar with, there’s this, uh, uh, I think Kaspersky started it. I’ve seen it on their website, a statistic that says, effectively that 90% of all cloud security breaches are the result of the poor security practices of the people consuming the cloud, not the actual, uh, cloud service provider themselves. So, um, you know, you working at aws, if I ask you, what are the most common things that AWS customers do that can cause them problems of note, including breaches?

Temi Adebambo (03:40):

Yeah. You know, uh, that, that statistic is, is right. I, I would imagine it’s actually greater than 90%. A lot of the gaps that happen is on the, uh, on the customer side, what we call a shared responsibility model. So, uh, about, about, if, if you look at the, the, the, the model for cloud creations, there’s a, there’s a set of responsibilities for security that really falls on the provider. Um, and many times that’s everything you think below of the, below the, below the os. So, uh, a good chunk of the networking, a good chunk of the actual app provisor and, and machines themselves. And then you start to like, look at the responsibility of the customer that is actually configuring, um, their instances in the cloud and their identities and how they’re keeping their data secure. And that’s where things, uh, steadily, uh, start to fall apart.

(04:29):

Um, and because of the ease of spinning up, uh, workloads in the cloud, um, you really, you really have to pay attention to how your configuring things. Uh, otherwise you can be easily accessible, uh, by artists. Uh, some of the biggest falls I would say, is in identity management, um, managing identities, um, not following these privileged principles, um, having long leave credentials. Um, these are, these are probably the, the vast majority of where the challenges come, um, is, is just the way identities are managed in the cloud. People have over overly permissive, uh, identities, and they g they give them long leave, uh, access to accounts. And it’s very common that some of those, when they’re compromised, they can be used to then access order resources that were not intended, uh, because of the over permissive nature of those role of those, uh, goals and permission sets. Um, the other one I might say is, um, just not blocking, uh, uh, public access to resources. Um, we’ve seen some exposures in that, like not making things like extreme buckets, um, uh, started, started locations, uh, uh, private or having instances that are exposed to the internet. Um, so those are obviously, uh, very easy to fix things that you would probably identify quickly as well.

John Verry (05:53):

Yeah. I’m glad you brought up the shared responsibility model. I’m a, a huge fan of referencing that. Um, can you talk a little bit about how the, um, shared reference model shifts shared, excuse me, shared responsibility model. The shared responsibility model shifts depending upon the service, right? So, you know, obviously, you know, software as a service versus platform versus, you know, serverless, right? You’re gonna have a little bit different set of responsibilities that live on your side. And I guess one of the advantages of that, of course, is that with less mistakes to make, the likelihood of being secure is higher, right?

Temi Adebambo (06:25):

Yeah. Because, um, a as you said, the the levels, the levels vary. Um, so when you thinking about it, just when you think about the cloud and you think about just infrastructure and you thinking about us and le hyper very layer for you, then, um, you would, you would take ownership of the operating system. That means you have to deal with the patch. That means you have to deal with, uh, making sure that the OS is hardened and all of the things that happen at that layer. Um, you have to take care of the endpoint. You have to have XD arrows like, uh, you know, CrowdStrike and the rest of, of, of those solutions as endpoint protections on your endpoints. And then you take it up higher to a different layer where you have, um, some services that, that enable you to run, you know, call it serverless.

(07:10):

And you’re now able to use things like AWS lamb or using, uh, different container services that abstract the operating system away from you. And then you can let the cloud service provider take care of that operation system layer. You can have the cloud provider, uh, take care of all of the patch and all of those things. Uh, you, you mentioned the statistic earlier, but vulnerabilities, uh, in the operating systems is still an unpatched systems is still one of the biggest, uh, areas of risk. So, um, moving up that stack and, and selecting, uh, services at that layer that, that allow us do to manage services below for you is, is, is a lot of, um, it’s a lot of good security that you can benefit from there. And then finally, you have the layer where, uh, you basically just managing your identity and, and, and your data. And it’s almost like the entire, uh, the, the entire, um, uh, cloud is, is managed by, by, by the provider except for the software and application layer, uh, by the, the, the customer.

John Verry (08:15):

Thank you. Um, so when we talk about these issues that cause people problem in, in, in my opinion, that it is in most instances an immature SDLC process, um, where there is insufficient thought process on both establishing, maintaining the security and compliance of the application, right? They, they don’t put enough effort into that. Um, you know, when you see folks migrating applications to the cloud, workloads to the cloud, I think there’s, they tend to focus more on getting the application architected and built, right? More business focused. They’re not gonna say security and compliance focus. Um, what do you think the challenge is?

Temi Adebambo (08:57):

Uh, the challenge in that area is actually multifaceted. I think, uh, the ch the, the one you mentioned, um, is, is the business focus and, and the business moving to the cloud, trying to take advantage of, um, all of the benefits that the cloud can offer. And developing the application with that focus and the security not coming along with it. Um, that, that, that does happen. We see that quite a lot. Where the SDLC process is, is is not really involved in security until the tail hand where they want to get some approval or they want to make sure it hit some IT policies that, that have been set for security. And that’s really not the way to, to, to build applications, whether in the cloud or not. But in the cloud especially, that’s not a good way to build applications. Um, it also leads to, um, challenges in the end because then the business wants to go live and the security seems like a blocker, um, sec.

(09:54):

You wanna bring security a little bit early all the way to when the application is being taught of and designed so that security is by design and, and baked into how we, uh, we test, how we, uh, move from one gate to the other so that when you get to the end, um, we are not in this position where we are choosing between security and the functionality of the app. Cuz what ends up happening nine out of 10 times when it gets to that position is that the security becomes technical debt. And they say, okay, we move forward and we continue to address the security. And what doesn’t happen ever in that position is that the security get taken care of with the same, um, level of, of, of, of uighur that it should be. And as the application continue to, uh, evolve and continue to get updates, if that process is not well built, it would continue to have, uh, issues up to a point where something probably makes it into production that should have been cut early.

(10:53):

So I say, yeah, that is, uh, definitely one big area that, that we have is that security should be brought up earlier, uh, in, in the SDLC process. But the other part is, um, the lack of security resources that are, that are actually dedicated to the project. Um, we have a lot of developers that are on there, and if you have a project, which is a bunch of developers trying to do their best, and they don’t actually have a security stakeholder in there, you don’t have a security champion in there. Everyone’s gonna do their best with best intentions, but no one really, uh, focus on security. It will make it an afterthought. So in that case, it’s not that they don’t plan on having it secure, they just all sign, sign up and say, yeah, I’ll make, I’ll make my code secure and I’ll make my code secure.

(11:41):

But there’s really no one who is really, um, making sure that at the end of the day they’re taking that, uh, security responsibility, um, on the, on themselves to make sure that they’re championing, uh, championing it. True. So I, I like the idea that security is decentralized and everybody should be responsible for security, but if you don’t make it, um, something that at the end of the day you have someone championing through the process and making sure that security is at every gate, um, you are likely to also get there. And that can happen when security resources are either a, not enough or, uh, they’re just not being prioritized on the projects that the business is working on.

John Verry (12:22):

Um, could not agree more. Uh, so, aw, yo, AWS is amazing to me. I I, I don’t spend a lot of time on your tools. I’m, they don’t let me touch stuff anymore. Um, but every time I do,

Temi Adebambo (12:34):

Probably for good reasons.

John Verry (12:35):

Yeah, probably yes, for very good reasons. <laugh>, you know, you know, you know what, what’s the old, you know, those, those who can, uh, you know, do those who don’t teach. Yeah. That’s, that’s why they let me get on the pH. You know, they should, they don’t, don’t, those who don’t sell, cuz that’s what, that’s what they let me do. They let me get on the phone and problem solve with clients. I’m not allowed to touch anything anymore. Um, but occasionally I will sneak in, uh, I still have my login ins. And, uh, to me it’s a remarkably robust platform. Uh, it it crazy the, the number of services and capabilities. I mean, you can, you can do virtually anything with it, which I think is both a strength and to some extent a little bit of a weakness because I think sometimes folks get a little bit lost in there. Right. So let me ask you a question. How would you, for someone who is listening to this, that knows they’ve got workloads, they know they’ve got applications in the cloud, um, is there a fundamental set of recommendations that you would make, right? What are the most important aw AWS tools and capabilities that somebody should leverage right? To, and, and how should they be integrated to, uh, once they’ve got these things deployed in ensuring that they’ve got a cohesive solution to manage security and compliance?

Temi Adebambo (13:47):

Yep. And, uh, let me, I’ll, I’ll take you back to something you said earlier, like, there’s a slew of services mm-hmm. <affirmative>, I think of it as Lego blocks. AWS just gives you all of these Lego blocks and you could be whatever you want with it. Um, and what we’ve learned from our customers is like, while they love that wide ability to be creative and innovate on the platform, um, for security, they, they would like some prescriptive guidance, right? And oftentimes, um, I sent customers to start with our, our security reference architecture. That is a set of prescriptive guidance that we have published out there that kind of gives you like a good starting point. Um, so it’s kind of like your quick, your quick build with a Lego so that you actually know what you’re doing. Um, so that’s a good starting point for anyone who’s new and just like trying to figure out like, how should I build this?

(14:36):

Or are we, are we building this the right way? Or what’s the best practices? The security reference architecture is a good place to start. Um, if you’re talking of the services themselves and you wanna understand, okay, am I using what is at the fundamental security services? I would say the services you want to turn on, the moment you’re running aws, um, is God duty. That’s probably the first thing you want to turn on if you’re talking about security, is that you want to have God duty turned on. Um, God duty is the native AWS tread detection, um, uh, service that basically pulls in some of the key, uh, logs from AWS and actually gets feeds from our threat intel, both internal and external threat intel, and combines that with machine learning, unable to, uh, detect threats on your environment. Um, it would also highlight setting configuration as, uh, uh, are risky when they do occur.

(15:30):

So I would say without a doubt, you wanna, you wanna start off with that. Um, security up is probably what I’ll say our next most, uh, important service that you want to turn on is cuz security ups enable you to pull all of those alerts and findings from guard duty along with all of the other third party providers. You might have a security, so what it’s tenable, uh, or you are using some endpoint protections like CrowdStrike, you’re able to pull all of that information as well as the identity, uh, identity side of the house. So where you, whether you have, you know, no MFA turned on and misconfigurations. Um, we also have a, uh, security benchmarks in, in, in security up. So the, the bench of benchmarks in there if you need to apply to, uh, uh, abide by specific compliance, uh, area. We have some compliance checks there too.

(16:19):

So it’s a very good place to start to understand what is my posture looking like when, when I compare myself to the best practices, where can I make quick, uh, quick queens on this platform, uh, from a security perspective. So I would say those two are, are probably what everyone should turn on if you’re not already using it. Um, for security, those would be the two foundational ones. Everyone at some point has to use iam, so I’m not gonna mention that, but they obviously have to have an identity and you have to manage that well. Um, and then kms, which is our key management system, uh, I strongly recommend, you know, data protection and encryption in the cloud. Um, not that we are gonna look at your data or anything, but, uh, you wanna make sure that your data, when it transits and at rest, uh, you, you, you’re encrypting it and you’re managing permissions to do so. Definitely guard duty and security up. And then after that, you start looking at things like kms.

John Verry (17:14):

Yeah. The, in, I, I know we, uh, are extensively in security hub. And one of the things that I’ll go in occasionally and look at is, you know, we have set, um, some compliance targets, you know, to comply with, you know, pci, I D ss, the CIS security benchmarks, uh, and your aws, um, you have your own, uh, benchmark. I don’t, I forget what it’s called, security fundamentals or something of that nature. Yep. Yeah. And, and our goal is always to have, uh, a, a score of a hundred across all three of those, which is not an easy feat, uh, especially because, you know, you guys are, and, and it’s great. And, and you talked about the importance of identity. Like, uh, I did go in in recently and I was surprised we were at like 98 and I was like, what the heck went wrong?

(17:53):

And it was that we had an account that someone hadn’t logged into for 90 days, and your recommendation of best practice was if an account is, is not used for 90 days, it’s probably an account that should be deactivated. It shouldn’t be an act. Yeah. So, so it was interesting that our score went down by virtue of the fact no one logged in, <laugh>, no one had logged in, but it was still good guidance. Right. Um, so yeah, I listen, I, I, I think what you guys are doing there is, uh, is fantastic in terms of how do, um, like, you know, there are, I mean, the number of things you have with Cloud trail and CloudWatch and API gateways and things of that nature, um, does, does that all, and I’m not, I haven’t used those personally. Do they all filter in through that, in through guard duty and into that security hub? Or, you know, do you have, do you end up having to have multiple, uh, uh, hubs, if you will, or multiple dashboards that you need to go to, to see all of this data?

Temi Adebambo (18:54):

Yeah, good question. And in the past, it’s probably has been a little harder than it is now. Um, right now you can use security op to actually view, um, the incidents and alerts across, um, your AWS environment. You can do it not just for an account, but you can actually do it across all of your organizations. So you could have hundreds of accounts across the globe. Um, and you can actually centralize all of that into one, one designated accounts security op. So you actually can have one screen to manage all of the incidents and alerts across your AW s environment. A lot of the logs you talk about, um, like cloud trail logs, those, those will, those will be used by guard duty in analyzing your tr your threats to the environment. Um, BPC flow logs the same thing, looking at the network traffic in and out.

(19:43):

So all of those, uh, logs are there and you can ingest them directly into other systems as well. And we provide the ability to do that. So if you want to use a Splunk or you want to use some ex uh, some ex uh, some other systems to, to, uh, like a SOAR system to respond, uh, to things that are coming out of aws, we allow you to do that. But within AW s itself, um, you can turn on guard duty, you can ingest all of the important logs, um, all of the other, uh, things we have set up like CloudWatch alarms and, and things that you might want to customize yourself and say, I want this particular parameter to be set up. You can do those. And they will feed into security up. So with design, security up to be that one center place where you can get feeds from things that you customize yourself from, config and event bridge and, and, and cloud and cloud, uh, cloud watch alarms, you feed all of that in as well as things that are automatically analyzed using the machine learning within, um, within our services like Macy, uh, for detecting, you know, when objects are, for example, uh, PI objects are placed into buckets that are not designated for pi, those alerts will fit into security up just the same way guard duty alerts will fit into security up.

(20:58):

So really design security up to be the one place you can go and really aggregate, not just from one account, but from all of your organization. You can aggregate it into one security or, and manage it directly from there. So to that degree, we’ve, we’ve helped simplify how you can, uh, manage, uh, your, your, your threat, uh, and respond to them.

John Verry (21:18):

Yeah. Sim simple is better when it comes to security. Um, are there design choices that somebody could make during the initial process that would reduce the security and compliance burden, you know, on the backside, right? So for example, we talked a little bit about this, you know, if I, if I, if I went serverless right, uh, you know, I went Lambda as opposed to EC two, certainly it’s going to, I’m gonna reduce some of that burden. Uh, any other recommendations you typically make to people great services that AWS has that will help to reduce that ongoing burden of managing the security and compliance of an application?

Temi Adebambo (21:55):

Yeah, you’re thinking about it from an application perspective and you want to simplify it, you, you absolutely point on, right? Come off the stack and actually, um, use the, the platform like services that you mentioned, whether it’s lamber, um, or, or the solutions that we have there. Um, same with the databases, right? So we have managed databases so that you don’t wanna spin up your own e C two and then install, you know, yours, SQL server on that, and then start patching and updating the s SQL server and patching and updating the E C two two, uh, machine itself for the OS that’s on there. And, and deal with all of that. You can just directly use, uh, managed, uh, database services. So when you’re thinking about application development using managed services like, like the managed, um, uh, database service along with lamber and or container services as well, you can use containers, uh, and those abstract from the operating system.

(22:52):

And when you, when you are working in containers and you’re working in Lambda and you’re working with managed services, then a lot of your effort can be focused specifically on your application security, uh, the security of your data of course, and encryption and, and, and key exchange, as well as the permissions and identities that you allow access to it. Um, the only part of the, that you have to deal with on the cloud side would then be the configuration of those services. You would abstract yourself, uh, away from dealing with the, um, middle middleware layer, whether it’s updating the Java or engine or, uh, or or handling all of the other, uh, elements that are gonna be at the operating system layer once you move to, uh, a containerized environment and, and a manage database. Uh, so I would encourage people I to take advantage of the managed databases, manage services that we do provide and, and try to come up the layer if they can from the, uh, from the application side.

(23:52):

So we have a bunch, we have, you know, build bin stock, um, Lambda, we have a bunch of services in that area that can help you move up and, and not have to manage the mundane task of, of managing the os, keeping the endpoint protected, putting all the EDR and, and all that services on that. So I, I would encourage people to, to rethink the application where possible and see if they can move it up the stack and make it more modernized. And, and, and, you know, of course build everything with infrastructure as code and, and, and, and leverage, uh, the, the, the more advanced services that we offer.

John Verry (24:27):

Yeah. And then, uh, I, I guess another way that you could reduce kind of the ongoing burden, um, especially any burden associated with, uh, investigating or responding to events would be to take advantage of some of your more protective services, right? Um, correct. So, so something like a WAF or something like a web application firewall or something like, uh, your API gateway. I recently, uh, was chatting with a client and, and they expressed some confusion over, you know, what, what’s the difference between AWS’s WAF service versus their API gateway? Don’t both of them do a lot of the same thing? So, uh, that would be a question I have for you is how would you differentiate to that client the difference between your WAF and API gateway?

Temi Adebambo (25:08):

Well, the, the, the WAF does actually <laugh> help with a, with, with a, with a very different problem, right? So when you, when you think of the waf, think about the ability to actually restrict network traffic, um, to be environment that protect and serve you host in a web server or, or something like that. You would, you, in, in waf you would be able to subscribe to actually not just our rules, but also like rules from people like F five, um, that actually would pre protect the environment because they, they will be able to update, um, based on, um, on, um, signatures, uh, that they have from other, uh, environments that F five and AWS obviously sees. So if we have malicious IP databases, we can obviously use that to protect, uh, the, the, the, the, the, the environment using the waf. Uh, other things you could, you could do with the WAF is also you can very, very, very, um, uh, what, what’s the word I’m looking for here?

(26:13):

But from a networking perspective, you can be very specific with how you want to block or tackle things. So I, I remember the, uh, there was an environment I was building a while back where, uh, we decided to integrate some lambda with the waft where we said, uh, we wanted to try to address some, some of the DDoS potential, uh, that could occur in the environment by, by doing some form of rate limiting. So once the, once, once we get a certain number of pings from a, from, from an, from an, from, from the environment, uh, from a specific ip, uh, maybe it’s like 50 in a, in 10 seconds or whatever, we quickly identify that we run a lambda and that lambda injects a rule directly into the waft and adds a line to, to prevent that IP from, from getting in, uh, or block it for a certain number of time. So you have a, a lot of actual access firewall type things that you get to do, um, you get to do within the WAF from a security perspective, um, that, you know, the API gateway doesn’t necessarily provide that level of security. It doesn’t integrate with manage rules and, and b and bad malaysia’s IP databases doesn’t allow you to, uh, to add that level of rigor from security perspective. So that’s, uh, that’s, that’s the advantage of it. Yeah.

John Verry (27:32):

Cool. Um, so question for you. Do you think that, um, that dev teams and, and your clients are focused enough on the security of the AWS management plane itself? Um, you know, cuz that’s certainly a risk that I don’t think most people you like when you think about the risk to an application, you don’t think about the risk to the management plane, which grants access to the application and all the resources, you know, they’re within. Um, so, so what recommendations do you have for clients about ensuring that they’re doing an adequate job of protecting the management plane?

Temi Adebambo (28:04):

Yeah, the, I would say the management plane, a lot of times the devs, um, the devs do, do not, um, have a lot of focus on the AW s management plane. Uh, that that will be, that will be accurate. Um, but again, it all depends on what level they are operating at. If, if they’re operating only at the application layer and they are not really, um, connected to the AWS platform and that’s provided for them a lot of what they need to do, I would encourage security teams to build guard rails. Um, not expect the developers to be in tune with all of the, all of the security that is necessary at the AWS layer beta build god drills for them so that they are able to operate and build things without going outside of those boundaries. So, um, and, and what, what I mean is, uh, for example, um, in, in an environment where we, we know what services we’re gonna use, we could use something like, uh, a scp.

(29:10):

So that’s, um, that’s, that’s the, the term we, we, we have for actually limiting the amount of services or what a service can do within an environment. So you could set an s p that says that we cannot have an S3 bucket, uh, there S3 bucket had been public, um, is something that can change within that environment. So you then allow the developers the ability to create S3 buckets. They will still be able to create the S3 buckets they want. They’ll be able to have permissions, but they don’t have the ability to change whether it’s public or not, because that’s something that as a security team, you already defined as a guard drill to keep the developers able to do what they want without having to, you know, expose the organization to additional risks. So the way I think about, um, how the dev teams should work really is that, um, they should be aware of the data that they’re putting in a w s and, and the permissions that, that, that is needed to manage the, the workload and focus on, on, on building in a secure manner and, and do all the rigoring checks.

(30:15):

I don’t really expect them to be in tune with all of the management, uh, AWS management layer security. Uh, I expect that we will building guard rails to define those so that it’s commonality across the platform and the developers when they bump against the guard rail and they, they they need to do something special, um, we walk together as a security, uh, as a security, uh, team with, with, with, with, with the developers to understand why and, and create, you know, paths to make it happen. So it’s more of a, of a yes, but ow rather than a no or a you should know everything on security as well. Um, type of environment that I usually prescribe to my customers, I tell them, you know, let’s build really good guard rails. Let the devs fly, let them build however they need to do, find those that bump against the guard rails. When they do that, let’s figure out and understand how to expand or, or create a, a, a path specifically for them. And, and let’s, let’s move forward. Cuz one thing you don’t want to do, you don’t want to slow down the pace of innovation in the cloud because you keep putting security as a, as a barrier. You want, you want to enable them move forward,

John Verry (31:31):

Um, from your lips to God’s ears, uh, because, uh, you know, too infrequently do we see those types of guardrails in place. And you know, it’s a, it’s amazing how often we hear stories of exactly that, you know, that a dev you know, spun up another instance. And literally we had a client recently that, you know, someone spun up another instance and they didn’t have those types of controls and an S3 bucket was left open, which seems to be, uh, you know, somehow an easy problem to have and, uh, it caused some impact. So, uh, couldn’t agree with you more.

Temi Adebambo (32:00):

Yeah. So God drills, uh, really, uh, the way to, to really make this easier cuz we want it to be easier for the developers. We don’t want the developers to have to understand how to manage all of the services and all of the security, uh, for the services. So we want to make sure that we are, we are opening things up for them to operate, but setting security parameters that we make sure that they don’t expose the organization to more risks than we, than we want. And we can do this in, in stages, right? Um, I’ve had developers, um, that have come to me when I, when I used to run a, a platform and say, I don’t know what permissions this needs. I need you to give me all the permissions because I’m building this app and you know, the environment you’re giving me to work with is limiting me.

(32:45):

And I don’t know which one of these permissions I need. I don’t want to bump against each one. Open a ticket every time. Wait for your engine security engineer to make the change because you’re slowing it down. And, and, and that happens, that literally happens in organizations today. Security tries to, to limit it. And what we ended up doing was creating an even lower environment, basically a sandbox environment where this developer can go ahead and just develop whatever he wants. For the most part, it’s not exposed to the internet. That was the only, the, the main gradual for that environment. But everything else you could do could make himself an admin and he could give any permissions. And what ended up happening was before he could now move to what we, what we knew as dev from this sandbox environment, he needed to now tell us the permissions.

(33:29):

But we are able to do that now because we have access analyzer that can analyze what access and what permissions were used in sandbox and we can now move into a dev environment where we have things controlled. Right? So that was some of the things that, you know, we had to do because we didn’t want security to slow things down. But we also wanted to have a least privileged rule for making sure anything you are working on in dev, you having permissions to do that. And the applications we are documenting what permissions they had, but he as a developer that, you know, those guard drills didn’t work for him in depth. So we had to go create a sandbox for him where we could actually get this data. And at the end of the day, it was a win-win because now, you know, we, we kept our side and then he was able to move fa forward faster. So guard drills are important and I don’t want to set set them in a way where everyone thinks of just one set of guard drills. Cause we have some for prd, we had some for Dev, and now we had some for Sandbox, which was basically bare minimum, like just don’t connect it to the internet, but you could be the admin on all of it, right? So it’s important to think about the layers of gradual drills as well.

John Verry (34:33):

Yeah. So, so you gave them the, the ability to go fast and they didn’t have to consistently hit speed bumps. You, you just had a speed bump at the end, which was to make sure that as we did migrate this into a, a higher level environment that we did so in a way that was not going to, you know, cause us a, a grievous problem.

Temi Adebambo (34:49):

Correct. Because we have the tools to analyze,

John Verry (34:51):

That’s called Access Analyzer, the tool that you used to do that. That’s cool.

Temi Adebambo (34:54):

Could you use Access Analyzer to determine for any user, what permissions have they used in the past? Mm-hmm. <affirmative>. So you could say from like last, you know, 90 days what permissions as this role used and AWS can actually propose, uh, the permissions that that should go with the, with the role and, and shrink it to what was used only so that all of the extra permissions are are abandoned. So we have the ability to do that. So it’s a combination of understanding what tools you have and what God drills you can put to really help the, to move things faster.

John Verry (35:25):

So after you use Access Analyzer and you, let’s say you reduce that permission set, what do you then have to validate that the everything still operates as intended? Bef Okay.

Temi Adebambo (35:34):

Correct. All right. So then you make sure, so you, you use externalize that we got, we gather what access permissions are necessary, that we assign those to the, we, we, we shrink it back, we create a new, a new role. We, we assigned our goal only those permissions we run the application. If it runs well, perfect, now we know that’s exactly what we need to move it into, into the dev stage and then it can continue to do his work. Awesome.

John Verry (35:56):

Um, we covered a lot of ground. Uh, is there two, two questions for you. What, anything we missed and that you’d like to point out? Or B, knowing your role and knowing how, uh, high energy you are with regards to the awesome stuff going on at aws, anything else you want to talk about that’s new and exciting that you think is worth highlighting,

Temi Adebambo (36:16):

Uh, new and exciting, um, in aw s <laugh>, I would say we, we constantly live in the future, so the things that are new and exciting to me, you would’ve to attend AWS reinvent to find out in the next couple of months <laugh>. But yes, there are new and exciting things that are coming up. All of them do make security a lot easier for our customers. Um, but, you know, some of the newer things that have come up, uh, that that is really cool is, uh, the way we, we, we are able to, um, do more for containers now. So we have a lot of guard duty for containers, a lot of support for our cont for people operating in containers. So I would definitely, uh, ask anyone to that hasn’t looked at that to take a, take a quick look. Um, we, we, we, we now able to also, um, we’re able to support a, a number of, a number of, uh, data privacy things that were a little challenging before with the whole Macy, the new Macy’s really able to do a lot of analysis.

(37:15):

So if you’ve not looked at Macy in a long time, you can dick a look at that. Uh, inspector, which is one of our other services that does, um, that that does, um, vulnerability, uh, identification and management was also refreshed this year. So another cool and exciting, uh, product that you should check out, but there’s, there’s just a lot going on. There’s a lot more in the future as well. Um, I think, uh, very recently at Reinforced we announced that, uh, the ability for, for you to actually, uh, do uh, malware detection using guard duty. Uh, so we built that in there and you’re able to do that without, um, actually an agent because a lot of complaints we had was agents on machines always slow them down so you’re not able to do malware, the detection cuz we don’t work on the agent. We take a snapshot of the EC two and we actually analyze that.

(38:07):

So you don’t need to have an agent to actually scan, uh, the environment. You can scan it based on the snapshot and we can a analyze that. So those are some really cool things that it of us has added this year that I think are just exciting. You know, the ability to just not even worry about what an agent to do to the machine or how he slows the machine down. Just take a snapshot, analyze that, send feedback back into guard duty, forward that into security app and then, you know, got the results right there. So lots of cool things like that. And there’s, there’s gonna always be more, we always thinking about new ideas.

John Verry (38:38):

Well the one thing that you guys never want for is change. Cuz every time I go in, there’s three or every time I’m on a phone with a client, there’s a new service that someone talks about that I gotta, I gotta jump the AWS products page so I can play catch up to the conversation. One question for you on that Macy product, that’s one I’ve never heard of. Um, does that, is that anything to do with, cause one of the challenges we’re seeing a lot for folks right now is, um, automated data discovery and classification and it sounded like that Macy might be in that realm. Yes,

Temi Adebambo (39:05):

Correct. Uh, Macy is exactly in the realm. Uh, you can, you can give it tags and it can go in and scan your, your s uh, your S3 buckets and you know it, that’s some automatically of course like credit cards, social security numbers, some of those basic things mm-hmm. <affirmative>, you can scan a, a, a, a S3 and tell you whether those those have, you can have it turned on so that only set specific S3 s have set in tag can all those kinds of information. And if it finds it in any other ones, it can automatically alert you. There’s a lot of capabilities with, you know, just classifying, tagging, identifying data, uh, that you can use may Macy to help you

John Verry (39:40):

With. Gotcha. And is that restricted to just S3 or would I be able to run it against structured data sources like RDS and things of that nature as

Temi Adebambo (39:46):

Well? So we’re working, we’re working on extending that to databases for now it is, it is for s3 but working to make data, uh, s uh, Macy worked for databases as well. Yeah. Is something that, uh, is in a is in a works.

John Verry (39:59):

Yeah. Cuz with, you know, cuz I mean, you know, the next, you know, frontier of pain for a lot of people is, you know, the GDPR cpa, APAC V D P world, uh, and uh, you know, and, and the problem is with, you know, any of the non-automated ways are, are painful, right. You know, manual data mapping, you know, and maybe you arrive at a reasonable data map on day one, but how do you maintain that data map as things change, right? As your environment changes, as your applications change, it’s not easy.

Temi Adebambo (40:28):

It, it automates it. So it basically enables you to discover and protect the, the, the sensitive data at scale. So you automate the discovery, you gain visibility to, you know, what kind of, what kind of, uh, things are stored and you

John Verry (40:41):

Know. Right. And of course the other advantage if you can do data classification is that, you know, beyond privacy, right? There’s lots of other forms of data that would be, you know, nice to know where they are, nice to know how to, you know, nice to know they’re being adequately protected. Nice to know they’re in, like you said, we have the right guardrails, they’re in the right places and on the wrong places and be able to manage that automatically is pretty damn nice. Yeah.

Temi Adebambo (41:01):

It, it can also take action, which is, I mean, you can take action, you

John Verry (41:04):

Can decide that work through Macy Oh that’s cool as hell.

Temi Adebambo (41:06):

Yeah. Yeah. So you can kick off workflows, you know, you can remediate, you can say, Hey John,

John Verry (41:12):

Just put out this isn’t, this isn’t, this isn’t allowed here. Bang. Right. Or even have nothing else if you can just automate the response. Right. I mean, if we can open up a ticket somewhere so somebody knows, hey, this, this stuff’s here. You know, cuz I mean, you know, what you do find is a lot of people are hesitant to automate too many things. They worry about breaking stuff. Um, so, you know, the idea of the idea of just even automating the, the response and ensuring that it occurs is just massively valuable. I think.

Temi Adebambo (41:37):

Yeah. You might just notify the owner and say, Hey, did you know that this is what you just did? And, and get them to validate you could, you could do something more, uh, more forceful like quarantine it and don’t, don’t put it in that public box yet because it has some information that we don’t want ever in public. All depends on of course what, what the situation is. But you know, there’s certain situations where you might wanna, you might wanna take action immediately.

John Verry (42:01):

Awesome, man. Well listen, this has been fun. I I will ask you the question and then you have the right to turn me down cuz I did a crappy job and didn’t get your, our discussion notes beforehand too much. Um, so give me a fictional character, a real world person you think would make an awesome or terrible CISO and why.

Temi Adebambo (42:20):

All right, I will go with, uh, Eli, uh, Peyton man. <laugh>, Peyton man would be a, probably a, a decent CISO in terms of risk management. Uh, you know, it stays in a pocket. So he is got the poise, it can handle the heat and uh, he knows he doesn’t run around. So when the heats getting too close, he knows when to throw the ball away and do risk management, you know, limit those hits and uh, you know, still get, still get the job done at the end of the day, match ’em down the field, um, re plays, you know, read the defenses with the offense. And, and then, so I think Eli, Eli, if he apply himself, you know, beyond the nationwide commercials and N NFL <laugh> may have a third career in,

John Verry (43:04):

Well, you know, at, at all. So I’m a Peyton Manning fan and anyone that can win a Super Bowl, right. I, I can’t, I, you know, the only thing is that I have, I have this, as soon as you did that, you might have seen this smile on my face cuz I had this image of him sitting in a conference room, like in a CISO setting going Omaha, <laugh> <laugh>, right. Cause that was his, that was always what he used to. Hot Hu Omaha. Omaha <laugh>. So that’s definitely, no, it’s okay. And, and listen, you know, the other thing which, you know, Eli won a damn Super Bowl as well. I mean, so it’s, it’s kind of hard not to think he would be a good CISO as well. I mean, of course he needs a David Tyree working on his team to make an amazing whatever the equivalent of a helmet catch is in in Yeah. Whatever the equivalent of that is in, uh, in information security, right? <laugh>.

Temi Adebambo (43:50):

Yeah. Yeah. They’re also always the lowest seats. So I don’t know. I think, uh, I think Eli, Eli Eli is more of a re sticker. I see, I see, I see. Uh, Peyton is a lot more calculated, a lot more reading the reading, reading what’s coming to him, changing the plays to make sure that Yep. You know, every, you know, you might, you might call it play and you might move, move, move blockers around to make sure that he has a time to manage the risk and he chose the ball out. You know, as I said, when he needs to, he doesn’t, doesn’t get slammed too much. You see a lot of young quarterbacks today thinking they can outrun the, the defense and then end up with concussions and stuff. He doesn’t take those risks often. So I think that would be a good

John Verry (44:31):

Season. Yeah. And if you look at e Eli especially, right? Like E Eli, what, what did he start? 200 straight games or something crazy like that. I mean he and he only, he only, he he broke the string because they just started another guy over him and then went back to him the next, the next time. I mean, what do they say the, the greatest uh, ability, uh, of, of a NFL quarterback is, is availability <laugh>. Exactly, exactly.

Temi Adebambo (44:55):

Your, your greatest ability is availability. <laugh>, if you’re available. It doesn’t matter how your home strength is, you might be able to trade a

John Verry (45:03):

Hundred, you know, you know what that applies to. Aw, that applies to an AWS deployed application as well, right? Yeah. Availity,

Temi Adebambo (45:12):

If you down, cause you have a dirty issue, you down cause you haven’t suffering at <inaudible>, we can’t get to you then the application is no good. You gotta be

John Verry (45:22):

Available. So, so now we’re gonna refer to this Lambda as the Eli Manning of serverless computing. There you go. The, you you’re welcome to use that in all of your marketing. You’ll have to check with Eli, but I’m not gonna charge you anything for it. <laugh>. Yeah. Timmy, man, this has, this has been fun. Uh, i, I really appreciate you taking the time. If, uh, if somebody wanted to find out about all this new and exciting fun stuff there at Amazon, what’s the best way to do that?

Temi Adebambo (45:49):

Um, obviously you can create an, create an account if you wanna play around in it, it’s gonna be free for a while. I think you have a, a free, a free, um, account that you could create on Amazon with a lot of services or of course there’s a lot of documentation we pride ourselves in documenting a lot of stuff. And so a lot of getting, getting started, uh, kit out there if you actually wanna get hands on, uh, with, with the service. Um, lots of, uh, case studies out there for, for business leaders as well. If you just wanna understand, you know, how, what, what types of problems, uh, can use, use the so cloud to solve natively that maybe, you know, your current on-premise does not allow you to, or that you can actually spin up faster. So with case studies, understand how businesses are using it of us, uh, to actually solve their problems. Uh, I would say, you know, that’s, that’s, you know, what you should do. And if you are a security person that really, you know, want to understand some of the best architecture guidance that we have, um, you know, start with the security reference architecture. Um, we have a lot of best practices, uh, security best practices page, uh, that you could search for and uh, follow the AWS security blog.

John Verry (46:54):

Yep. And one other thing too, I would just point out, if you are looking to move stuff in into aws, your partner network is quite good. I mean there are a lot of really talented people that, that, uh, are available out there if somebody wants to leverage AWS infrastructure.

Temi Adebambo (47:08):

Yeah, absolutely. So lots of, lots of partners with lots of software vendors as well as GSI that are system integrators. Uh, and they all specialize in, you know, from enterprises to small businesses. Um, the whole gamut. We have customers that, you know, build only a few hundreds customers that build millions on aws, all work with different partners. So partner ecosystem is one of our biggest advantages cuz we have a ton of partners that we work with and they understand how to make, make the best out of AWS and, and, and, and help businesses achieve their, uh, objectives. So absolutely take advantage of, of, of, of, of the partner network.

John Verry (47:43):

All right, sir, this has been awesome. Thank you.

Temi Adebambo (47:47):

Yep. And if anyone wants to, uh, reach out to me, they can, uh, they can find me on LinkedIn. Uh, just search for my name to me, Baba and uh, uh, happy to connect.

John Verry (47:56):

Sounds good, man. Thank you. Have a great weekend. All right.

Temi Adebambo (47:58):

Take care. Bye bye.