Imagine us. It's Monday, the last sprint of a project you just had planning. You agreed with your team that you need to fix two bags, you need to write the documentation, and you're basically ready to release th you feel good, you feel motivated, excited, excited for the release. You've worked so hard. You're excited for the future and new project that's coming. It's Monday, but you feel great. You feel that what you planned with your team is achievable. So let's just do it on Tuesday, engineering manager comes to the room and she says, look, I think it would be good if we run this through the security just before the release. And in this case, it would be great, means we must do it. So you go to the meeting with a security team, and they ask you tons of questions, and they look at documentation that hasn't been finished yet. And after the meeting, you end up with a whole bunch of bugs to fix. And if you ask me, I also have no idea what a snail is doing among all of these other bugs. Snails are not bugs. Right? I've been in this situation way too many times. Way too many times. And every project, we would have this lovely meeting called project retrospective. Do you know this meeting? And we would be like, oh, you know what? Having security review at the last sprint of the project, it's not good. It's stressful. It adds work. We don't want to do it this way. And the moment, trust me, the moment the meeting ended and we closed the door of this meeting room, we would all forget. But it. And this review, security review in the last sprint would hunt it over and over and over again. I mean, it would hunt us over and over and over again. To put things a bit into perspective, my name is Wiktoria Dalach. I was born in Krakow, Poland, but I'm based in Berlin, Germany, and I've spent the last decade building software. Two years ago, I decided to switch the perspective and join the security team. And it was great opportunity for me to see how organization works from different perspectives, because when I was an engineer, software engineer would go to the meeting with other engineering team and other engineering managers, and we would be peers. We would be like, yeah, let's build it, let's improve it. Let's do something, whatever this something was. But when I started working as a security engineer and I started saying, oh, this is what is important, I got pushback. I was like, I was not a peer anymore. I was another stakeholder. So I realized that there are some low hanging fruit like things that you need to pay attention to in order to create good, secure products. And today I'm sharing those with you. All the notes from this talk are available under this link. So no stress about taking notes or something. We can just enjoy our one on one conference experience. So first of all, pay attention to access control. You cannot grant admin access to everything and you cannot give it as a freebies. No, you need to be very careful how you structure the access control and what kind of resources people have access to. And look, this is very difficult for us engineers because we are like, oh, but we want to see this feature. We develop some feature, why can't I access it on production with my customers data? Right, you can get the pushback like that. But please be very strict with the access control. The role structure in this access control will not necessarily match the structure of your organization. Pay attention to that. Even if you are a senior software engineer, you don't necessarily have to have access to everything. Even if someone is the CEO of company, they don't have to access all of their AWS instances. For example, pay attention to that. When you are embracing the cloud native and cloud architecture, you probably deal with a lot of services, services that microservices that talk to each other. And here's the thing, I've heard so many times that oh, this is an internal service, we don't need a special authorization for it because, well, only we know about this address. This is not true. This is actually the easiest way to cause a data breach. So secure your API, secure the connection between your services and again restrict the access. Make sure that authorization is in place. Low hanging fruit, but super important misconfiguration hurts if you use defaults. If you store credentials as a plain text, it's a horrible threat to security of your product. So educate yourself. Like search for the best practices, update your servers, make sure that if attacker comes to the system and breaks into your server, for example, they cannot just read their credentials for the admin account in plain text. Educate yourself, read the best practices and follow them. Sometimes it can be annoying because maybe no one will check it, but don't overlook it. Misconfiguration is one of the biggest security threat for your product. The good thing is that you don't have to do all of this alone. Lent machines work for, I mean apps that can scan your system. So the most popular solutions are SAS and dust. Dust is dynamic application security testing tool and it means that it's an application that works with your front end, your web application, and it just sends malicious input, malicious data there and sees the response. And if the response is, well, bad, then it will inform you, alert you about it. The other type of application security testing tools is SAS. SaFt is static application security testing tool. So the thing is that instead of dealing with your web app, SAS tool just goes into your code base and scans it. So it's very handy when you're developing things because you can integrate SAS into your pr, for example, into your workflow. And every time you add something new, the SAS tool will run analysis and tell you, whoa, wait a minute. You just created a potential SQL injection or misconfiguration. It is worth implementing, especially if you are growing organization. If you're a small startup, then maybe, well, you need to navigate between speed and security. I understand that. But if you are already in a growing organization, the sooner you implement those tools, the better, because the culture of your organization will grow with the security in mind, which is very difficult to implement later. And now I would like to share something that absolutely blew my mind when I became my transition from software engineer to security engineer. The problem with security is that from the product team perspective, the product people. So designers, product managers treat security solely as an engineering problem. And engineers are so focused on delivery and on scoping their mvps that security features are very often put on the shelf called nice to have. The other problem with security is security is an ocean. It's a vast topic. You have application security, infrastructure security, cloud security, you have it security. You have human security. In application security, you can think, but threats, you can think about vulnerabilities. It's an ocean, and you're just one developer and you should deliver secure product. Right? This is overwhelming, but I bring you hope. And the hope is that we all agree that when we think about threats, when we think about the dangers for your product, there is an infinite amount of threats. It's like an ocean. Like you cannot analyze enough and find all of the attack vectors because it's such a dynamic field. Like every week you get new vulnerabilities. Every week you hear about a new data breach. So there is an infinite amount of threats. But all of those threats can be assigned to one or three categories. It is so amazing when you think about, so this ocean, this ocean, you can assign to three categories, and these categories are confidentiality, integrity, and availability, which are called the CIA triad. I could make a joke about spice right now, but the only spice I like to think about are Spice Girls. So I will skip it. What it means the CIA triad it means that you can put the whole ocean, the whole ocean into three buckets. Confidentiality, integrity, availability. The whole ocean and three buckets. That's amazing. Before I jump into how to do it, let's establish what confidentiality, integrity and availability mean. Confidentiality means that we want secrets to be secret. If we are exchanging emails, I want only you and me to be able to read those emails. Integrity means that we get what we expect. When you log in to your Instagram account, you want to see all of the posts, all of the followers, all of the following, right? If suddenly you log in and suddenly everything is wiped out, that would be suspicious. Integrity. We get what we expect. Availability means that we can always access the information. You can send me an email right now. You can send me an email in 10 hours, like during the night. It doesn't matter. You always have access to your emailing system and you can send an email. How is it helpful? How is it helpful? Why am I talking about it? This is helpful because instead of approaching the ocean, when you're thinking about your security, instead of being confused and looking, oh, should I make sure that this vulnerability is fixed so we don't introduce this vulnerability or that vulnerability? Instead of that, instead of looking at security as an ocean, you can use the question. The question which is, how can the CAI of this thing be broken? Now, I would like you to think, but the project you are working on right now, and you got it, you can ask the CIA question for it, how can the CAI of the project you're working on be broken? And it changes completely the way you can approach security. Because instead of being like, oh my God, I don't know what to think about you look at the thing that you're building and based on your building on what you're building, you're asking the question, it is amazing because it will work for you. Whatever technology you use, whether you're front end, back end, cloud, no cloud, whether you're, I don't know, junior me, senior staff director, product manager, designer. You can always ask this question. And of course, based on what you are working on, it won't be just one question. You will ask questions for each of the categories for confidentiality, integrity and availability. For confidentiality, you can ask, who can see this resource? This is the most basic question. How do we store credentials? Do we use default credentials or credentials? Easy to guess. What do we stored in the logs? Integrity? Who can create, update and delete a resource? Is there any way that a malicious actor sends us malicious code or malicious data? Via form. Like what happens then? Is there any way to see a malicious actor just deleting all the resources of our customer? Is there a way to prevent that availability? Of course, the most obvious question is like is this endpoint rate limited? But also as developers, we introduce so many dependencies between our systems. So what happens when a product that we rely on is down? Does it mean that the whole product is down or some capabilities are limited? Asking CI questions will help you design with security in mind. And the question is when should you do it? Like you know what to do, you know that you should ask the question, but when should you do it? I cannot tell you about it without telling you about shifting security left. Shifting security left is this new approach to security when we look at the SDL fee. So software development lifecycle, it is lifecycle if it's a circle of life. But here's the problem. I don't know about you, but from my decade experience of developing software, this is never a cycle. But from my experience, usually software development timeline happens. So instead of going around, going round, you just go analyze, design, develop, test, maintain, release, basically, and you move on to a next project. So shifting security left looks at it and says, well look, remember the story I told you at the beginning, like when we had security review in the last, basically last sprint of the project, shifting security left is like, no, we ain't going to do it. This is not a good approach. Let's shift security left, which means let's shift security to the basically design phase. And why is it very powerful? Because when you have code, when you already have design in place, every change will be very expensive, every change will be time consuming, every change will be stressful. But if you design, if you only have some sketches, then changing your system is very easy because you just need to move some lines. So shifting security left and designing with security in mind and for security will help you immensely to build better software and to prevent you from much more stress and costs. And here's the thing, how do you implement the CI Triad in your organization? So first of all, present it to your peers. You can send them this presentation. You can just email me if you want. I can tell your company about it. It's not a problem. I would love to help, I would love more people to use it because it's so easy yet super powerful. You discuss it with your team, you see how can you fit in the CIA triad and those questions in the design phase. And you make it a part of your process, make it a part of your process and make it visible. Which means, for example, you look at templates of, I don't know, the documentation that you need to write for each project. Maybe it's a solution. Brief enhancement proposal, request for comments and you add security section there. Exactly that. Like how the CIA of this can be broken. This is the question. You can add more if you're nice, but basically you inject security into your product development process and that's basically it. And it will help you develop better solutions for your customers. And look, there is no week when we don't hear about a new breach, about new security vulnerability. We are in this moment, in this magical moment in history when we as an industry need to agree that the time of move fast and break things is over and we held too much responsibility and our products influence lives of so many people that we need to take responsibility and we need to create better, more secure software and using the CIA triad. Any tips that I share with you today is the right good step. Enjoy the rest of the conference. Thank you for listening to me and I hope this presentation was helpful. If you have any comments or questions, please reach out to me on LinkedIn. Thank you.