Navigating the Security Maze: An Interactive Adventure

Speaker 1 [00:07]

Welcome everybody to this interactive session. You can already get your smartphones out if you want to contribute to the decisions today. This will be interactive, of course. So, my name is Clemens. I was already introduced. I'm your game master today. So, we will go on an adventure through software security today. And you are the audience and you are making the decisions today. So we have a very simple game. You all together play as a team. You make the decisions together via online voting and all the decisions you will make will cost some time and some money. And you have these bars in the down left corner where you can see how much money, how much time you have left for your adventure building secure software now. So have a look at them, and of course, you will not know up front how much a decision will cost, just like in normal life, right? So you will have to guess, and you will have to have a look that you will stay in the budget you got. And all your decisions you're making will have an impact on security, but we will have a look at them later. And, of course, they will change the flow of the game and they will interact with the decisions you will do later. So classic role adventure rules here, I would say. And let's start with the voting. Now you can get your smartphones out. You can scan this QR code or you can enter the URL down below, maize.innovex.io, and now you should get to an empty page, and there you will get the decisions you will do later. The URL will come up later again if you were not fast enough. But first, for the scenario we are playing today. So, you are all working in a company called Maze, modern applications, zero errors, and you have a new product idea. So, after Corona, a lot of companies have empty office spaces, so you have the idea of building a marketplace where companies can offer their offices as co-working spaces, others can book them. And you have an MVP, you want to list these ads, you want to make booking and payment possible. And of course your marketing department already has the campaign ready and they want to start in six weeks. So that's your time budget. In six weeks we have to deliver a functioning MVP. So you together work as software engineers in this project. And you will have to ensure that this MVP will start on time and also will be secure. So that's the scenario you have to deal with today. So let's just try if the voting is working. You should see a decision now on your mobile phones. And you can vote. And let's estimate maybe 60 persons in here. So around this, I will stop the voting. So let's have a look. Okay, some of you are a bit skeptical, but most of you are on. So I like that. So let's start with the actual adventure. So just so you know, we have five phases in our adventure today. for depicting the different phases of a software development cycle. We will not get to operations today because we only have 30 minutes. There's a longer version I can talk about later, but we will focus on the kickoff phase, on design, on implementation, and on testing today. So just that you have an idea what is coming up next. So let's start with kickoff. So in the beginning of the project, everyone is very motivated, and also your manager, and he hands over to you 10,000 euros and says, security is very important for me, here you have some money, let's start something right now. So your decision, your first real decision now is, how do you want to spend this initial 10k? Do you want to buy a day training for the whole team? Do you want to buy some security scanner licenses already you can use later? Or do you want to go on a nice conference in Darmstadt for yourself, have a nice training, build up some knowledge for yourself? What do you want to do with this 10 grand up front? All right. Let's have a look. Okay. Very nice of you. So you think about a whole team and you buy a day training for everyone. on. I like that. So you book a training, for example, at my company, Intervex, and I will give you an overview of different security activities you can do about different tools, how you can code in your language. So in the end, the whole team is a bit exhausted, but they all have a similar level of knowledge, and you can continue with that. So what's my opinion about your decision? I think you made a good decision there. So training for everyone in the beginning is maybe not a bad idea to have a common ground to start off. Of course, the level of the training might be right for everyone, so that might be the risk there. But yeah, buying a tool upfront that you do not know if you need it later is maybe not the best idea. And building up a specialist in the team, like sending someone to a conference, that might work as well. So you have some guy that is really focused on security, but maybe it also goes the wrong way and then you have one guy that should do everything and the others do not care about security at all. So that's the problem with that. All right. So 10 grand spent. Now the invoice is there and your boss is already a bit skeptical. Maybe it's just an MVP. Maybe it's not so important that we build security right now. We do not know if there is even a market. So yeah, he says, let's just focus on MVP security. We can do that later, right? So what do you want to do? Do you want to agree with him and hope the best, or do you want to try to pursue them to continue with security from the beginning? Oh, that was very fast. Let's have a look, okay, a lot of you are motivated, I like that. So let's see how well this works, and of course now this great dice comes into play, so we will have a look. If you roll a five or six now, you succeed with convincing him, if not, we will not. And the first row will be my eyes, and oh, it's only a four, so you failed convincing him, so that's bad. But yeah, don't worry, we will continue anyway. So no, yeah, so he's still a bit skeptical, but with a reduced budget, you are able to continue. Always have a look at the values down there. So what's the background behind this question? I think even for MVP, it's very important to start security from the beginning. It's like every quality goals you have, if you want to fix them later, like regular bugs, It's very, very hard and more expensive the earlier you tackle these problems. It's cheaper. Of course, there are some things you can forget in the MVP first and build in later, but especially some design things, some very important things like authorization. It's very hard to forget them up front and build them in later. So some things might be added, but security should be a first-class citizen in the project from the beginning on. All right, very good. Let's continue with the second phase, designing our actual product. So in the beginning, you sit down together with your team, and they are already collecting some requirements, and you want to discuss with them what should security do in this phase. Do you want to establish some secure coding principles with your team, so some guidelines, some checklists that everyone has to follow during coding later? Do you want to build a secure architecture, so document the whole architecture, the different parts, how they are secured? Or do you want to do a threat modeling session, so thinking about what threats can come up, what an attacker might do, and then get the right countermeasures out of that. What do you want to do? Okay, not so easy, a bit slower, but let's have a look. Oh, okay, interesting. So not so clear results here, but you decided to establish some secure coding principles. So that's a good idea, I would say. So you talk with the team about different security principles like defense and death, a secure default for everything, the principle of least privilege, stuff like that, and you develop a guideline for that and you document it in your wiki and hopefully you will find it later again when you need it. So what's the background behind that? I think all these activities are good activities to start with. Of course, everything will get relevant later, so make sure to just not do these activities for themselves, but to make them in a way that they can be used later again. And the idea of all of them should be to make security present in the team and motivate the team to think about this stuff later. So that was a good decision, I would say. We can continue with that. So one important thing you think about up front is authentication, right? So the users should not be unauthenticated in your application. So you want to register and authenticate the users in some way. But the question is, how do you want to do this? Do you want to build your own authentication solution? So you are all coders, right? So you can code your own login system as well. Do you want to go for open source solutions like KeyClock or stuff like that? So some open source software you run and deploy and run yourselves. Or do you want to solve this problem with money? Have a look at your budget down there and buy some third party authentication provider like Okta or something like that and use that service provider. All right, lots of votes there. Let's have a look. Okay, one person wants to develop it on their own, nice, but most of you are open source guys, I see, very nice, so we go for the open source authentication service. So you pick something like KeyClock, it's a bit tricky to configure it right, and you have to look after it the whole time, but then you have a functioning authentication provider very very good so that's that's a good good solution we have authentication set up now so we can now go into the actual implementation so one very important thing when developing such a web platform for example is always we had this security principle before never trust user input so you need some kind of input validation the things the users enter in in the front end should be somehow validated, or should it? So what do you want to do with it? Do you say, no, we are still in the MVP, we do not need input validation, we can do this later? Do you say, oh, in our front end, we have a nice feature, we can do the input validation there, then the user gets direct feedback, nice, simple, we'll use that, or do you want to do it in the back end on your REST API, do the validation there, or why not both front front-end and back-end, then we have double security. Where do you want to do user input validation? Why not both? We validate in the front-end and in the back-end. Let's have a look at our time budget when we do both. Oh, okay. So why not? It's a bit of an extra work, but maybe it's worth it. What's the background behind that? So the very right answer would be, of course, we do it in the back end. That's where we have to do it. Input validation, that's a quote from Obast, must be implemented on the server side before any data is processed. Of course, we can also do it in the front end. Then it's mainly for usability, because everything in the front end is controlled by the user and therefore also maybe by an attacker. So they can bypass any validation there, but it's easier for the user if they get direct feedback there. So it's nice that you thought about the users there, do it in the front end as well, but that's not for security mainly, but more for usability, that's important. Alright, so implementation is going on and now you also want to think a bit about testing. So, and you do a little web research, and you have a lot of options how you want to do security testing, and you need to select one of them right now to start with. Which type of security tests do you want to perform in your project, and what do you want to choose there? Do you want to use some static code analysis, some sust tool in the pipeline that runs on the code and looks for code lines that look somehow fishy and like a security problem? Do you want to write your own security tests, so you also already have some integration tests and you also write some security tests for them for the misuse cases? Do you want to buy the vulnerability scanner now, a cloud service that checks your application during runtime, or do you want to do a pen test, an entire pen test after each sprint? What do you want to do? How do you want to test for security in your project? All of them. have to select one right now, but it's a good point, yeah. OK, let's wait for one more vote, and let's have a look. OK, oh, it's a close call, but I think the SAS tool got it. OK, yeah, so you voted for a static analysis in the pipeline. And so now every commit, every merge request gets checked in the pipeline. And in the beginning, you get a lot of findings and also some false positives. So you have to go through all of them and sort them and assess them. But you also find some important things. So that was a good decision there to scan your code for security issues. So we already had the comment, why not all of them? And yeah, different types of tests help for finding different kinds of vulnerabilities. That's just a small list of different weaknesses we have in software, and it's definitely not entirely clear what tool can find which category is better or not, but I tried to evaluate somehow. So we have some things that are easier to find in the actual code, for example, cryptographic failures. So we are using some cryptographic algorithms that we should not use anymore. We can find that very good with a SAS tool in the code. Other things like, for example, in injections or misconfiguration of the entire runtime, that's something that a vulnerability scanner that is testing the actual running artifact might find easier. Misuse cases are also very nice because you can write your very own cases. But of course, you will only think about stuff that you already know you have to think about. So these are more regression tests for security then. But in best case, you can combine different kinds of security testing and find different kinds of weaknesses with the different types. And also a big thing in developing software is, of course, the software supply chain security. So all the different libraries, frameworks you're using, You want to make sure that they do not have any issues, some security problems in this library. So how do you want to tackle this? Do you want to check them all manually, go through your package JSON or requirements TXT and check if everything is up to date? Do you want to use a tool like Renovate that checks every night? Is there a new version for this library and opens a merge request for you and you just have to merge them if you have a good test coverage? Or do you want to use a tool like OVASC dependency track that has a look at the dependencies you have already running and checks if there are security issues for them? So if there's a CVE coming up for a library there, then you can get an alert. So how do you want to handle software supply chain security? here. Okay, 70 votes already and most of you go with the OWASP dependency track, good choice I would say. So, yeah, you configure this dependency track, it collects all the dependencies you have in your project and, yeah, you have to go through all the findings because you You have a lot of transitive decisions there as well, but then you find all the problems, and then you have to check if there's actually an update. And that's the big difference between Renovate and DependencyTrack. With the one tool, you can see if there's a new version of your library and you want to update. With the other tool, you can see if there's a vulnerability, but maybe there's not a fix. So that's the difference between looking for fixes, for patches, for updates, and looking for vulnerabilities. Both are important when talking about software supply chain security. So that's the thing there. And also, Renovate is a good idea, keeping your dependencies up to date. But you have also to make sure that you are not too fast and introduce some new weaknesses in new updates that maybe were not found before. So that's the trade-off there. But definitely you were right not to check this manually, but to automate it in some way so you can handle more important stuff. Very nice. So in the end, we want to do a pen test, of course, and now we are ready to launch our software and we want to do a last evaluation of the security. So you do an external pen test. So you have two very good decisions you made up front, the one day of training was very nice and making the coding principles was a very good idea. So I will subtract one point for these two decisions you made. So we will roll the dice again and, oh, lucky, we have a two and we subtract two. So I do not have a zero, so we go for one. But yeah, that was a very, very lucky outcome, and you made some good decisions. So the pen test we made did not find any critical vulnerabilities. Of course, there are some small findings, but in total, they praised your defense and death measures, and it's a very good success here at the pen test. And now we can go live. You did it! You managed to have a lot of money left, so we have a big release party with that, I hope, because you went for open source in a lot of decisions, so that was nice, and we are also still in time, so that's nice, the product can launch, everyone is happy. But then, oh no, in the night there are some suspicious activities on your system, And yeah, you will have a look at the logs. But thanks to your secure coding principles, everything was secured very well. So the attacker can hopefully, let's, yes, we managed to drive away the attacker. So yeah, he was able to break in some systems, but you fix it and you can lock them out. So all two customers you already have on your platform can be informed, but now everything is hopefully secure and you can continue with your product and the launch of your software. Congratulations, you did it. You successfully managed to navigate through the maze. So this was a very short version of the maze and of different things you have to think about when developing a software, but, yeah, let's have a look. Oh, you made a second place in our perfect rating score, but, so, yeah, you made some very good decisions, so congratulations on that. Everyone that was in this room can now get a sticker. I made it through the Interweb security maze, so come back later here and collect your sticker if you like. Also, this was just the short version because I only had 30 minutes. So if you are interested in the long version, maybe for your team or for another opportunity, just talk to me. I also have some flyers there. I'm happy to play the full maze with you again. And then you can also see how different decisions may lead to different paths. So that's also very interesting for me every time. Of course, we also do trainings. Of course, we also help you developing secure software development processes, so that's also something I love to talk about. But that's it for today from me, and thank you very much, and congratulations again.

