Shipping securely: How strong security can be your strategic advantage

Good afternoon, everyone. My name is Clark Rogers. Thank you for joining my session here today, CG 203. Um I am a Director of Enterprise Strategy at AWS, focusing on security risk, compliance and privacy. Enterprise Strategists are former AWS customers, former customer executives who led a digital transformation and/or cloud migration at their previous companies prior to coming to AWS. And our role is really to speak with executive customers and sort of help them on their journey no matter where they are in the stages of cloud adoption.

These lights are very bright so I can't see you. So please keep your gestures towards me polite. Uh a as we move throughout the session today and this will be the one time I sort of look out into you and sort of ask a couple of questions can just by show of hands as far as your role in the in your organization. Uh if you are a developer or product manager type couple. Ok. Thank you. Uh infrastructure and operations. I'm seeing some of the same hands that's not good. Uh se security risk compliance, privacy folks. Ok. And then just sort of business leaders or other. I see a couple. Fantastic.

So the majority of the time I spend with customers is meeting with these disparate groups at a customer company and help them not hate each other. Right? And help them be more successful as they drive their business forward. Um I'm hoping at the end of this talk, uh, those of you who are from different factions will meet up, give each other a hug, maybe go have a drink, do something like that.

So why does it matter? Right. When we're thinking about security in the enterprise, why does it matter? Well, we're there for one thing and that's to make sure that the business is successful. Um not always is the business the most secure, but it's successful because security, um, security investments, compliance, investments, etcetera are risk decisions, right? And we have to make appropriate risk decisions as we move forward. At the end of the day, your customers are probably not that impressed how many firewalls you use or what uh java library you're using or what's your c i cd pipeline is like they want to find the blue t shirt that they've been looking for and have it delivered to their house. It's very transactional and if you can't provide that to them, they'll look somewhere else.

So I have some customer examples here. We'll start off with Nasdaq. Uh Nasdaq as you all know is, you know, a global financial data exchange and they developed the Nasdaq uh cloud data engine in order to allow them to develop software faster and release it faster as they're delivering their insights across, you know, their financial data streams around the globe. Neiman Marcus, the high end retailer. When Covid-19 hit, they were prime, not predominantly a brick and mortar shop, they had to pivot very quickly to an almost online presence but still give that high personalized quality and experience to their customers who expect it AWS you're here. You know, especially if you attended Adams session this morning, we release thousands of services and new features every year. We are driven by innovation because you our customers ask for it. Phillips Healthcare developed the Health Suite which allows them to ingest store and analyze data from all of their connected health devices from around the world and maintain regulatory compliance. And then lastly Experience who is a credit broker here in the United States for both consumers and businesses, they standardized a lot of their platforms so they could detect anomalies very, very quickly and then react to them because they own the customer trust business. If you need to have your credit checked, you want to make sure that that happens quickly and efficiently every time and that your data is protected

While there are security elements to all of these examples. These are business examples first and part of my job is to make sure that business leaders understand that the value of security brings to their business and it's not just a quote unquote security or it thing.

So a little history about how we got here from a security perspective in the enterprise as far as, you know, uh risk bad actors, et cetera that are out there. Humans, right? Code, humans make mistakes. All codes have vulnerabilities. It's just whether have they been exploited or found or not. And there are several different motivations for attackers to attack your systems and websites, etc, it could be financial. So just the standard criminal folks, political spies, ideological. And then there's people who are just curious. A lot of you are probably curious but you don't break the law. How can I break things? How do I think about things differently?

And if we look at the scale and sophistication of events over time, it used to take a lot of skill and a lot of resources to pull off some of these attacks. But thanks to things like the theft of NSA's cyber weapons a couple of years ago, fantastic customer service in the dark web. If you want to subscribe to a ransomware service and do it for yourself with your stolen credit cards. Of course, it makes it very easy for non technical bad actors to attack you and they can do it at scale

For those of you who attended our AWS Reinforce conference last year are then co CJ Moses put it quite succinctly. And this brings me up to another topic which I didn't cover at the beginning. There's a lot of material in this presentation today and there's a lot more material available to you on aws.com and youtube, etcetera. So I've included QR codes throughout the deck, video, interviews, white papers, etcetera that you can follow up and get more information on this.

