 Hi and welcome. This talk is let's not play dice, what scuba diving and IT security have in common. And I would like to start with a little introduction about myself and the motivation for this talk. The name is Katzenfrundt and about ten years ago I found someone actually paying me for doing IT security for them. In this ten years I worked in application security, I worked for pen testing, I did architecture security, I ended up doing embedded devices security. And during that same time period, that's what the slide is so split-screen like, I also did a lot of scuba diving, ended up being a dive master, did quite a bit of reg diving, tried kevin diving and ice diving earlier this year. And after a while I noticed that some strategies that you find in the field of IT security you also apply in scuba diving and some of the scuba diving ideas nicely work together for IT security if you adjust them a slight bit. And for this talk I would like to share with you some of these ideas and maybe you gain one or the other nice idea yourself for future use. Hi. So let's jump in. Don't be surprised I will structure this as most projects work, so you meet your teammates, you hopefully plan what you are about to do, you do your tool set up, you discuss your configurations, you do your implementation, your change request, your patch, whatever your current situation is about, and you have some kind of closure where you might or might not reflect on what went good and where you would like to handle things differently in the future. This is exactly the same way that your dive works. You meet your group of divers for the day, you meet your body team, you do a briefing where you discuss what are we about to do on this particular spot, what would we like to see, what's everyone's experience, what's the weather conditions and what not. You assemble your gear, you hopefully have a very nice dive and then you get out of the water, you do what is called a debriefing and discuss what you have seen if everything went normal, what should be changed next time, and maybe you jump right in because the only thing that matters after one dive is the next. So let's start with team forming. The important aspect here is that you understand the experience of your team, that you establish a common language, you speak about the same things, and you basically are able to understand what your teammates are trying to tell you. Experience to a high extent is based on what kind of tools can you use, think about what network scanner you feel comfortable applying, what kind of programming languages everyone's preferred uses, what kind of scripting you like, have you done something that is similar maybe for a different client, but more or less the same project or similar migration, have you done a dive at the same spot earlier this year, are you in a continued dive series with ten dives on one single wreck because what you're actually looking at is some giant ferry and with even ten dives you can't cover the whole thing. How many experience does anyone in your group have is another important factor that might be the number of dives but that might also be have you worked with a particular network equipment vendor before and understand how the CLI works. So have a fair understanding of what everyone in your group is good at because it will also help you to understand okay, where can I look for advice and whom in that group can I approach to discuss an idea. The next two parts that should be considered a little bit together, actually the first one is establish a common language. In scuba diving that's more obvious because you have a formal language by the means of hand sign so if someone gives you a thumbs up, on most places of the world you usually mean okay, it's all right, continue going. If you would not give me a thumbs down I would assume okay, this is a boring talk and you would all like it to have, to do something else whereas underwater if someone gives you a thumbs up or a thumbs down it usually means okay, I would like to get to the surface please or I would like to get down. Another very important thing is the definition of done. That's the terminology of a scrum project you might call it differently but at the end what is the important thing is that you have a common understanding is what's the goal, what's the finish. Is it finished once your pet is implemented, is it finished once you have an executable that you can run, are you finished once this has been tested, are you finished once you are out of the water, are you finished once everyone is back at the dive base and you all took apart your gear and had the briefing, just have an idea about that because under that point most people will have certain expectations towards your own behavior and also they will react differently to whatever kind of interruptions there are. Last part, units, for vulnerability scanning you might prefer CVSS, you might prefer CWS or DREAD or whatever your metric of choice is, funny thing that I remember is I overheard a conversation once where someone said well we should be quick here to high vulnerability, okay I understood, the guy he was talking to actually interpreted this as well it's high, it's not yet critical, I still have a couple of days to deal with it, so make sure you actually interpret on the same scale. A more obvious example, are you measuring your pressure in bar, are you measuring PSI, unfortunately outside the scientific community most people don't use scientific imperials for everything. And then the example of half the tank, if you have regular equipment this means a hundred bar, if you have more modern equipment or if you come from technical diving it might be a hundred and fifty bar in literally even 200 and it's always the exact same sign to indicate to your fellow divers, hey half tank, but is that a hundred, is that a hundred and fifty, is it 200, measured in time that comes down to I have 30 minutes to go, I have 10 minutes to go, I have two hours to go, so agree on something before you need that sign or you need to have that particular conversation. Okay moving on, let's assume you have a fair understanding about your team and you all start to plan what you're about to do. Something that helps a lot is to gather as much documentation as you can need, you can get on a particular dive site, on the network where you're about to work at, on systems that you need to interact with, on basically everything that can help you to understand what the environment you're about to work at, or to dive at. For penetration testing you will probably call that recon, so you try to gather any particular piece of information you can have on a certain area and on the individuals involved. Do that, take your time, every piece of information you gather here is handy later on. You might use that as a measure to work even if the inventory management is not as properly as you would hope for and you can add some information that is might not clearly written in the official documentation tools just because you took the time and checked the git comments of the previous two of redevelopment teams. For diving, look at the history of AWAC. Was it an ammunition transporter or was it an oil tanker or is it just some rich guy sailing boat that for whatever reasons get down on the political spot? It actually matters because in one thing you can expect there to be things that are, might still explosives. If it's oil, you definitely not want to get in contact with that because if that gets into any piece of your equipment, it might be very bad for your equipment and then ultimately bad for you. And if it's some rich guy sailing, you might think about, okay, where can I get a good view? What is interesting here? And ultimately in that way get a better experience out of it. Speak with a team about similar things that they might have done for another client or the previous 10 change requests on the same network because for some reason they do that job like forever. Has someone been on that dive site? Has someone worked with that particular peers beforehand? Are they familiar with the other individuals involved? Have that conversation and actually understand what they tell you. And if you do not have anything that is remotely similar, it's always worth to take a short look at GitHub or whatever your core trying inventory of choice is just to get an idea on complexity and how someone else actually approached a certain problem. The last important aspect of planning that both of these themes have in common is you do a kind of threat modeling, okay, either by attack trees, by stride, by pastor or whatever your weapon of choice is. You make that formula, you sort of rate that and then you actually discuss, okay, how bad is it? Is it something that we need to avoid on all courses? Is it something that we find a compensating measure for? Is it something that at the end is just a little bit inconvenient but ultimately not much of an issue? As a diver, you like to avoid situations where you're out of air. Ultimately, you usually have a planned beef in case this happens and that's to a very large extent, basically you rely on the fact that your body will not get out of air at the same moment that you do. And regularly, you track your air to avoid that situation, okay? And then consider, is it still bad? Okay, moving on, set up in configuration. Two basic principles here. One thing is your own limits. The other thing is how familiar are you with your tools, your gear, your equipment and the other stuff that you use. Your own limits basically is all the experience that you have gathered on a certain topic. That might be your first dive on 40 meters, that might be that you're for the first time ever working with Postgres or that might be that you just realize, oh, I'm a person who for some reason needs 30 minutes to wake up and to start thinking and to be able to think properly. And then maybe you should not be the engineer on call in your team because that's the guy wake up at 3 o'clock in the night to fix an issue. Be honest about what you can do in these situations and understand where your limits are and where the limits of your team actually are. It says here, can you do math on 30 meters? For most people, interestingly, rather difficult. The other thing is I've heard someone saying recently, oh, I can't do math live. That's okay. You can avoid it. Just pre-calculate it, write it down and have it with you in that situation. Reading is far easier than doing the math to it. Next part, know your tools. For IT security, obviously, what kind of tools are you used for scanning? What kind of tools do you use for version control? What's your programming environment of choice? Familiarize yourself of that. If you need to use that because it's the team standard or because someone else actually recommends it for you or for some reason it's you're using some proprietary piece of software and that's literally the only tool that can do that. Try to familiarize yourself with that in a more controlled environment. That might be a virtual machine that you set up for that particular case. That might be a docker container that you launch. Do some testing. Do a little bit of exploring here and afterwards you just throw it away. That might be that you have never used a compass before and that's okay. But then use it on the surface for the first time, preferably without the thick diving gloves. It's far easier if you realize it upfront and not on the seaside because then you can do it comfortably on your sofa. Found nicer. It also means understand where your tools become unreliable. You can't use everything that exists in the world of scuba diving for ice diving. That's just a more extreme case. Not every network scanner scales very well. Not every database should be used for distributed systems or can do good replications. Understand where the limit is and then choose something that seems appropriate and familiarize yourself of that before you move on. Okay, you will then come to the point where you actually need to do something. You do your implementation. You do your testing. You change your whatnot. And now I would like to speak a little bit about different strategies that are in the field of security and that can be used in both worlds. First part is you need a way to improve availability. An obvious choice here is to make something more or less redundant. You can essentially replicate the exact same machine or the exact same system. You can have something that accepts the same input and generates roughly the same output, but is actually completely different. Both methods are fine and fair. However, in some case, it might be enough to just have something on set by and you manually change to that. Okay, so you just start a different server or you let's actually do the example here. Let's see if we can make that visible for you. These two elements, sorry. These two elements there are actually two different what was called the first stage in diving. So these are the units that reduce the pressure in your tank or cylinder down to something like 10 bars that you could technically use further on. A, these are not physically identical units, so they both have different specifications and B, they do not switch over automatically. So you do not have something that's actually checking is the other device still available and working. You end up doing that manually by just taking something else. That's the other two photos out of your mouth, switch to the other unit, put that in your mouth and continue breathing. That simplicity saves you the necessity to have something that still checks if that other device is still working. So whatever you wouldn't use in security that usually has a heartbeat mechanism of some kind or a watchdog for the other mechanism or some kind of handshake that is continually running. And that feature you can avoid this way because ultimately that feature can fail as well. And you have that introduction of more availability, you can actually have a reduced part of availability due to the synchronization or observation effects. And keep in mind when you have to double certain parts and sometimes you just can't avoid it, you're in that way also need to do more maintenance work, you have more patching, you have tremendously more testing because you need to check and test that one additional feature that does that check is the other device that's here and functional, or is it not? Whereas if you have just manual switch over, you don't need this component and you can save that time. And yeah, choose wisely and just don't try to overshot here. Moving on integrity. In the IT world, you have a tendency to add Bluetooth to pretty much everything, right? You can have toys with Bluetooth, you can have, for some reason, evil greed with Bluetooth, you can have whatever I've seen. Tempest starts with Bluetooth or just some nice drinking bottles with Bluetooth so that they could actually tell you if you have drank enough water on a particular day. We connect more and more, it's okay. And that way we also reuse more and more features because we can just pull certain information on another service that has already implemented that particular information that we are looking for. However, if you take a look in more secure networks, we actually find that there's a tendency to keep that attack surface reduced. Usually that's done by reducing the interfaces and the communication happening from a particular device. There's a security approach, or the IT approach. If you check what is common in diving, you want more interconnection? Okay. You get more interconnection but keep the old one. I've used another example here that's a pressure gauge. These two pictures are actually two things with the same feature. The one is measuring analog, how much air is left, the other one does the same thing digital. And usually if you have the digital unit, you somewhere still have an analog one basically because that transmitter is not wireless so it doesn't need a battery which can fail. It can't for some reason be broken when you jump into the water and it just hit hard on the surface on a bad angle and you find yourself in 40 meters and figure, oh, I just can't do that anymore. Bad luck. No, I just need to hope it's enough air. The diver's approach is to have it doubled. Might work in IT security as well in one or the other case. And important, the comparison usually is manual. It's not that we end up in the idea of having a safe comparison mechanism again. You basically check both your measurements just after one another. Measuring is key to our next part. Monitoring. I've seen a lot of projects where at some point they decided, oh, let's just lock whatever the default is. Then you end up in an incident and you're like, oh, we can't make sense of whatever we're logging or for some reason it's not enough or not what we actually are interested in. So it helps to only decide what you actually are interested in in terms of data. Make sure you have that data and then look at the data once in a not stressful situation and check if you can actually make sense of it. If it's whatever you expected and if you can handle it sufficiently. If you find it's not the case and you are, you know, it's a training situation and you just look back and change that it's fine. If you have an incident and you figure, oh, not the right data, yes, there will be an next one. There always is. But it's not best practice to wait for the next. It honestly doesn't matter how you measure it. If it's a dashboard, if it's a lock fight, if it's a pressure gauge or just your dive computer, check up front if you are able to make sense of whatever you're measuring. Moving on. Exercises. If you practice something, it will help you to become better at it. That works for a lot of things. You can see a lot of examples here. Maybe you'll remember when you first tried to solder, you start with something fairly simple. Most people start soldering with a small grid of just wires. Choose easy examples. If it's your first approach, it makes them a bit harder after a while. This is important because it will help you to remember the steps. It will help you to stay calm if you actually ever need to apply a particular ability. And depending on what you would like to actually practice or how complex it is, choose a good one. A structured work through is something where you usually do not actually perform an action, but you just speak about it. This is very good if you have things that are very, very extreme in the amount of time that you would need or involve a lot of individuals. Of course, you can do Red Team or Blue Team. You can also do your first aid training and I hope you'll do that regularly and not just for driving tests. You can do a rescue diver training and basically everything where you actually do a movement will help you to remember it because your brain has a tendency to better remember things that are connected with some kind of movement in whatever way. Foolish example, most people have a tendency to better remember the movement to type their passwords as compared to the actual password. Okay, let's move on. Stay fit. That helps in the long term because it actually makes sure that you have a broader range of experiences to use from. You have different ideas and sometimes just maybe one or the other plan B that you can pull from someone else's ideas. Typical things. Attend a conference, good choice. Read an RFC, listen to a podcast. Scuba divers usually take stay fit rather literally because you actually need to be able to swim a certain distance. If you're a drift diver, you obviously want to be fit enough to swim against the current for a while. If you can't do that, speak with your team about it, maybe you can just as a body team get up if one of you gets tired and get out of the current escape from this and everyone else stays in that drift dive and you just meet at the surface. That's cool. Just have an idea of where your limits end here and try to have a recent idea. Okay, I was able to do that five years ago is not a good answer. Last step. Closure. When you have done your change request, your implementation, your whatever kind of project or teamwork, take the time and speak about what went nice and what we would like to handle differently. Try to not make it a shitstorm. Actually speak open about what should be different. It doesn't need to be a formal meeting. It's cool if you do that at the coffee machine and everyone has a cup of coffee after 10 minutes, you're done. Just make sure you have that and that everyone had that chance to speak up with their minds, essentially. What I find helpful is actually write that down and take a look at the things that you would like to do differently and how you would like to do them differently with a little bit of time in between like two or three weeks tops. For Auditosa it's just saying if it's written down, it happened. If you write it down, you will make it happen. With that phrase, write it down and look at it later. Now I've spoken a lot about what they have in common. I would also like to point out a small difference here. When you paid attention, you probably noticed that from the classical CIA that there is in IT security, I completely left out the area of confidentiality. And unless you're a military diver, this is something that is completely nonsense if you do scuba diving. You want as many people as possible to know where your dive is and what you plant. You literally deploy a large flag on top of the surface making sure that the captain of this boat realizes oh, there's someone in the water. I shouldn't stop here. When you do night diving or ice diving, you usually have someone else on the surface completely briefed about your dive. When you get in, what's the planned route? When will you get out? A good dive center actually should ask you something like well, how long is your dive? Okay, 45 minutes. And how many minutes after 45 minutes you want me to call an emergency team? Okay, that's kind of grace periods that you usually agree on and yes, they actually do that. Another thing that is rather obvious, yes, we've seen we follow the same steps. However, the time span is completely different. Recreational scuba dive usually is limited to one hour. With breathing and debriefing and assembling of everything you might have two hours tops. A bit more if you are experiencing something new if you make a formal class, okay? But I've yet to find an IT project where the kickoff meeting is two hours or shorter. One last thing that I would like to mention is something I've just noticed when writing the slides. There are a lot more institutions that allow you to gain beginners' knowledge on how to do scuba diving compared to how many institutions there are that allow you to get into the world of IT security and get knowledge here in a particular field. Yes, of course, there are universities. However, they usually require you to have some kind of education beforehand to be enrolled. I personally believe that Cybertty did a great job here to make that situation better for the IT security world. What else is different? Honestly speaking, pretty much everything, but I guess you all figured that by now. Okay, I promise if there ever is a CC3 workshop on how to do decent slides, this one, this slide that can be used as a bad example and I will attend it. With that, I am open for questions or comments. We have a microphone here or I can repeat your question whatever you prefer. Thank you for listening.