 Hola a todo al mundo. I am Lewis Denham Parry from Control Plane and I'm going to give a light speed introduction to threat modelling cubitettis. As I say, you may know me as the head of training at Control Plane. However, the fact that this is a light speed talk is going to be very beneficial because I'm going to pitch to you all my crazy amazing new idea for an adventuring cloud native today which is called, very imaginatively, Control Flame. What is this well thought out, well considered idea I hear you say? Control Flame is all based on the fact that I run Capture the Flags for a Living. I love running Capture the Flags at Cubecom for wonderful people like yourself. However, what this means is I've become very good at breaking clusters and I've forgotten everything I used to know about fixing them. So Control Flame is my wonderful idea where I will go all over the world. Lewis? What are you doing? I didn't think you'd be here. I wasn't, I just woke up somewhere and I didn't have my lanyard. I don't know what's really happening right now. This one? Why are you speaking? Why are you talking about Control Flame? I'm pitching. You're pitching? Yeah. How did we get to this spot? I'm so glad you asked. I thought you never would. So, remember dinner last night? Not really. You see this dastardly character at the back? You were a bit suspicious yesterday. He was the man who handed you a eighth glass of wine. And the first to the seventh as well. And the first seventh. That probably explains the ditch, yeah. Well this was the start of the night. This was the end of the night. Okay, so that's our first fright model. We can't really trust you. Yes, but thank you, James. So, first of all, we want to talk about identity in that some of you might not have known who I am. Hi, I'm Lewis Denham Parry. First of all, thank you to James Kalligan. Actually, for the remainder of his talk, I will be James Kalligan. So James is a security architect at Control Flame. He helped create this workshop. This initially was a workshop that we deliver on threat modelling. Hi everyone, I'm Vareal Lewis. I don't know how to prove it to you right now, but I am the head of training at Control Flame. So when I take a stage, I like to take the opportunity to talk about mental health. I'll just say this for a moment. I do suffer from depression and I know I'm not the only one who does. At times this conference has felt overwhelming. The last couple of years having virtual conferences have had their own problems. Being in a room filled with people, seeing so many people all at once. It's been overwhelming, but it's been so good to see familiar faces from days gone by, but equally making some new ones as well. Making some new faces, some new friendly faces. But to the point of depression, if you do suffer from it, you're not alone. My DMs are always open, but equally, I'm sure there are so many people around you who think you're awesome. And equally, I think this is now going to be called the cube con where everyone found out how tall we are. So, like the last few years, I did not know many of my colleagues and their height. Now, the other caveat to this talk is that it's always learning. I am forever learning and I'm happy with that. The terms that I'm using today are the terms that I know of. And equally to the open source maintenance that we have in this room, if we're talking about technologies, I absolutely appreciate the time and effort that you've put into writing, maintaining and contributing to open source. So, if anything is derogative towards anything of it, it is not that. I'm just talking from an attacking perspective. And equally saying attacking. Sometimes when given talks, some people find that too aggressive. I'm still trying to figure out right terminologies and so forth. But if I do offend you in any way, please just give me a shout out. Just drop me a message and yes, I will continue to learn. But to that, we're here to talk about threat modelling. So, what is threat modelling? Threat modelling is identifying, enumerating threats and vulnerabilities. It's devising mitigations and it's prioritising residual risks. And we want to escalate the most important things. So, you should try to build the first version of a threat model without any outsider influence. Then you can pull in external resources to cross-check the group's thinking. Threat modelling can be performed at any stage of the project, but to quote the Smith's, how soon is now? The sooner that you get it started, the better. And this isn't a shift somewhere from a security team to someone else. This, for me, is about being a decent human being and respecting other people's information and lives. And we'll talk more about that during this talk. To that point, this allows us to have diversity, which I hope I've spelt correctly at this moment in time. Threat modelling should bring everyone together. Everyone's got a voice and everyone should be heard. Race, gender, age, all the shapes and sizes, everyone should be at the table for this. Within your organisation, it should be development, it should be operations, QA, product, business stakeholders, security. Equally, if you're in your own building, talk to the security guards, talk to the people who are cooking the food. Like, have you ever thought about what might happen if someone poisons a whole staff? Now, did anyone here take part in the CTF over Monday and Tuesday? If you could raise a hand, I can see a couple. I recognise some familiar faces. Thank you ever so much for joining. Thank you for the feedback. It's been... That was almost a swear word. I hope that's not a swear word in Spanish. Now, I don't think I can remember saying this, and I don't really know where it came from, but my point is that I felt comfortable to share this. So, you are stupid if you assume I'll remember you asking what you think is a stupid question. I remember the first time I went into a threat model, I felt like I was asking the most stupid questions. But, like I said, if your voice is not being heard, then that's just a stupid assumption. Equally, back to mental health right here, so Ian is in the room today. Ian, Smarticus and Moet as well, so Skybound, they both did super awesome at the CTFs and speaking to them, like, I don't think much of myself. I see the best in everyone else, and I've learned that if the people that I look up to and respect me, then that's something I should be proud of. So, thank you to Ian for doing this tweet. It gives me the motivation to stand up on stage today. So, we're going to be going through these four steps right this talk. We are going to talk about what we are building. We're going to talk about what can go wrong once it's built. What are we going to do about the things that can go wrong, and are we doing a good job? It'd be good if I could pronounce it good the first time round. Are we doing a good job of analysis? If you came to KubeCon and I have to present this talk, then I have to run back to the office next week. Sorry, what I'm trying to say here is, if you've come to KubeCon and work has said you need to present something when you come back from KubeCon because we sent you all this way, why not do a threat model? Why not do a brown bag session at lunch and bring a team around and try to figure out the risks that you might have on your projects? That's what I'm hoping to do today with this talk, is to put you into a position where you feel comfortable to be able to do that. So, what are we building? Here today, I've got an assumption here that you already have an understanding of Kubernetes and we're going to be focusing more about the threat modelling here. So, we're going to learn more about threat modelling during this talk. If you do have questions, then please come at the end and we can discuss them. Also, I'll be here all day tomorrow and all day tonight and I'll be here tomorrow and I'm more than happy to talk with you. Documenting your system, your business is not my business. You might be a large, multi-scale corporation that's existed since what I think of as the dawn of time. Equally, you might just be a start-up and you might have just met your co-founder five minutes coming down on the escalator outside, coming into this talk. Not all businesses are the same shape and size, so the threats are going to be different. So, what type of damage can be inflicted? Well, when we get attacked, there might be reputational damage and there might be financial loss. Now, threats represent potential ways that information assets can be attacked. So, let's use information in an information asset. So, is anyone in this room willing to shout out their credit card number to me now? Does anyone? So quiet. So, I don't think anyone wants to shout out their credit card information because it's going to be transmitted, the network across here, everyone's going to hear that credit card and it's going to be there. So, on the note on my phone, and the storage of that isn't ideal because it's just going to be in plain text. So, we've got issues there about confidentiality. So, we've got the CVV, the CVV digits of the credit card. We need that to stay confidential. Now, we also have integrity. So, integrity is about if someone goes to make a payment and I'm trying to say I'm going to pay James for coming up on stage and I'm going to give him five euro. Now, Andy, the CEO of Control Plane, he's still trying to get more money out. I realise that this money is going to go to his account. So, the integrity varies, is that I think I'm paying James for actually going elsewhere. And finally, we have availability. So, availability has been able to have a service available to me to be able to process this transaction. So, there should be a scheme in place for how important the information is. So, how much money can you lose as an organisation? So, as an organisation, if you're a startup and you're literally counting your pennies, like you put all in to come to KubeCon and keep going for the next year, then maybe you're not too concerned. If it's a free service that you're offering people, then it's probably like, well, you only live once, we've got to get through to next day. Whereas, if you're a multinational company, you might be willing to lose money. It might be a lot cheaper for you just to lose money than it is to pay for a new team to fix an issue. But let's also, instead of talking about money for a second, let's talk about customer data. If it is a free service, then you might be willing to say that, well, I'm losing all this data because it's a free service at the end of the day and I'm just going to burn down this company. But if you're a company that's dealing with people's life savings and then you lose someone's information or it becomes available online, then the integrity of your business just disappears straight away and then all of a sudden that's going to be a huge cost to you. But away from those two points, there's also something else. There's a loss of life at risk here. So, we've all got personal secrets and depending on where you live, then it might be personal for a reason. It might be that the political system or for religious beliefs, you can't share some of this information. But you might have reached out to someone online to be able to talk to them and feel part of the community. If that information gets out, what might happen to that person? Equally, if you've got personal identifiable information, as we've seen with Strava Graffs previously and so forth, you might be able to identify where people are, where people live, and so forth. So, I hope I have your attention when I say to you how important it is that we deal with data and how, if someone trusts us with their data, that we look after it. Now, we've got an adversary matrix here. So, these are the people who might potentially, or the actors, that might potentially look at attacking your system. So, we start off at the top on the left with a script kitty. So, anyone in this room when they're at school, did they ever try to play Quake or Doom on their school network? Okay, there we go. That always gets their hands up. So, these are people who watch YouTube videos and try to figure out how to hack. And their motivation might just be, they're just trying to see what's happening. They're just trying to learn. They might also then grow into a motivated individual. So, this could be someone who's got a competing startup to you and they want to inflict damage on your business. It could be someone that you've annoyed because you didn't recognise them first time around at the conference or they just plain don't like you. Now, to that, I would like to introduce you to Freddie. Freddie is the nicest person I know. He is phenomenal. And if you give him a follow, those two things, they do so well online. And they do this on capture of flag events. You'll see them hacking away on YouTube and so forth. Follow Freddie and then you're going to learn more about the techniques that those people might use. So, from there, we're going to look towards insiders. So, this is someone inside your organisation. So, instead of having someone who's outside of your organisation and frustrated with you, they've somehow found their way inside. So, this could be a disgruntled employee. They might have just seen a spreadsheet with people's salaries and then they've seen that they're owning, say, 40% less than everyone else. And they want to take out on the business. Now, we'll come back to this in a little bit again, but then that also leads on to organised crime. So, in organised crime, you can think of this as a business because they're just trying to exfiltrate money. And they are going to go for key individuals. So, this comes back to Covid. For the last two years, we've been sharing lots of personal information online. And depending on our threat model, how open we've been about it, but it's a way for us to find our communities again when we've been locked away from each other. Can these opportunities allow people to identify people that might be in an organisation that they can look to leverage? And right now at this moment, you might think to yourself, I'm so happy in my job. I've got the perfect job in the world, and everything is rosy. But what happens when, say, a family member gets a medical bill and they can't cover it, and they come to you asking, and there's this huge bill, and then you've got to find that money overnight? If someone comes waving this money towards you just to give them some credentials, some access to this, something as simple as that, would you be willing to give them access to that? And could that be someone else next to you? And again, I know this sounds like far fetched, but I was trying to figure out just a moment ago. I think I've lived through two or three recessions now, possibly four soon. I've lived through a pandemic, I've lived through a volcano erupting that blocked air travel, and I've lived through a laster city winning the premiership. Tell me that ten years ago, and I would have just said no way, but that's where we are. Now, to get some user involvement, I've devised some games today. So the first game I've got is called The Apprentice. So prior to you all coming in today, underneath the seats, I've put two post-it notes. So someone's got a post-it note, with game 0-0 written on it. So if you look underneath your seats, and I'm hoping you're sat on one of the seats that has a post-it note, we've got one over there. So would you mind just reading what's on your post-it note? Yep, so just for the people who might be watching online, just to make sure I get it right, you're a C-level exec, someone's emailed you your password, and they've said that they've got a webcam video of you from your laptop. So all of a sudden, you're probably now thinking, well, I don't want that video to be online, so someone's got leverage over you at this moment in time. So that's an example of what can happen in an organisation. Think of LinkedIn. As an attacker, I can just search for C-level execs of these business. I can look into a company's documents, I can see how much you're trading. At this point, not everyone's techie. Educate your team. I think we've all seen those emails before that show us that password. We're all here probably nodding saying, well, yes, I know about Have I Been Pwned. I know straight away that that was from a data breach from someone a while ago. But if you're a C-level exec, you don't. And equally, they're targeting the emotions there. So again, educate your staff, make sure that they're aware of this and look towards password managers as well. So to go back to this, we've talked about cloud service insider. So we're building up on dependencies now as well. So when we looked inside our organisation and the people around us, what about the people that we're dependent on? So you're running Kubernetes. I'm presuming that a lot of you are running stuff in a cloud. The cloud is real. So even though we talk about it being rented to compute, you can go and touch a compute somewhere in this world and that's where your workloads are running. Do you trust an individual who's got access to that? Is your organisation a bank where you need to know that someone can't touch that server unless they've got certain clearance? And the reason why we need to do that is for the next one. So I don't think you need to do the scan, but there was another post-it note in this room. And so if you had the other post-it note, would you mind standing up? Cool. We've got one over here. So would you mind just sharing what yours says? It's a pleasure to meet you. So they just mentioned that they work, sorry, they are part of a government agency with unlimited funds towards offensive security. Oh, this was part of the game, sorry. Who's sat next to me anyway? So that government could even create a new identity for you. So when you go to get your job, when they go to get the job, they could create a brand new identity. They can make that person look as they want to. And with the unlimited funds that they have there, then it's all of a sudden a different kind of thread. So here's an example of a section of a data flow diagram that we used in our full workshop. A data flow diagram should describe a complete set of data. It should show our trust boundaries. It should show all user roles. All network interfaces. And we should make this self-contained. And the most important thing out of all those things is that we make it accurate. If it's not accurate, then it's worthless. To make us easier for others to consume and contribute towards, we can have a high-level overview. Again, we want to bring as many people as possible to this. And remember, we can then delve deeper into this. We can deeper levels going into further abstractions. But at this point, just remember to drop the ladders. An assumption that you make because it's something that you've done for the last five years, the junior, or someone else, or whoever it may be, and it doesn't even have to be a junior. Someone who's coming on who doesn't have that knowledge that you do, they need to be able to pick this up and understand what's happening. So this is an example of the CNCF, the Financial Services User Group, the Kubernetes data flow diagram. So we've identified state flow and the black lines in this. The black arrows are crossing machine segregation between nodes as seen with the green boundaries. There's a lot of information here, but if you want to learn more about it, then we've got access to the CNCF repo there. So how can I take a look for an entry point? Publicly available information is the easiest route in. So Rory is someone again who I have the utmost respect for in the industry and I look towards for this. And so they've got a fantastic blog post about finding publicly accessible clusters. And you might think to yourself, well, I've been running clusters for so long now, why would someone make it publicly accessible? Well, from the keynotes, we've heard about how many new people are still coming into Kubernetes. This is day one for Kubernetes. Someone's starting their journey again and I can attest that I learned by making mistakes. So other people will potentially be making these mistakes. And this is why we need a threat model. We need a threat model that is available. So what can go wrong? And with the alignment of this header, we can see a great example of things that can go wrong. This is where your experience is required. Has anyone ever heard of a term secret source that is used with your products? Now, the secret source is something that if it isn't very secret anymore, is that going to cause you issues? We can also use threat intelligent sources such as these to help and guide us. Lots of people have collated information to help us with this. As with everything cloud native, we stand on the shoulders of giants and we really appreciate that. And these techniques give us a starting point. From there, we can use modelling techniques such as stride and attack trees to go into further detail. Now, to give an example, we're going to use the Microsoft threat matrix for Kubernetes. Now, I'm not going to go through each of these, but the highlight that I'd like to make you aware of is the green. The red shows deprecated techniques and the green shows news techniques. The reason I'm saying this is because Kubernetes is constantly evolving. We've seen the four-month release schedule for it. This is ever-changing. If that's evolving, we need to evolve our threat models with it, too. Stride. I can never remember the acronym for stride, but we need stride for process, for data flow, for store and for actor. We need to identify what might go wrong. So, with stride, stride spoofing, pretending to be something or someone who you're not. James did this perfectly at the start of his talk by pretending to be me. Tampering. Back to the banking example. When we talked about I was trying to pay James five euros, Andy took that request. He modified it so that Andy paid five euros. That's tampering in action. Repudiation. So, this is when we just assume business is happening as usual. If Andy did that in transit, then I would not necessarily be aware that Andy has changed the bank account. I'm assuming I've paid James. So, if James hasn't been paid, how do I know that Andy's taking the money? And equally, if I say to Andy, Andy, you took my five euros. How can he say no? No, I haven't. How can I prove it? Oh, hey, Andy. Right. So, we've got I for information disclosure. This is exposing information of people who aren't authorized to see it. So, this was the example of a credit card, CVV information. No one's willing in this room to give me their credit card number. So, I think you need to trust that if you're taking anyone's credit card number, I think you should treat them the same. So, D for denial of service. At this point, it feels like I'm probably D-dossing you with the amount of information I'm giving you. But if you've got a publicly accessible API, then someone could D-dust that account and take your, say, the API offline. So, then the administrator of a cluster can no longer manage their workloads. Then we've got elevation of privilege. And James again did this perfectly. He went from having a speaker lanyard to having a, sorry, a sponsor lanyard to a speaker lanyard. And then he was able to get up on stage and tell you what he wanted to say. So, we build from Strider and we visualize with attack trees. This helps to identify risks to our resources and the likelihood of them happening. We don't want to have too much information in this instance. So, please focus on the quality and not the quantity at this stage. And be confident to deliver concise documentation. Now, in this example, we use a delivery person who has taken a sensitive document from building A to building B to be stored in a locker. So, to compare this to Kubernetes, people would be equal to our workloads, our roads is equal to networking, buildings would be equal to storage, and our security guards are equal to the control plane. So, you can see from the color coding here at the top, our top node is an or node. And we also have an and node. So, for the example of that, the blue and node reads steel from locker. So, the and node means that the two children nodes of the and node need to be accomplished to be able to access. So, this needs to be both the child nodes, so the key to the locker and entry to the building. Now, Kelly Shortridge has shown us how to use GraphViz to build attack trees. Deciduous is another option available to code an attack tree, and we have also created an example available in our Git repo listed here. These slides will be available afterwards. So, let's have a look at what can go wrong within Kubernetes. So, this is our game, Game Zero Two, Wheel of Misfortune. So, I've kindly asked James Manly if he would mind playing Wheel of Misfortune. So, James, have you ever played Wheel of Misfortune before, or Misfortune? You have not. So, could you give me a letter, please? There is no V. Could you give me another letter, please? That is not V. OK, so we've got R. We've got A. I think it's the point. Can anyone guess what could go wrong with Kubernetes here? Does anyone have a clue? Pardon? R back. Yeah, R back. So, this was a great idea that happened a couple of hours ago, and we invested a lot of time and effort into getting to this stage. If you've ever tried to create this, oh, jeez. So, we had to make a quick decision. Do we continue with this, or do we scrap it? So, we fixed it, and we've added a configuration onto it. So, what can go wrong with Kubernetes? Well, we've got workloads. So, this is our pods. We could have a rice within there. We did the CTF. On Monday, we showed you how to break out of a privileged container. It could be file systems, hostments, hostile containers, run times, pod configuration, pod security context, and service count. Then there's networking. So, we've got intra pod network. So, it's pods communicating with each other. So, we're sewing in a control plane, being able to communicate with someone in a default, and vice versa. Inter pod. So, we've got our own network within the pod. We don't have any workload identity by default, and we don't have network policy by default. So, storage. What about attacking volumes? We have the dangers of hostments again shown in the CTF, and equally, what happens if we have no encryption at rest? So, if we're perceiving where we're storing our state, what happens if SCD isn't encrypted? What happens if our persistent storage isn't encrypted? And then, also with our IAM policies. So, can we pivot to attack on the cloud APIs? Can we pivot to attack the Kubernetes API? And can we exploit app workflows? So, in summary, what can go wrong lots? And this is overwhelming. I understand that. But the most important thing that you can do is just try it. You start with, you pay your best foot forward, and you keep pushing forward. Now, this is only a small subsection of the attack tree, and we can review these attacks to see how they will be scoped. Do our attackers have access to the resources that can enable them, and this is available on the threat modelling labs repo as well. So, what are we going to do about it? Absolutely nothing. We can do absolutely nothing about it, and that's what's going to happen if you're not doing threat modelling, because you're not aware of this. Equally, when you do become aware of it, then you might say, well, we don't need to do anything about it, but it's important to become aware of the risks, and then you determine that with your own threat model. Now, we have all performed our own personal threat model. In Kubernetes, that's not our company name, we're control plane, which is equally difficult when you work with Kubernetes. In our company control plane, we've been discussing about our personal threat model during Covid, because everyone's been affected differently. For whatever reason, we all have to make different choices. We've all decided to come to Valencia and come to this, and there's people who are at home maybe watching this who might have decided not to. Doing all that, you identify the risks and you identify it if it was worth you coming. When we talk about threat modelling, don't think of it as a scary buzzword. Now, we've shared responsibility model equally depending on where we run our Kubernetes cluster. If we are running it in the cloud and we're using a hosted service and they're managing our control plane for us, then maybe we don't have to worry about the control plane. That's being managed, that's being done by someone else to handle. Whereas if you're running your own Kubernetes, then you do need to then consider about managing the security of your control plane. Risk management. In the case of avoid, just think of Marie Kondo and if it doesn't bring you any joy whatsoever, just throw away. Just get rid of it if you want to avoid it. Now, if it is bringing you joy, if you do require to run it, then we can mitigate this, but that means that you need to make it better. You make it better until it brings you to a position of joy. You can accept it, which is just to do nothing. It's meh. And that's fine. This is your risk. This is your decision. Or you can transfer this. So you can just pass it to legal or to your insurers and then you can give them joy in doing whatever it is that they do. Now, we can do things, we can be preventative. So preventative is about shifting our knowledge. Now we talked about shift left. If you've got developers who are just committing some Yamelin or some infrastructure people, we can use tools like CubeSack or OPA. And then with these tools we can then review our workloads as an emission controller. But not just deny, not just to say you can't run this workload. Help educate people at this stage. Help give them a reason as to why they shouldn't be doing this. Because if they can understand why they shouldn't be doing it, then that gives you growth within your business. So we can be a detective, so we can export and monitor logs. So tools like CubeSack are great at doing this. Corrective, so if we can have a corrective approach. So this could just be a big red button on your desk. If something doesn't feel right, if you want to cut everything out, you can literally just pull the plug out of it and hit this button. That gives you the confidence to do it. And this is a shite at old school as well. Now, in training with Kubernetes, I see there's lots of patterns that get repeated over and over again. But equally I see patterns that die off and are no longer available. So ensure that you base your decisions on the technologies and the concepts that we still use today. Don't necessarily use the old ones instead. Kubernetes and Cloud I am is at the centre of cloud native security. So review your permissions regularly. User management processes are key. So review onboarding, offboarding processes. So joiners, movers and levers or JML. Implement strong access controls and policies. Default Kubernetes service counts should not be used. Create a dedicated service account for every workload is your workload identity. And workloads will interact with Kubernetes API or the cloud via workload identity integration. Cloud provider services can help. So I am roles for service counts in AWS or workload identity in GKE. The IRSA uses service account token volume projections and this is one benefit of using a managed offering. For cryptographically strong workload identity spire can be used and spire is a production ready implementation of Spiffy's APIs. So look towards the least privileged parts. Always look at least privilege. Make sure that you can't run things that you don't want to be able to in within your parts. Review what the workloads are when they are being submitted and use IDS to report suspicious behaviour where possible. And use automated security testing within your pipelines. So I don't know if anyone else has spoken about supply chain yet. To save a bit of time, this is my hot take. I would employ at 6 store if there is Luke Hines. I have had the pleasure of chatting to Luke. He is such a good person and I am so excited to see what happens next and what the future holds with 6 store and I am sure it is going to be awesome. Equally to that there is Jed and Adrian at ChainGuard and I am expecting to see amazing things there as well for sure. So please look towards those talks around this conference. In regard to networking go chat to Nathalia Isovalent. We have been working together on the CTF and the tools that they are open sourcing this week are phenomenal and really exciting to look at. But with this as well on day 1 look towards network policies and such make sure that only things can communicate to each other that you want to be able to communicate to each other. So manage your secrets with whatever works for you. Don't just go for a big name just whatever you feel comfortable with whatever is right for you make sure it is just implemented correctly. Use a mission control to have context as to what is being shared and no one should be able to read what is in my volume and no one should be able to get out what is in my volume. So we have controls for the security requirements. I am giving this talk-out moment and you are living in real life. Everything that I am probably saying is you might just say to you well as great you are on stage just talking about this I understand. But make decisions which sometimes we don't understand ourselves and we have to work with that. But again like I said we are all human beings we just need to do the best job that we can with what we are given. Prioritise a risk and do what you can do. So did we do a good job? I have heard this possibly several times in my career now that I have done a good job but it is important to make sure that we are confident that we have achieved what we have set out to do. And look towards other people as well to help you identify this. We need to work as well as looking forward. Have we achieved what we have set out to do? Look to others for their reviews. Is there something that you have missed out? There is testing, testing and testing and we will talk about testing with security in a moment. And as time moves on our acceptable level may change. So what I mean by that is document the decisions that you make today. The decisions that you make today is with the information that you have available to you right now. If someone reviews that in a week's time then the information that they are using to make that decision is different. So if you document exactly the reasons why you have done this it gives a fighting chance in the future to understand why we have implemented things. Select security controls for implementation. So map these controls to our attack trees. So when we have identified in our attack tree a possible route then we look up controls that can mitigate this for us. This provides us a direct means of evaluating our effectiveness. Visual representations are easier to reason about. So identify how many nodes and branches of the attack tree are covered by mitigating these controls. This assesses the result in security of a system. So enough security controls are defined. Any new attacks added to the tree should be mitigated by existing controls. So if you look within the Git repo that we have you'll find an example of us using GOS to test out a security requirement of a cluster. So in this we did a demonstration of a pod security policy. And so as we changed the vision of our security cluster and pod security policies are no longer in place our control is no longer there for our security requirement. So our test fails when we upgrade our cluster. But that's great for us because that tells us that our security requirement is no longer controlled. When we have a failed test we know we need to review that. It equally allows your team to deliver and contribute code with confidence. So I got this far into the talk without talking about Wales. I'm very proud of where I've come from and I feel you should be proud of where you've come from too. When I grew up I couldn't really identify with anyone and I didn't know where I was going in my life. So being able to be a bit like confident in myself I try to leave a way forward so that others can follow if they so wish. Now we also have castles in Wales. Now castles are the OGs of threat modelling in my mind. If you ever feel like you have to walk around a castle just think of all the ideas that they had to prevent people from attacking. But at this point I thought there was a song by a Welsh band which is a good way to leave this talk. So there's a band called The Stereophonics with a song called A Thousand Trees with a link to it there. But I changed it to it only takes one project to identify a thousand threats and it only takes one threat to burn a thousand projects. And finally just remember your own voice. I've been trying to say today that your voice is so important that you share and you share these ideas that you have. Today or this morning there's a Twitter threat so has anyone had issues with taxis in Valencia? Has anyone been in a taxi in Valencia? Okay has anyone been in a taxi on a roundabout in Valencia? Like... Exactly. So it's a bit worrying. But I mentioned on the first day I got here I just started talking to my taxi driver and I became friends with my taxi driver and we shared numbers and so every morning at 8am my taxi driver and I... he picks me up and I'm getting as much swag for his children. We had a face time with my daughter on a way in this morning. It was probably too much information. But to that, Rory, who I mentioned earlier on, who I absolutely I looked towards Rory replied with, now that is good thinking. So that's an example today where something that I just thought was so obvious to do is for other people you might not necessarily see. So I hope you can leave here feeling that we can all contribute and please feel free to empower others around you as well. So to that I thank you for your time. Enjoy your cube con and enjoy the party.