The tools of the trade of hackers are no longer a secret sauce. They are available. They are everywhere and it's up to you. The enterprise, the SMB whatever type of business you are is to not only realize that they're out there but to build in your defenses to combat them. And the defenses are not always just security tooling. It's thinking about resilience your backup plans, etc

If you've not read this book by Nicole Perl Roth, I really suggest that you do. This is great for every job family that i asked about in this room earlier. It talks about how we got here and how that quite frankly the intelligence agencies at various governments have really propped up the industry for vulnerabilities and making sure that they cost as much as they do. But it's basically created the market for people to find the exploits that they use against you in a day to day manner. And ultimately crime pays and things get messy.

And for those of you who are security professionals, you can probably relate to Chad Wolf here. Who's the VP of Security Assurance at AWS. Security if you're doing your job. Well, no one notices. It's only when something bad happens that security might get the attention that they're looking for or that they need.

So, what does shipping securely look like? During my time at AWS, I've met with over 800 customers and I've compiled what I believe to be the sort of three pillars of progression as an organization to progress from sort of a yes, security is important to security as an enabler from my business perspective. So those three pillars and this is from the organization perspective, I'll be talking about a security teams in a minute.

From an organization perspective, we start off as we're aware of security, right? So these are standard network based controls. Humans typically have direct access to data. Excuse me, I've been breathing a lot of that fresh casino air. There's really no security culture with, with, with the exception of the security team, right? Because they realize what they're there to do and a lot of security and infrastructure activity is done sort of from a point and click perspective

As organizations progress. And this is typically when they also happen to be looking more into the cloud and taking advantage of what's available to you, they really start focusing on identity because they realize in the cloud you have to start with identity before you do anything else. There's a mix of system and human data access when things go bad, they start asking things like, well, why did this happen? So let's start investigating a little bit deeper into our processes, our mechanisms etc to see what did we fail to do that caused this bad action.

And lastly embedded, this is when organizations are thinking security first. Again, from the development perspective, all the way up to release security team integrations, etc. Humans don't have any access to data, right? It all has to go through a service account, for example, uh zero trust architectures are enabled, right? Trust no one and never trust them until they can authenticate appropriately. Security is everyone's job and tooling is becoming more and more automated, right? We realize we can do more with less, we're automating repetitive tasks, etc

We released a white paper on zero trust earlier this year that i encourage you to take a look at. It was in conjunction with the Sands Cloud Security Exchange where the major cloud providers got together and talked about security for a couple of days. It was actually pretty awesome.

So now let's shift gears, excuse me to the security team. So security teams evolve as well. Initially, security teams are reactive, right? So when they're first starting off, they are firefighters looking for smoke, they have some tools, they probably partner with the infrastructure team a little bit, they're probably not close to the development teams very much at all. Other than that they're aware that development teams exist and are pushing software

As they mature, they start to put in those perimeter defenses, they start putting in the detections, they're reacting, they have a SOC, possibly, right? They're investing in those automated tools themselves. They're starting to act more like developers, then they start to differentiate your company. Right? Because we talked about earlier, the customer just wants to buy the blue t shirt in their size. Well, if they know that company A keeps having security incidents and company B is not, and they both sell those blue t shirts. Where are you going to go spend your money? Right.

So you start to differentiate, but it also happens, I'll give you a little bit about my history. I was CSO in the insurance space, we couldn't get certain lines of business unless we had and could prove a very distinct security outcome for our products and services. So we were able to differentiate ourselves between our competitors to our customers.

And lastly, and again, this is the, the nirvana of it all is security is enabling the business. It's, it's that secret weapon that the business has, that they can take more risks, they feel de-risked, right? Because they have the confidence that their systems can be, be, be rebuilt very quickly because resilience is a focus. If something goes bad, there's a detailed incident response plan that's been practiced with both executives and legal and coms and security and infrastructure and developers and that there's a strong security culture where security is important and it is everyone's job, but it's not as easy as just putting a couple of slides together with some cute dogs. This is an evolution. This is not something that happens overnight. And you have to really think about putting security throughout the organization and treating it as a core task for your business.

