 protecting your Rails app and user data. How many of you here were at DHH's keynote this morning? Cool, almost, I think all of you. So, I was also there, sent in the audience, and I noticed that a lot of the themes he had in his keynote are actually similar to what we're gonna be talking about today, so I'm excited for that. I'm super excited to be here. This is my first ever conference talk. I can't believe it's here at RailsConf amongst this awesome community, so. Just one note, if you're looking for a chore list of what to do for putting in security measures, it's not gonna be exactly that, but I'm hoping to start a conversation here and really start talking about security in a new light. So, let's get started. So, originally, when I was creating this talk many months ago, the title was Uncertain Times Ahead, but in those couple months, a lot has happened. It's been some un-trying times. Yeah, another connection to DHH's talk, The Juicero. What is up with that? I don't know, but it's not Uncertain Times Ahead. It's Uncertain Times Now. Uncertainty has always been here, and especially now, I think it's more, we're more aware of that than ever. So, who am I? I'm Krista, you can find me on Twitter. Krista A. Nelson, a bit about my background. Went to a big university, studied math. Went to a big corporation, spent a lot of years making rich people richer. Got sick of it. Went to the Turing School out in Denver. It's an awesome seven-month Rails program. If you haven't heard of them, check them out. And then after that, I was looking for my next career and my next job. I really wanted to make sure that I found something that I was passionate about. I'm not just making other rich people richer, and if I'm gonna wake up and work hard every day, I'm doing something good. So, I found Glassbreakers, which is an enterprise, whoo, it's an enterprise platform that connects employees on personal identifications. So, things that are really sensitive, like your race, gender, sexual orientation. Also, some more fun things to do like foodie or hiker. But why we are there is to, again, connect people to build a platform to empower them. And so we wanna make sure that we're not putting them at more harm by having us trust in their sensitive data and not treat it well. So when people ask me what I do at Glassbreakers, it's hard for me to come up with an answer because I'm a back-end developer, but I do more than that. I really focus on the security and making sure that we're doing everything that we can do. Unfortunately, when you say you work on security, people's minds think security, network security, firewalls, and they start asking me all these really complicated questions that I actually don't focus on day by day. So I was trying to come up with a new way of explaining what I did, and I really had to think, why do I go to work? What am I doing? I'm trying to build something that's gonna help people, and I'm trying to protect them from harm's way or bad. So then I came up with, I'm a protection advocate, but then I thought, that might sound like I'm advocating for a different type of protection. So I, which I advocate for all protection, but I landed on developer user protection advocate. So that's what I'm gonna go on for now on. I hope there's some more of you in the crowd, and I hope after this talk, you'll all wanna become user protection advocates because I think we need a lot more in our community. So this, this has been me pretty much the last year, digging into security ever since I've taken over the focus. I've just been reading blogs and blogs and blogs. If you Google software security, oh my goodness, like the outcome that you get from that, there's just so much to dig through. And the more and more I read, instead of becoming more clear of what I needed to do, I was getting more clouded, kind of more confused, like what do I focus on this? Do I focus on that? You know, where do I go? So then I started talking to everyone I could, anyone I could talk to about it, I would try talking. So my coworkers, my parents, they're so sick of me talking about this, my Lyft drivers, my mailman, you name it. I was talking to them about security, and I noticed two things. Everybody loves talking about security. Everyone has their favorite like breach story, you know, like, oh, the Ashley Madison, you know, the LinkedIn, the Yahoo's, everyone knows about, it's a problem, they have a favorite story. And then the other thing I noticed was everybody had an excuse, why they didn't have to worry about it. Like, oh, it's a good thing that at my company, we have a security team, so I don't even know what they do, but they handle it, I don't have to worry about it. Or, I hear this a lot, oh, our company's too small, it's lucky we don't have to worry about it, we don't have any information that's sensitive, we don't have, you know, HIPAA compliance, so we're good, we don't have to worry about it. Or, oh, yeah, I know, we have to worry about it, but we just have to get out our MVP, like once we get out our MVP, then we're gonna have all this time, I'm sure a lot of you have heard that before, that like, we'll have time in the future, but that never comes. So, I noticed there's this big disconnect. Everybody knows it's a problem, everyone knows here's the stories, but nobody's taking action on it. So, why is there that disconnect? At the same time of doing all the security research, I was also getting ready to go on my next hut trip. So, every year I go to Colorado and our friends and I get together and we hike seven miles out into the middle of nowhere, on top of a mountain with no cell phone, no Wi-Fi, hike through Avalanche zones to completely disconnect. And as I was preparing for this, I was also talking to people about it and everyone didn't get it. Like, why would you do that? Like, why would you spend your time off and want to put all that effort in doing something that is so dangerous? You know, there's so many risks. You could have a blizzard, you could get lost. There could be an Avalanche. But to me, it was in my heart, I knew why, like it wasn't a question. I knew why I would want to do that. It's worth it, the journey's worth it. It's this beautiful atmosphere and there are risks, but you just handle it. You know, you do your training, you get your gear list. It's just kind of built into the process where you're kind of always thinking about it, but never realizing how much you are thinking about it. It's just part of the process. So then I kind of had this aha moment. They're kind of similar, right? There's a lot of risks in security. There's a lot of risks in back country. Basically, you need to figure out how you can best protect yourself, but what was the difference between me handling our security research and this Avalanche safety research and it was the passion? So here, again, risks. Anything out of all of the research I've done on security or on Avalanche training, every tip and trick and recommendation, when you really look down to what they're suggesting that you do, it's just understanding your risk. Understand what is the probability that this is gonna happen? What are the consequences if it does happen? And then how can I minimize my vulnerability to that and how can I limit my exposure? So if it's so clear that all we need to do is look at our risks, always be assessing our risks and figuring out how we can limit our vulnerabilities and exposure, why is this a $350 billion industry? And I think this is the problem here. So it says one cannot be prepared for something while secretly believing it will not happen. And I think from going back to all the talks that I had done, it was one kind of theme, one common theme. It won't happen to me. It's not gonna happen to me. It sucks for the people it does happen to. I hope they're doing something to protect themselves but it's not gonna happen to me. Also, when I was doing those talks, I realized some of these companies I'm actually a user for, I use their product and I hear, oh, do you do security training? Nah, we don't do it. And then I realize I am trusting in these companies just as the users at my company trust in me and I wanna make sure that they're preparing for me just as I'm preparing for our users. So to help try to get through this, it won't happen to me, mentality. Here are some stats. 43% of cyber attacks target small business. So I think a lot of companies think, oh, they're only after the big dogs, they're only after enterprises, but no, 43% of attacks attack small businesses. You might think, okay, still won't happen to me, like there's a ton of small businesses but out of holds small and medium sized business, 55% reported that they had a cyber attack and 50% reported they had a data breach. Again, that's just the percentage that reported it. A lot of companies will go an entire year without even knowing they were attacked. So it's now obvious there is a good chance you are gonna get a breach or cyber attack but then oftentimes you hear, well, how bad can that be? So if this is happening to everyone, they get through it, we'll be fine but 60% of small companies that suffer a cyber attack are out of business within six months. This is what my brain felt like when I heard that stat. We work so hard to try to get our companies to flourish and thrive and yet 60% of small companies that suffer a cyber attack are out of business in the six months and 55% report a cyber attack. So often they'll say, okay, we'll buy a product, you're right, we get it, we'll buy a product, we'll throw money at it, that'll fix it. 48% show root causes from a negligent employee or contractor and 41% show root cause from a third party. So again, even if you throw as much money at all the products that you want, how are you gonna get control of your employees and third parties? 63% of companies have confirmed a data breach, leveraged from a weak default or stolen password. So I already had to change the title once. I'm changing it again now to change your passwords and enable two-factor authentication. If there's one thing I can get out of this talk is I hope all of you have a secure passwords and two-factor off enabled. So also 63% of businesses don't have a fully mature method to track and control sensitive data. So most of us are gonna get hacked. We know it's a problem, yet the majority of us don't have a system in place. So let's hit the road and see what we can do. I'm gonna talk about three things. How to get everyone involved, mapping your sensitive data and securing your software development life cycle. All right, so get everyone involved. So back to those conversations that I was having. And again, so many people were saying, I don't have to be involved. We have a security team, they handle it. When you are out in back country, even if you have the best expert with you guiding your group, if you have one person that's having an off day, not paying attention, if they make one wrong turn, they can trigger an avalanche and put your entire group in danger. If they're not prepared to know how to use the tools that they have, how to use their beacon, their transceiver, how to, the skills it takes to locate a person and probe them and where to dig them out. Again, you're putting your trust in them that they're here to also protect you. So again, it doesn't matter if you are an expert, if you have an expert, if you have one person in that group that's not prepared, it can be really costly. So one issue I found is you have to talk to leadership. So how do you get everyone involved? Again, everybody's busy. Usually now, everyone's wearing multiple hats. There's deadlines, you have to get your project done, you don't wanna get in trouble. So you just need to do what you need to do in order to get your work done. And if you have time later on to learn some security things, cool, but you need to focus on what you need to focus on. I noticed too that if leadership is not on board with this, they're not gonna understand that they're the ones that need to lead by example and do what they can do to make sure that they're protecting the company. And then also understanding and budgeting time. You know, if something didn't hit its deadline, understanding was it because they were just trying to be secure and be careful and make sure the product was safe. So how do you get leadership to buy in? So again, to show them the stats. 60% of small companies suffer a cyber attack or that suffer a cyber attack or out of business in six months. So again, when you're getting pressure from leadership to focus on other things, just remind them that if they wanna make money, 60% of small businesses are out of business. Also remind them of what the bottom line is. Regardless what your bottom line is, if you're there to make money, if you're there to help people or if you're there to help the planet, you're not going to be able to do those things unless you are fully bought in on the team. Like this is why we hear, we are waking up and working our butts off in order to do one of these things or maybe all three. So again, when you're budgeting time and getting efforts, make sure that they understand that if you wanna make money, I think from the small and medium sized businesses, it was almost a hundred K cost for each breach that they had. So again, putting some time up front can save the company lots of money. And again, if you're here to do good, I just saw in the news, there's this awesome new app that made me really excited. I can't remember what it's called, but it's basically a panic button for those that are in fear of getting a tax less minute by immigration. And it's this really great concept. You have your contacts and a message to each contact where if something happened, you can hit the button and it'll send messages to those contacts. I was so excited to hear about this project. I thought it was great. I went to their site and I noticed they did not have the certificate, the SSL certificate up in the browser. And I broke my heart. And on the form or on the page, there was a form where you put in your phone number. And so my, you know, that's what I'm thinking about now is security is if you're putting in your phone number, again, and you can identify someone by their phone number and providing all of this very sensitive and secure information. And if it's not at a trustworthy company, you can end up doing way more harm by if that information got breached, then it would have done good. Luckily, I went in and I checked the form where they got the phone number and they had the encryption at the form level. But again, if you were unknowing and you went to the site, it'd be really easy to have a fissure where they made a site replicate this other site and you could put in your phone number and they would know who's at fear of hitting into the situation. So again, make sure you can continuously kind of give this message back to the company of why are we here? What are we passionate about? What are we protecting? All right, so how do we get everyone involved? So make sure that everyone at the company is included in this program. So that includes employees. It also includes contractors. Anyone with access to sensitive data and code. One of the great things about the Rails community is mentorship is really big here. So if you have a mentor or an advisor that can see your code or can see your sensitive data, make sure that they are also on board. So every single person, anyone that has access to any part of your information. What? Make sure that they understand what is considered sensitive. I think most people assume we know, okay, a social security number is sensitive information. But talking to the full team, it was surprising to see how many people didn't realize a name. That's sensitive, an email is sensitive. Even just knowing that you're a part of an organization, if you're signed up for an application, could again, if someone got it in the wrong hands, could be harmful. Why? So protect yourself, users and the company. I read a blog on the, it was onboarding for startup security and it broke down what it really meant when you signed your documents and included, so these companies do get breached and what happens when you get breached? You could be sued. They could take an image of your computer knowing what information that they're gonna have. I'm sure a few of you maybe sometimes have once or twice done a personal thing on your professional laptop. Maybe you checked your email or your bank statement. Understanding that when you're signing those docs, what you're putting yourself up for. And again, your users and your company. When? Make sure that everybody knows when to say something. I think a lot of people can be afraid by security. So maybe they did click a link that they shouldn't have clicked and they think, oh, should I, I probably should tell someone. But let them know when they should step up and say something. And then where? Have a repository for all your policies and make sure that all of your employees can have access to that and easily pull it up if they ever have a question. All right, so now how? Password managers. Who here uses a password manager? Nice, oh my gosh, this is so great. So this is, most of the room is using a password manager. I think also we need to step a little bit outside our bubble. It's so great that we all are using password managers, but as I've been doing these talks and really talking to everyone, most people don't actually know what a password manager is yet. So a password manager is just a way that you memorize one password and it'll generate random passwords for all your logins. So that way you can have different logins for every system. You can go to, I think it's www.HaveIBeenPoned.com and you can put in your email and it'll show you if your email and password has already been hacked. And I have a guess that most people have. Two-factor authentication. This is another common thing that I heard when talking to people is everybody knows they should use two-factor authentication, but then you hear, oh, but it's so annoying. I have to get up and get my phone and oh, I don't have time for that. But again, it's important. So is it worth getting up to get your phone to protect your users? Secure your devices. So I live in San Francisco and it cracks me up. So I'm often, I'll work in coffee shops or go to meetups and it blows my mind how many times I see someone with their laptop just wide open and they'll just walk away. And it'll be open for more than five minutes without a password screen popped up. Again, most people, you got stickers on your computer, you're wearing shirts, so they know who you are. So please put a password lock on your computer. Again, these are not new topics or new subjects or new insights, but how many people are actually practicing that? When in doubt, delete. So if you have spreadsheets of user information or anything on your computer, you don't know if your computer's gonna get stolen. So keep as little information on your computer as possible. And careful what you email. I think we work so hard to protect our application and our databases, but then we'll blink out and we'll send an email with user information to it to one of our coworkers. And so also make sure that your full team understands that emailing is not safe. So make sure that you have a way to set up where you can pass information through encryption using a GPGP or up on box, but definitely don't email. And also I've heard so many companies that use Google Docs for everything and also I see they put user information in their Google Docs, so be careful. A good developer is a secure developer, Kristen Nelson. So this is a quote by me. Also, so again, when I say that I work on security, everyone assumes I'm a security engineer, but really this isn't just a task that I should worry about. Like every developer should be a secure developer, just like this Rails community, right? Like we all wanna write clean code. We want it to be readable. We want well tested. Why do we not put an emphasis on something that is so costly to our programming? So relating it back to DHHU's talk, he talked a lot about how you have to have roots. If you don't have roots, you're not gonna understand why you're doing what you're doing. And if you don't understand why you're doing you're not gonna care. You're just gonna keep doing the motions, be miserable. And this applies to security as well. So again, there's so many chores that you could have to do and they can seem annoying, but if you really figure out why you're doing it and what the fundamentals are, I think it'll help make it less painful. So the fundamentals are CIA, so confidentiality, making sure only those who should be able to see the information can see it. Integrity, making sure that that information is what it should be. So again, are people logging in and changing information? Are they mimicking? Are they trying to duplicate a certificate? How do you make sure that this is what it should be? And then accountability. I think we see this a lot with the DDoS attacks of if someone needs information, can they trust that it's gonna be there? This, the OWASP. How many people here have read through all the OWASP docs? Okay, a few hands. So this is probably the first thing that I would recommend for developers is go to the OWASP site. It's the open web application security project and it is an open source project with just a ton of awesome tools. They have a fake app setup that you can test and play around with. They have the OWASP top 10. They just came out with a new release and they're looking for feedback on it and they're gonna do the final release later this summer. But they have these awesome resources. So these are the top critical vulnerabilities that are most likely gonna hit your application. So if you can focus on these top 10, you're gonna get the majority of the vulnerabilities that you're gonna be put at risk. Again, it's not gonna be 100%, but this is a great place to start. Understanding encryption types and hashing algorithms. Understanding why it's important. Again, I've seen apps where they still have the SHA-1 password. So again, you don't have to know the full details of all the different hashing algorithms, but know what you can trust about them and what you need to know about them. All right, next, mapping your sensitive data. So when you are going through Avalanche Zone, it is critical to 100% make sure before you go into the zone that you know exactly where your danger zones are. Cause again, when you're out there, it's very hard to see. Okay, if I step here, I'm safe. If I step here, I'm not safe. So you need to have it well mapped out and know, okay, if I walk through this area, I need to put extra caution. You can do things where you send one person throughout a time to limit your exposure. You can talk quieter, you don't shout. There's all these kind of tactics to limit the chance that something's gonna happen when you're in one of those zones. So how do we do that with our applications? If you start thinking about, okay, we have the sensitive data or we collect all this data from our users, what do we need to keep safe? So again, personal identifiable information can be so much, again, a name, a phone number, their LinkedIn URL, an image, all those things could tie a user back to an application. Do you have any protected health information that has a whole nother laws and compliances that you need to enact if you hold any of that information? Payment card information, social security numbers, messaging, communications, logs, all these things can have sensitive information that you need to keep track of all those things. And if you think about all the journey of that information, right? So if you have someone's email address, you know, they use it to log in. It comes to the application, it gets saved in the database. We goes out to SendGrid or MailChimp, we send them emails. We have like a third party tool that tracks analytics on that user. Maybe there's spreadsheets or, again, so many places that this information could go. Adding in third parties, knowing what information gets sent to what place and who has access to all that information. So again, you can be aware of, we need to be safe in this place or if someone leaves the company, you can know exactly where you need to go and check to make sure that they no longer have access to that information. So 41% show root cause of data breach from a third party mistake. And I think this is one of the things that was really shocking to me too. I think we put so much trust in other third companies. Again, we just assume that they've done their diligence. It'll actually be safer. Instead of us having to do our work, we'll make sure that they go and do their work or we just assume that they went and did their work. But again, a huge percentage of data breaches happen because of your use with third parties. So before you use a third party, make sure you do a security audit on them. What are their security policies? Who has access to their information? What information are you giving them? Have they done penetration testing? Do they have vulnerabilities? Have they had any recent attacks? You can get there. There's a SOC2 report and it'll show all of the security measures that they've been through. So every time that you're sending any of your information from your platform to another company, you need to make sure that they are trusted and legit. And again, make sure that that is ongoing too, that maybe they were secure, but then there was a vulnerability. So you need to keep that line clear. Also, I think another big thing with third parties is you assume the defaults are secure. So I know there's all these different tools out there that you can plug into security. And I know one where they were tracking exceptions, but the default was, so when it tracks an exception, it grabs the params of the request body and it captures that in time so that it can help you determine what caused the exception. There was no filters. They had all these filter options, but the filters were not default. So again, what information is getting trapped in that params? Raw passwords, social security numbers. So make sure that if you're trying to do good by adding a third party, make sure you read the docs and make sure you're setting it up in a secure way. Also, if you're the reverse, if you're a product and you're offering a service, if you have security measures, a lot of times you'll go to the site and be like, oh, we offer authentication and all these things. If your users have to take a step to enable that, make sure it is like read and clear so that they know to set it up. The simplest things are often the truest. So again, when you're doing analytics, do you need to send all of the user data to your analytics tool? Can you completely anonymize it? Again, the less that you send, the less chance there is gonna be that it's gonna get compromised. All right, and last, securing your SDLC. How many people here have heard of the SDLC before today? Okay, about half of you. So the SDLC stands for the software development life cycle. And again, even if you didn't realize what the SDLC was, you're probably doing it. And again, it's just the fundamentals of how do you get a project from the very conception of an idea to deployment? So you start by spec-ing, right? What are we building? What's required? Why are we building this? Really think of like the high level. What needs to get done? What do we need to think about? Like, do we have privacy laws that we need to withhold? What are the terms and conditions? What have we promised our users? Are there any ethical and moral requirements? Do we need to make sure it's encrypted? How available does it need to be? Features. So again, when you're budgeting time and building out your product, think about what features can we include in this, should we include in this to make sure that our users are as safe as possible? So user privacy settings. What do they want to choose to be public and to be private? Strong pass rate requirements. Again, if you make your pass rate requirements, I mean, this would be extreme, but 30. Basically, 30 characters in length. People are gonna start having to use a password manager just because it's unreasonable to try to come up with one that long. Do you offer two-factor authentication? So again, we expect the platforms that we use to have two-factor authentication. Are you yourself providing that as well? Email authentication. So again, did you set up your SPFs and your decams on your emails? Secure sensitive data deletion. So what does it look like when you delete a user? Is it really getting rid of all your information from all your tools? A mass staging environment. A place you can test your product to make sure it's not gonna have vulnerabilities, yet at the same time, not putting that information out for another place to get breached. Anonymized analytics. So once you get your main features kind of specced out, the next part is design. So this is where you go and really dig into what are these features gonna look like? So in avalanche safety, avalanches happen when every time it snows, there's a new layer of snow and there's always a weakest link. And once it gets triggered, that weakest link layer is what lets go and that's where the slide happens. So again, what are your weakest links in these features? Is it your input? Is it your authentication? How likely do you think these things are gonna happen and how consequential will it be if it does happen? And then also once you figure out all of kind of the risks that you can think, really like ranking them, what are the ones that are kind of the most likely to happen, the worst that's gonna happen, and are there measures that you can take to mitigate those risks? And if not, maybe the feature's not worth it. Again, you have to think, is this feature gonna add to the product or in the end do more harm? Peer code review. So one thing that I've read over and over and over again is even with all of these tools, one of the most effective way of catching a security breach is through peer code review. We are human, we're tired, we're overworked. There's a lot to think about. So having an extra set of eyes can really make a difference. So I recommend making a security code review checklist and just checking these things. Is it authenticated? Is the authorization set up correct? Are we encrypting sensitive data? How's the error handling? Again, if we give errors that could give hackers clues into how our database is set up, it could lead them into harm's way. Is there, oh, any add-on configurations? So again, if you're pulling in a library or you're pulling in a third data, do double-check to make sure that that's a secure source and that you have the configurations set up in a secure way and complex code. Give an extra look to complex code, because again, that's usually where the breaches can happen. Sack analysis. So again, with the, there should be two types of code review. The manual human code review and then a static analysis. And there's a ton of programs out there. It doesn't matter to me which program you use as long as it works for you. But these go through and catch a ton of things. So Breakman is just phenomenal. I'm so glad. Thank you for doing all the work that they do. But everybody should have, at least Breakman, if not all of these on their code practice. So again, you can set up, if you have CircleCI, you can set it up where every time it runs, it does these checks. I'm gonna can check for top problem abilities. Again, those OWASP top 10s. Can check all of your gem dependencies. There's bundler audit, which makes sure that you're not having any dependencies in your gem file that has vulnerabilities. So manual testing. This is one of my favorite Giffy's. If you can't see it, he's shooting in his code product and then a QA Gumby shuts it down. But again, if you spent all that time writing your code, building a feature, test it, also try to break it. Make sure too that it's not just you. You have some coworkers going in and purposely put in incorrect input and see what happens. Dogfood, your own product. Our CEO is famous for, she's the best at dogfooding our own product. I don't know how she finds all of the bugs that she finds, but it's usually in a demo. But make sure again, you are using your own products. Set up a secure staging environment. Again, if you wanna make sure that what you're testing is gonna be true to what's gonna happen on production and test on different account types. So again, it might work for you, but maybe you have a different authentication level than what your users have. So when you're going through and testing, make sure you log in as a user, log in as an admin, log in as all the different roles and make sure that only things that should be happening are available to that access level. Dynamic analysis. So this is where it'll actually go in and try to hack into your code. Qualys has this great SSL test and you can just type in your website and it'll test your certs. So again, I'd set up a weekly calendar reminder to every week, put in your website into Qualys and just make sure your certificate's set up. Tinfoil and Burp Sweep and OS app. Again, there's a ton of products out there and they are in range of price point, but I would figure out a way of not just doing the static analysis, but dynamic analysis too. So deploy, be on high alert. So once you've deployed your code, usually you just wanna celebrate, go have a beer, you did it, you hit your deadline, but you're not quite done yet. So again, as soon as you push your code, go to the logs, figure out what's gonna happen. Have a way to revert the code if it crashes, right? Check your logs, check your page load times, check HTTP errors. What does your database performance look like? Are there any weird database queries? Logging. So again, make sure that you're familiar with logging. I know when I started, I knew it existed, but I just kinda thought it was there just in case for emergencies, didn't really wanna go into it. But again, really get familiar with it now. The more practice that you have, the better you're gonna get. So just with Avalanche training and being in the back country, every trip that I take, I learn more and more things. And every time something then happens, I'm quicker to being able to respond. So get friendly with your logs now. There's also a ton of different products out there where you can help filter out noise. You can consolidate all into one centralized location. You can have it where it's structured. Loggerage will condense it from multiple lines down into one lines. So take the time now to clean up your logs, get them set up so that you're comfortable with them so that if something did happen, you'd be able to tell and you'd be comfortable. Monitoring and alerts. So again, make sure that you know what the norm is so that you can see what those spikes are. And then set up the alerts for, how critical is it? Is it, if it happens once do you need to be alerted or is it where it's happening many, many times over five minutes you need to get alerted? Also know how severe is it? Should we wake up the engineering team? Is it more disadvantageous? So again, this will be kind of constant refactoring, if you may, of always kind of updating what those alerts will look like for you. So uncertainty is the only certainty there is. And knowing how to live with insecurity is the only security. So uncertainty is definitely here now. It's definitely not going away. It's not helpful to just be afraid by it. I mean, it's really the only most certain thing there is. And knowing how to live with insecurity is the only secure way. So again, we just need to build these into our course. We need to be passionate about it. Why are we here? Why do we care if our systems are secure or not? And figure out how to update our daily processes. So again, I am Kristen Nelson. I am working at Glassbreakers. Glassbreakers is hiring. So if you're interested, it's an awesome organization, come find me. And I hope that after today's talk, we have more user protection advocates in the crowd. Let's spread the movement, all right. Thank you.