Speaker 2 [24:35]

Thank you. Thank you, mr. Clemens. Congratulations, everyone, for your live product. We have a couple of questions to ask you in our q and a session. First of all, what are your thoughts in terms of security on Github dependable?

Speaker 1 [24:52]

Dependabot is quite similar to Renovate, so they also open up some merge requests if there are updates for your dependencies. So I think that's in general a good idea to keep your dependencies up to date and introduce fixes as early as you can. So then if something really important comes up, you do not have to jump up three major versions because you are lagging lagging behind that much but you also have this problem you do not want to be that fast maybe and want to give others the opportunity to find some weaknesses some bugs in there up front so that's the the trade-off i talked about but yeah In general, it's a good idea and a good way to automate this.

Speaker 2 [25:41]

Thank you. We have a second question. Have you any experience with the packages safety and bandit?

Speaker 1 [25:49]

Say again?

Speaker 2 [25:51]

Do you have any experience with the packages safety?

Speaker 1 [25:54]

Ah, okay, no, I'm afraid I do not know them, but yeah, come to me later and tell me what they do, and I'm, sorry, okay, for what, okay, okay, yeah, so then it helps you find, but I do not have experiences on how good they are, sorry, yeah.

Speaker 2 [26:15]

The next question, could you explain your motivation for Using postgres sql?

Speaker 1 [26:23]

Did we use PostgreSQL somewhere? I like PostgreSQL, I worked with it, but I would not see the need to do it in our MVP here. So that would be your decision then.

Speaker 2 [26:39]

So, a funny question, how did you do this presentation basically?

Speaker 1 [26:44]

So, this is based on Reveal.js, you may know, a tool where you can write presentations in HTML, more or less, and JavaScript, and we pimped it a bit with React so we can have a state and make all these decisions and go back to them later, yeah, and the motivation was to make the software security somehow explainable and experienceable. And that's why we built this.

Speaker 2 [27:17]

We still have four minutes. So if you have any other questions, please submit them in the slido. But in the meantime, thank you so much, Mr. Clemens, for this amazing presentation and for bringing us with you in this journey in maze. And yeah, I don't see any more questions. So thank you very much, Mr. Clemens. Another round of applause.