Often times customer executives think. Well, I'll just get a larger security team that doesn't work. You can't have a large enough security team to do all the security that needs to happen. You have to have it embedded throughout the organization. It has to be socially aware and a deep ingrained part of the culture.

So how do we realize this vision of shipping securely? I hope I hear some laughter here. Some of these ideas are actually legitimate. But the point of this slide is really sort of say, you can say all these things and may even put it on a t shirt and this is done in tongue in cheek. But if you don't actually believe it and enable it and put mechanisms in place for people to take advantage of it, you're never going to realize this vision.

So like many things at Amazon, we have pillars and these four pillars, which we'll dive into a little bit deeper as we go through the talk, sets up that framework for success to actually realize the vision I find i come across organizations where the technology and security and business talent is just off the rails, but their culture is horrible and there's a blame culture, there's a infighting, there's silos, all this kind of thing and it's like you have no idea how much talent you have and if we can get you to work together, watch out. Right.

So we're going to talk about culture, organization, mechanisms and execution, culture. So this is what really differentiates people from being on that beginning journey of the security evolution all the way to the end when they're enabling AWS security. And I'll be using AWS examples throughout here and sort of sprinkling in some customer examples as well.

We understand that this is the way we do it. We're a little bit peculiar, but a lot of our customers have adopted some of these processes, a security. I think this is one of the most important things. We encourage all of our employees very similar, I think to TSA if you see something, say something and we make it very easy for them to do so whether it's through a web portal for ticketing, picking up the phone, whatever we want to hear. If you think something's wrong, if you think you have a security problem, you have a security problem. And regardless of the outcome, whether it's an actual security problem or it was a false alarm, you're praised either way. Thank you for bringing that to our attention, it makes customer employees feel valued and they realize that they're all supporting the overall security mission.

Also, culturally, we hire a little bit different on the security team and actually for service teams as well, we look for people who have that bent of. How do I break things? We talked about that bent earlier and I can get you in trouble if you're breaking the law. But internally in your enterprise in, in your organization, you want people like this, right? How do I break things and make sure that they never break again? It's an awesome trait and influencing people socially, even if they're never touching a keyboard other than in the office suite or something, they're still contributing to your overall security organization.

So engagement we talk about in the past we've kind of talked about, well, we want to get executive sponsorship, whether it's for your cloud migration, digital transformation, maybe some security etc sponsorship is great. Engagement is better if your CEO gets up one time on your three year cloud journey and says, hey, the cloud is important, I'm behind you and you never see him or her again. You know, it's not real. But if that same same CEO in their quarterly meetings kicks off the first of the meeting with, hey, here's our cloud progress or here's our security progress, you know, they're bought in and then when they're bought in, their reports are brought in and their reports are brought in et cetera. So it's a cascading effect.

So the current Amazon CO CJ Moses, um I have an interview with him here. He talks just about that process that if the most senior person, the most senior executive isn't stepping up and making it important, you have the responsibility as, as an executive within your organization to be a leader at Amazon and AWS, we look at everybody as a leader regardless of what level they are and they can step up and do what needs to be done.

Enabling, we've talked about again in the past. Hey, I have all these security tools available to me. Why don't they just use whatever that's out there versus making them easy to use, giving people the golden path to actually get to production faster and more secure. Some examples I see in customer environments, the security team actually takes over the CIC pipeline. They put all the checks in there that need to be there. Now, the development teams don't really have to think about it that much, but you have to do that upfront, work with the development teams. So when they get the findings back, when they're trying to push to test from development, they realize it's not the security team that's out to get me. This is going to make the code better education. Everyone in your organization should have basic security literacy. It needs to be tuned to their job, family and their level of responsibility. So some people are going to get a lot more. Some people will get a little bit less, but it's not just your annual security awareness training. It's making training available to those who want and need it on an easy low friction basis, whether it's internally like on your wiki or third party platform or whatever, my friend, Bill Shin who's in the office of the CO I think, put this quite succinctly that security professionals traditionally have not come up from a development or coding back background. So it's so important these days if you're going to bridge that gap of sort of of language and passion between the development community and the security community. And I'm even going to throw the infrastructure community on here because right now infrastructures code. So guess what? We're sorry, you're a developer now, right? So it's everybody being able to speak that same language.

