Imagine in this, it's Monday, the last print of a project, and you just had a planning, and you agreed with your team that the things to do are to fix two bugs, and you need to finish writing the good documentation. You feel good. It's Monday, but it's good Monday. What you agreed on is achievable, and you're excited for the release. You're also excited for what comes next. So you feel good, you feel motivated. Let's do it on Tuesday. Engineering manager comes in the room, and she says, look, it will be great if we can this through the security. Just before the release. Have you ever been in this situation? Do you know this pain? Well, you go to the meeting, and security team asks you so many questions. They ask about the documentation that hasn't been finished yet. And after the meeting, you end up with this. Forget about those two bugs. It's a whole bunch of bugs. And trust me, I also don't understand what a snail is doing up there. I've been in this situation way too many times. And each time, we would have this beautiful meeting called project, project retrospective, and we would all agree in the team that, well, having a security review in the last sprint just before the release is too stressful. It's just a horrible idea. And as much as we would all agree and nod our heads, the moment we close the door, we would forget about it, and the situation would hunt us down with every new project. My name is Victoria Dalach. You can find me in the Internet. I've been working tech for over a decade, mostly as a backend engineer. But two years ago, I transitioned to the security team in my company, and it has been an amazing experience because I could see the same organization from completely different angles. So when I would go to a meeting with engineers as an engineer, I would be like, oh, these are my peers. Like, we share the struggle, we share the problems. We support each other. But when I went to another meeting as a security engineer, all of a sudden, I was a stakeholder. I was a person who wanted something. I was a person who had questions. I used to have questions as can engineer, but you know what I mean. I would be the one who was blocking stuff. What? So I notice quite a few problems with security, and I will share something, a piece of security theory that will completely transform the way you approach security. Okay, are you ready? Let's go. So, the problem with security is that, first of all, there are many problems with security. Let's agree on that. I will not cover all of them, but in product teams. The problem I see is that product people, so product designers, managers, owners, think about security solely as an engineering problem. And engineers are so focused on scoping things right, making it achievable, defining mvp, that they label security features as nice to have and put on a shelf with other nice to have initiatives. And the problem is that those features are hardly ever worked on. But there is another layer to that. Security is a huge topic. I like to think about security as an ocean. So when I ask you, what do you think security is? Or how do you know if your product is secure? How would you reply? You can make it an experiment and ask your peers, fellow engineers, how do you know your product is secure? And you will get different answers from all the people. Security is a huge topic. There is application security, cloud security, infrastructure security. It security. When we think about application security, only they have vulnerabilities, risk factors, threats, so many of them, it's overwhelming. And the lingo. Oh, my gosh. The lingo security people use is difficult to understand. So, before I joined security team, I had thought that we as developers, have weird way of talking because we use a lot of different weird words. But when I joined security, the first six months, I would Google acronyms for, like, at least three to ten acronyms a day. So there are many layers where security is just overwhelming. But I bring you hope, because I have something very exciting to share. We can all agree security. We can all agree that there is an infinite amount of threats. Can of threats, you may say. We cannot identify all the attack vectors that your application is vulnerable to. We cannot do that. There is an infinite amount of threats. And every week, you got news about our new vulnerabilities found in libraries that everyone uses. Infinite amount of threats. However, this is beautiful. Wait for it. All of them. All of those threads can be assigned to one of three categories. This will be an acronym, but I think you know it. Those three categories are confidentiality, integrity, and availability. And this is called the CIA triad. I could make a joke about spice, but I will not do that, because the only spice I like to think about are spice girls. Forgive me. Why is it so exciting? The CIA triad. Why is it so exciting? Why is it something that I want to talk about to you, and I want you to later talk about with your peers? Why? Because the CIA triad let us put the whole ocean into three buckets, and it's a very impactful thing. But before I tell you, why is it so impactful? Let me just define what CIA means. Confidentiality means that we want secrets to be secret. If I send you an email or you send me an email telling me how did you like this talk? We only want us to read it. We don't want anyone else to interfere in our communication. Right. Integrity means that we get what we expect. So when you log into your email, you want to see all of your emails, right? It would be very weird if you had all of your data lost availability. We can always access the information. So we expect that you can send me this email 10:00 p.m. Or 03:00 a.m. In the morning. No matter when you can send email, you can access Instagram. Your application will work 24/7 right? This is availability. Okay, so how is it helpful? How is it helpful? You see, it is helpful because it transform the way you can approach security. Instead of thinking of oh, I want my application to be secure, how do I do that? Oh, this is this vulnerability. Do we have this vulnerability? Okay, we don't. That's good. And this vulnerability we don't have. Okay. And this, oh, we need to fix something. This is completely overwhelming. How are you supposed to, as a developer, remember about all of those things? It's impossible. So the CIA triad is very helpful because instead of going from threats, vulnerabilities lists, you take a step back and you ask the question, the question, the CIA question, which is how can the CIA of this project be broken? I don't know if you can fear, but it excites me every time. Think about your current project. Do you have it? Okay, you can ask the CIA question for it. Let's do it. How can the CIA of you say it be broken? How can the CIA of your project be broken? It's so powerful because it works for everything. It works no matter if you are backend, front end, mobile, if you work in a cloud or not. If you are junior developer, meet senior staff, whatever director. If you are product manager, you also can ask this question. If you're a designer, you can ask this question. This will work forever for you. How can the CIA of the thing I'm working on be broken? And of course, if you want to answer this question, you will need to dig deeper and ask more questions. And for each category, confidentiality, integrity and availability. You will ask questions specific to your project. But here let me share some ideas, some examples of questions you can ask confidentiality who can see this resource? How do I store credentials? Do we log sensitive data for integrity? Who can create update remove a resource? What happens when a malicious data is sent via form is the input sanitized? Are we protected against cross site scripting? These are examples of integrity questions. Availability, is this endpoint rate limited? What happens when external product is down? How much time does this database migration take? These are availability questions. And let me just stop for a second with the availability, because I get this often that when I say availability, developers stop listening because we think, ah, availability infrastructure group, infrastructure team. But this is not necessarily true. I mean, it's not true at all, because as developers we introduce new products, new libraries, which means dependencies. And you really need to think about what happens when this great product that you use for managing feature flags go down. Does it mean that our whole product is down? Availability. Don't skip it when you do this CIA questioning with your team. So now the question is when should you do this? Okay, so you maybe understand what the CIA triad is now. We talked about it, I told you about the questions, but when should you do this? Like your practice is already full and booked. So I cannot answer this question without telling you about shifting security left. Shift security left is this new way of thinking about security. And if you ever meet an application security engineer, probably in your company, ask them what shift security left means, because they will be probably thrilled to tell you more. But the idea is that when we look at the software development lifecycle, right, we have five phases, requirement analysis, analysis, design. Can I count on my fingers? Design, implementation, testing and evolution. But here's the thing, so I've been doing this way too long. I don't think we are working in a lifecycle. It's more like a timeline. We do analysis, design, we develop, we test, and then we release and maintain, right? And after we release, we just move on to the next project. So it's never really a lifecycle. If your experience is different, let me know. Anywho, we have this timeline and what happens. Remember the story I told you in the beginning? We had security review just before the release. It was on the right side of this product development timeline. So shifting security left means shifting security, thinking about security, approaching security to the design phase, right? So why is it so important? Because in the design phase, creating changes is very easy. Because what you do, you only, I don't know, change a document, change a graph. You basically work on a piece of paper. Whereas when you have security review just before the release, the changes are extremely expensive. Not to mention how expensive they get. When you already release a thing, that's horrible. And it's more stressful, it takes more time, it's more expensive, it's terrible. Shifting security left says hey, let's talk about security of this thing that we are working on before we even code. Let's agree on that so we can have some kind of confidence that what we are building is secure. This is shifting security left. So how do you implement this CIA triad in your company, in your practice, you inject it basically what it means, present it to your peers, you can send them this small video, discuss it with your team, discuss approaching security earlier. Invite your security team to discussions so they have some kind of input and they can help you and guide you. But also make it part of your process because in order we talk about scaling a lot. Security cannot be just an ad hoc action. It needs to be part of your process. And how do you do that? The easiest thing except of telling people about it is to update the documentation like documentation templates. So if you have documentation templates like solution briefs, enhancement proposal, request for comments, et cetera, add security section there, add CIA triad show. Hey, how will this affect confidentiality, integrity, availability? How can we break it? How can this new feature break confidentiality, integrity and availability? And it will help you work and create more secure solutions. Important thing, you don't have to do it on your own. Those can discussions are meant to be run together in the team and the more perspectives you bring the better. So you don't have to focus on back ends only. Like bring front end engineers in the room, bring a designer product manager. How can you create find a solution that is basically a compromise between business and security? Compromise, is it a great word? I think so. Like what we need is some kind of connection, some kind of understanding. You can do it to finish up. Look, there is no week when we don't hear about a data breach or vulnerability that is in this super important library that everyone uses. We need to as engineers step up and we need to understand that things that we are building have a huge impact on people's life. We need to take responsibility for that. The colorless times of moved fast and break things are over and it's a good thing actually. I hope that the CIA triad will help you create more secure software, approach security in an easier way, moved manageable and I think you will have great fun. Thank you for joining me today. Thank you for listening me and please let's stay in touch. I'm online. Well, thank you,