And then the fourth E is things we want to eliminate, right? It's very easy for someone to say security is not my job. You need to give them a reason to think differently, right? That they are contributing to everything and that security should be a source of enablement and not conflict as an exercise. The next time you're at your organization and you're having that discussion. It's production eve, your product team has been working for months on a particular release and it needs to go live tomorrow. Your security team has found a critical vulnerability that's going to prevent that. If they choose to fix it, who makes the call? What do you do? There's really no right answer. It's a risk decision, but it's how are they working together for that? The most successful companies are the ones who go, we're going to push that production release two weeks and we're going to fix it or the next fix is going to be the security fix. Despite what next feature you would plan to go out there, it really comes down to your culture and what drives your organization, your risk tolerance.

So when we're communicating security to the larger organization, we have to be very clear and crisp with the language that we use at Amazon, we are writing intensive culture that you've probably heard about our six pagers. We typically don't use powerpoints unless it's in an event like this because everybody likes pictures of dogs or I hope you did. Um the written language is very, very important. So you must be very clear and concise with your intentions on how you talk about security and making sure that it is an enabler and you're very prescriptive with your language and that you're not using what we call weasel words, you want to be very effective on how you talk about security problems.

So this is kind of the old way of thinking I will say, right? So we did these certain things from a security perspective, sort of more positive business inclusive language that goes along with this, right, the items on the right are designed as examples to sort of give you that feeling that there's more going on there. We're not just playing whack a mole with security. We're actually looking at security problems, seriously. We're building them into our products and services. So it's not an alarm when things just pop out of nowhere.

Organization. So let's assume everybody is trained and is on board and feels that security is part of their job. How are we going to design the organization for success? Another friend of mine and this guy with a great haircut, Hart Rossman, VP of AWS Global Security Services. You think about the possibilities of what you can do in the cloud. We have customers who tear down their entire environment every night. So every 24 hours, you're basically validating that all your code works and your pipelines work while that's an extreme. And I don't expect anybody to do that day one. It's something to shoot for and it's not just a technology marvel that you, you know that it or security or infrastructure can pat themselves on the back for. That is a business enabler. What happens if you had a ransomware event and you need to recover quickly? Are you running for your playbooks and run books and trying to figure out how to do it or you go? This is just a Tuesday it's no problem. Right. That's a huge business enabler.

So, when we traditionally think about product teams and security teams, there's usually a whole lot of product teams and very few security teams, maybe there's just one security team and when they need to release something and then security has to, has to, uh, get involved. Um, there can be a source of friction because it's many to one and not a lot of eyes on the security team who are maybe juggling some other balls at the time. So if we take all of those product, humans as listed here and in bed, security owners inside of it, that takes a lot of work off of the security team and really starts to push that onus down to the product teams. This is good because who knows the product better than the product teams. No one, if you've got 300 products in your organization and you have a 10 person security team, they're going to be limited on how they can help you. However, if there is a member of each product team that has security as either primary or secondary responsibility with a bat phone back to the security team, that's going to allow you to move a lot more quickly because you're going to understand what security risks are out there. Maybe you've been working with the red teams to figure out what the threat model is for your application and you're going to know some of the core, best practices that you should be doing from a development perspective.

So the security driven organization, um and we do this across all of our service teams. It's, you build it, you run it right. So at AWS, the product owners own the p and l for their particular product, they own the marketing for their particular product. Um and guess what they own the security for their particular product. Um clearly the security team is there to advise best practices and tooling, etc. but at the end of the day, you're concerned with the cash flow of your product as well as the security and the compliance aspects as well.

For those of you who had the pleasure of experiencing log four j a couple of years ago, i'd like to sort of give you a little insight on how it operated at AWS. The alert came out, the vulnerability announcement came out, the product teams went straight into their code. Libraries started looking to see what kind of vulnerabilities they had if they had them because guess what, they know what version of the library they're using, the central security team may not, they were able to dive in triage very quickly, see what systems needed to be patched. See what didn't security team for the most part was an observe and report organization up to management to say product lines a through d are good, e through g are yellow. They're going to get patched and then maybe there's a couple of reds so they co ordinated that. And yes, they were able to deploy a couple tiger teams here and there. But for the most part, the product teams were the ones who ran their patching, they identified if they needed to patch, they patched accordingly and then they gave the thumbs up to the security team to move on and the security team, of course, could run scans as well to make sure that that happened at AWS we have a program called Security Guardians at other companies. I've heard them Ambassadors, Security Cohorts, but the general idea is the same. There is a member of the product team who is responsible for security for that product and he or she is trained by the central security team. They may have interactions weekly monthly. There may be a special website or a hotline or something like that office hours, that type of thing so that every security guardian throughout the company has the same access to security tools and information that they need that aligns with their product development responsibilities.

Here's a sort of larger depiction of that. And the idea is that continual knowledge sharing that goes on as part of the security guardians program that they really do feel as an extension of the larger of the primary security team that's out there.

So let's move on to mechanisms. Every presentation is required to have a picture of Jeff Bezos, that's not true. It just, this one just happens. He's a big fan of mechanisms as a reminder mechanisms. You have an input, you have an output and then you're continuously self inspecting your process to make sure that you're getting the output that's desired.

So we have sort of three high level mechanisms that i'll touch on today that i think are particularly important for this security infrastructure and development integration that we've been talking about. The first one is measurement governance and tooling and we're going to get to measurement. There we go. Um it's very important that you're measuring the right thing and reporting on the right thing and not everything, right? So one of the metrics that the AWS security team has um is how many times did we say? No? That's a pretty, that's a pretty interesting metric when you think about it, right? Since everything comes through the ticketing system, how many times did we say no? And if we said no, what was the reason? And or are we putting something in place that, how fast can we get to saying? Yes, product teams, what is our release velocity and what does our security rework look like on an average release schedule? If we start measuring those types of things as we start implementing these other processes, one number should go up and another number should go down if you're doing it right? Which is pretty awesome.

So you want to watch out. However, for watermelon golds, watermelon, golds are green on the outside. So it says, yup, i think we're on track but red on the inside, they actually take away from what you're trying to do. So an example is retention rate. So you give everyone the goal of, we want to make sure that we're keeping all of our customers as long as we can. So, a brilliant engineer says, you know what, uh i'm going to remove the cancel button from the website so they can't cancel their account and then i'm going to replace it with a phone number that has 7 to 10 trees of hell, that you have to go through to finally get to a customer service person who can help me cancel my account. Now, that's a bit extreme. But what does that do? You kept your retention rate pretty high? But it was a horrible customer experience. So it's very important to think about having a balancing measure to make sure that you're aligned appropriately

So, engagement rate in this case, is the kind of thing that you would want to measure people against, right? So we want to keep our customers engaged, we want to keep them happy. So hopefully that would defer that enterprising product manager from removing the cancel button from the website. You need to think about what you're measuring and how it reflects at your business, but it's those kinds of ideas that will help you be successful in that area from a security measurement.

Excuse me, again, from a security measurement perspective, here's some examples of how things change, right. So we might have been counting the numbers of tickets, but how about the staleness of tickets? How fast are we actually getting to the tickets themselves? Rehydration time versus RT and RP? If you are, if you have everything in code in your infrastructure and applications and you can rebuild your environment in 24 hours or even a week, right? That's not only impressive, but then that also sets you up for being able to do things that you may not have been able to do before maybe entering new markets or releasing products that you didn't think that you could do.

Governance. Governance used to be a four letter word and in many of your organizations, it may still be a four letter word. Um when we think about governance, we really want to think about enabling people to move faster. So building those guardrails either from a technical perspective or a procedural perspective. So people can move faster at Amazon. We are very bullish on establishing tenants before policies and procedures. Now, for anybody who's in a regulated industry or has, you know, some sort of third party security certification, you have to have your policies and procedures eventually. I'm not telling you not to not to have them, but tenants help people act without the policies and procedures. So we want to think that we're directionally correct, allows people to make decisions quickly. You have to write these tenants in such a way. And I encourage that a team write their own tenants on how they operate, what customers they serve, etc so in the absence of clear direction, they can still make good decisions and move quickly.

Some example, tenants as we have here. Um I think my favorite one is in the middle. Mistakes will happen. Don't let the same mistake happen twice. I believe this back in 2017, um us east, an engineer was typing in a command to it was either to update or put in a new feature s3 that engineer mistyped the command, the system accepted the command. And unfortunately, for several hours, people were without s3 on the east coast. If you were affected by that, I'm sorry, many people say, well, that guy got that guy or gal got fired, didn't they? No, that person was thanked, that person was thanked because they realized this process is something that should be automated. We should never have to have to put this person in that position where they could mistype something like that. I don't know if that person is still with us, but they weren't let go for that, right? Um but that's an example of it's ok to make a mistake as long as we learn from it and then we build the capability so that same mistake doesn't happen again.

Centralizing objectives. So when we think about um security governance and auditing objectives, we want to be very clear about what we're trying to achieve as an organization. But then just like with the security, pushing the security ownership down to the product teams, you want to push this responsibility down to them as well, you may build a system that they can use to achieve some of these goals or you may leave it to them and say, i don't care how you do it just for every release, i need these 10 things and then the evidence needs to be put here. So some product teams may take automation to the extreme. And as you're developing artifacts, it goes into a repository automatically. So then auditors can take a look at it and then others may be doing it more manually. But at the end of the day, the same result is there eventually as you develop best practices throughout the organization, that's where your security guardians network can kind of come in and they see product owner z figured out this great way to automate evidence. Let me make sure product owner a knows about that and they can adopt that same code. So then eventually all boats rise.

Since we're on the topic of security governance and audit and compliance. We have a deep interview here with Jesse Skibby who runs our security advisory assurance team that helps customers learn about auditing in the cloud. What evidence looks like both whether they're external auditors from the big four or something like that or your internal auditing teams as well.

Operating with transparency is key. There shouldn't be any hoarding of secret sauce or secret materials when it comes to making things more secure. You also want to be very transparent with the rest of the organization. Regular security business reviews happen at AWS and these metrics and reporting are, are public in the sense that they're on our internal wiki so anybody at AWS can get them. But then it's very clear how is product a doing and how is product b doing and then all the way down the line, you know how many services we have, but it gives up to date dashboards on not only performance metrics from a compute network etc basis, but also how are they doing on their patching? Are they red, yellow, green, how are they doing with their compliance? It's very important because when you have products, unit leaders and in this case at Amazon for most times, they're VPs, they get very competitive, right? When you get called out and your product is discussed in the weekly meeting, you believe me, you want more green and more than the yellows and the reds and then your peers, if you get praise for doing something fantastic from a security risk compliance perspective, they're going to want that same praise as well. This all all these pieces of the puzzle come together and then since everybody loves it, every organization has bureaucracy. Try to automate as much of it as you can. Right.

Some examples here at AWS. Everything is a ticket. If you need new soap in the soap dispenser in the bathroom, it's a ticket. If you want a firewall port open it's a ticket and everything in between. So, culturally, people know if i don't open a ticket, it's not going to happen and nothing happens, that can't be tracked, right? So we build that uh methodology into everything.

Inspections and self test regularly, product teams. Um it's not the security team that tells the product team you need a pen dust. It's part of the product team's mission to say, you know, i think we're at the point where we haven't had one in a while or due to our schedule, whatever the case may be, we're going to initiate a pen, we're gonna tell the security team first, but we're going to initiate a pen test, right? Because they have that ownership around it.

And my favorite encrypt everything, protect your keys, restrict admin permissions and m fa all day, we go back to the beginning of this talk, you know, we had the, we had the five customers up there. Um most people would not look at encryption as a business advantage. It might be. We have to do it because we're under some regulatory scrutiny to do it. But assuming you're doing everything correctly here that you're encrypting all data, you're protecting your keys, you have that, um let's say 24 hour rehydration process in place and you get popped for ransomware again. It's a tuesday and that's the business advantage.

Tooling. As we all know, it's much easier to build security in at the beginning of the development process than waiting to bolt it on. At the end. Some of the processes that we have at Amazon that I'll touch on, we have correction of errors, operational readiness reviews and working backwards. So when we look at these three and I'll dive into a couple of them in just a second, um together the working backwards, for example, makes sure that excuse me, product team security etc are working on the right things at the right time and they're building the right tools to be consumed internally because there's an actual need for it, not just because it's nice to do the correction of error process. This goes back to that if something breaks, how did it break and how do we make sure it doesn't break again and again, this could be from something as simple as the soap dispenser was not filled in the right amount of time all the way to something very serious from a security perspective. So i'm sure you all have a root cause analysis, something that's very similar to that. But we do this for everything that does not go as expected. And we learn from it and then we set project plans in place to actually execute, to make sure that it doesn't happen again. And this is just to make sure that it's a virtuous cycle to make sure that it happens every time, the same way with the same expected results execution. So all these other three are great, but if you can't actually execute, they're almost a moot point. So laura grit, distinguished engineer, she talks here about our on boarding training that the on boarding training for developers at aws has a lot of security in it, right? Once as you come on board here, it's not just you're just going to be contributing to the new feature set of uh what was that was announced this morning, amazon q, right? But you're gonna be, you're gonna be doing it securely.

We see that when, as i touched on before, when security development and things are very iterative happens early and with the right frequency, we get different results than what was expected. So the traditional approach here is there's a long foundation period of let's make sure everything's right. Let's then make sure that there's appropriate governance around it. And then is there a use case for this thing we just built? Who knows? But we spent a lot of time and effort and it looks cool and you get that outcome versus the more modern way. If my clicker will click, you come up with the use case first. So this is that working backwards, right? What are we trying to do? What are we trying to achieve? Does this have any security risk, compliance or privacy obligations that we need to meet? Then let's tackle on the governance pieces to it and then let's build it or build enough of it to test it, to make sure it meets what we're doing. And you repeat and you are eventually moving a lot quicker and then your velocity increases, log everything. I can't say how important it is to log everything that you have. And i appreciate there's a storage commitment there to it. But we have found that when you're logging every security event from the application side, the infrastructure side, the security side, etc you may need to go back in a couple of years and dive into security logs to prove to a regulator to a customer, to a partner that you in fact, were not affected by something.

Security into all deployment activities. Again, the idea is you didn't do a bad thing, developer by having more red than green. When you put something in the test, it's operating as it should. Great engineers are also great security engineers and then focus on the security outcome that you're looking for versus the tool, right? Um i spent 22 years in corporate security in various roles and every couple of years there's some new shiny thing that comes out that's going to protect me from every bad thing that ever could happen. And i'm an rs a and i sign the contract and i buy it and it probably ends up doing maybe a quarter of that. But i got a really good steak dinner out of it. Right. If you're focused on the outcome, the tool doesn't matter as much as long as you're very clear on what you're trying to achieve.

So, if we look at aws security tooling, we cover a lot across the core six here, but we don't do everything, right. Um and just because it's a security tool, you may be able to do other things with it. And surprisingly enough, if you're using one of our other 300 some odd services, there may be a security outcome to one of those and it's not by chance, i wrote a blog on this very topic where i look at every aws security. I'm sorry, every aws service as a security service say that 10 times fast. The idea is if you're really focused on what you're trying to achieve from a security risk compliance perspective, there may be a better way to skin a cat using some of the non security services that are out there.

We touched on working backwards just a little bit. So we're going to dive a little bit into it here. We want to be thinking about the business outcome, right? And when i say business outcome, there may be a security component to it. But ultimately, the business outcome that you're looking for, you're going to conduct the appropriate risk analysis. That risk could be. The technology we're using is so old that it will be packed immediately. There's a regulatory piece to this that we don't have the back end controls in for whatever it is, you build the capability that you need to have from security. So you're building that core, secure foundation, incremental security additions, you're validating that everything works and continue to iterate as you develop. If we remember that other chart, this is the point where you get some functionality out the door very, very quickly, you bring out some more, you test, you validate, you test, you validate, you test you validate and you eventually have a product that does all the things that you want it to do.

Here are our guiding principles that we cover today. I hope you all will consider attending AWS Reinforce in June in Philadelphia. That is our security focused conference where just like Reinvents, it's built for security learners and builders of all of all types. We will have developers, you know, non security developers show up and product managers, security professionals, infrastructure professionals, risk and compliance, et cetera.

Some other resources sort of a deeper dive into our team. Some of the videos we've produced some of the white papers we've produced. Be sure once you're on YouTube to like and subscribe, it's my retirement plan. And I'd like to thank you all very much for attending. Um, I'm happy to take, we have a couple of minutes, so i'm happy to take any questions if you have any.