 Okay, so this is going to be less on the technical side though if anyone wants to cover some of the technical stuff please hit me up afterwards I'm more than happy to jump in. And what we're going to cover is how to engage so a your InfoSec team as an engineer as a developer how do we really engage them and help move the organization towards a towards a zero trust environment. And the reason why I'm focusing on you as engineers is that I think the source of a zero trust strategy has to have a very strong component of application developers being part of that like it's not something that you can just say oh I'm going to go buy a product we're zero trust now or we're going to create some definitions in InfoSec and configure some firewall rules and now we're zero trust. So this is something that really requires a fundamental shift in some of the controls that exist within the application or that the application itself is designed so that it can make use of some of those some of those controls. And in order to properly engage with InfoSec it also helps to understand who they are where they come from why they why they do the things that they do there we don't want to treat them as like yours brick wall we have the scale but instead as valuable partners that help us get to where we want to go. So a very brief intro whenever you talk with someone who's in security or InfoSec you will often see this triangle as the CIA triad which covers confidentiality integrity and availability. And so what they mean by by these three things is that you can take pretty much any security control and try to map it to to one or more of these. Interestingly availability is often ignored people often focus on the confidentiality and integrity but the fact that your system has to stay online that has to meet its SLAs is a critical component of that availability as well. So if you look at what InfoSec is really trying to do they're not trying to tell you know what they're trying to do is try to identify what risks are there they're trying to work out how to inform you of what the risks are inform the executive leadership executive leadership has to then take those risks and then make a determination based upon what what the outcomes are going to be and what those risks are as to whether they're going to accept the risk or if they're not going to accept the risk then what can they do to mitigate the risk mitigate as unlike we're going to stick a firewall in front of it or we're going to stick a policy engine in front of it or how do you transfer the risk? Transferring the risk is an important aspect but that's something we won't that is probably not our first line of defense that we want to head towards a really good example of transfer of risk that we're seeing today though is you're seeing cyber security insurance so if someone gets ransomware then they can say hey we're going to bring in this particular thing to help with that but generally that's like worst case scenario and another example of that from a personal perspective is like if you're driving a car you can transfer some of the financial liability to an insurance company so transfer of risk final one is avoidance which is like you know what this is too dangerous or we don't want to accept the risk value is not there so you just eliminate the the thing that was bringing in the risk in the first place so it'd be like let's go and remove the data and go purge it or destroy the medium or so on and now it's not a risk and so they also like to establish policy standards procedures and guidelines what we mean by this is policy is I all data at rest must be encrypted proceed a standard to be we use AES procedures would be something like we use BitLocker in this specific way to implement AES to have that encryption and then guidelines are things that are good advice to follow but you don't necessarily have to follow them but there may be implications if you do but it's not like strictly required so in terms of the other thing that you often see as well is response to security incidents and breaches so as in like something happens there are the teams who they have teams there who go and do the forensics and so on one word of advice though as well since is if you try to avoid the word breach and the reason you want to avoid this word this specific word is because there's only a small number of people in the in any organization who is able to say that something is a breach because there are serious legal ramifications that come with that word so always start with the word incident avoid the word breach until someone from the appropriate group has said this is a this is a breach and then from that moment on you would then use that that particular term but whatever you engage with them or you're engaging with a colleague like always use the word like we've had an incident you know I think this is serious or something you can say like what's what's what's happening but but stay away from that specific word because there are serious legal implications so just as a heads up and so but all of this comes down to two things do care and and do diligence and do care is like you're doing the right thing due diligence is how can we show that we've done the right thing or what are the actions we're doing to ensure we're doing those things so the every major infosec group has to show that they're following do care and that they're following due diligence an easy heuristic to this is what would a person who is trained in this who is an expert in this do what what would a reasonable set of actions be if you if you can consider those to be reasonable then you're probably following due care and this also becomes very important because when you start looking at massive organizations this do care if you're not following do care then there may be major implications that go to the actual person themselves who is supposed to have that do care so so let's jump a little bit forward now so we've gone over some of the basics for for infosec it describes like how they think like why why they do things that they do one of the things that we're moving away from is this concept of perimeter defense so this is like your standard network that you tend to see there's so many variations of this one of the variations is uh kubernetes is actually historically started off as a perimeter defense style approach you have your pod network pods can talk to pods pods can talk to nodes nodes can talk to nodes so very very perimeter defense like you had ingress controllers and so on and eventually you started to put more policy which helped drive it down but um like this this is a pattern that you see over and over and over again where we want to move is towards this nebulous thing called zero trust where you have controls that are more granular closer to the workloads you have this untrusted network that you're no longer basing your your system on and you have this attacker that's on the far end so if they get in just because they're on the network does not mean that they have access to the rest of the system so in a nutshell this is sort of the view that we want to to approach for hitting that zero trust approach but interestingly if you go to a company and you say we need zero trust one of the problems that we're running into is that every vendor has a different set of of what zero trust is that we actually we actually have a lot of of issues on on this particular path as a whole industry because the term is diluted it's it's been hyped up it's everyone selling you a zero trust thing things that were invented 15 years ago are being pitched to zero trust it's like it's it's really hard to make sense of it so the very first thing that you need to do if you're migrating a company of sufficient size is you actually have to define for yourself well when we say zero trust this is what we mean so you need a framework so one framework that i've been working with some colleagues on is this concept of like the same way we have the cia triad we have this concept of zero trust where we have identity policy and control and when you establish this actually gives you something like we're bringing in a product where does it fit does it give us identity does it make our identity story better does allow us to manage a scale or is it a policy thing like are we able to to drive and control things and create rules around it in order to control it is from the control side is this something that's automatable is it observable is it something that i can that i can manage at scale so we have so we have this framework and diving a little bit into it a little bit further so we have identity and when we say identity the area that i have been trying to push companies towards is this concept of cryptographic identity so if you think about how your identity is done today in a lot of organizations it's actually ip address import you all your firewall rules like you start looking at them they're like i ip address import you maybe dns helps break this little bit but it still ends up boiling down to my ip address import so if we can land a cryptographic identity one of the ones that i'm involved with is spiffy so if you like i hope that it ends up being something like spiffy but it doesn't have to be spiffy the the fundamental thing is the is the principle you get a cryptographic identity then you have something there that you can that you can control that it's ephemeral so that identity eventually goes away after some period of time so ideally you want to keep those short in spiffy's case the expiration time is an hour so you actually issue an x5 line certificate instead of it lasting for a year you have to renew it in 30 minutes to an hour which gives us the ability to constantly validate the workloads so in other words we can check does this thing still meet our requirements based upon what patch said it is is it running the software that it should is it configured in the way that we want to configure it is it attached to a system that has the right set of tpm's maybe it's gone out of compliance and then you can notice you don't necessarily have to kill it but you could you could look at the workload and say well let's go ahead and flag it and let's make sure that that that we're able to properly audit and get the right people who own that in order to go pat patch the system or or go fix it we that also gives us the ability to have systems communicate with each other using something like mutual tls where you can think of mutual tls like you in the same way like when you go to like google.com or your bank.com you're able to validate the server as the client mutual tls allows you as a workload to do the opposite as the server i can validate the client the i can validate the identity right off of the transport so this means i don't even have to bring secrets i don't have to have bearer tokens or jots we want to make that initial connection out to the system that in both directions they can validate each other so the x519 certificate becomes part of that chain of who you are and allows you to identify yourself to others in a in a uniform way you also have to pay attention to user identity i'm not diving into user identity in the scenario but it's also very important that you consider what are your user identities doing generally we want to stick with standards something like jots or or similar that'll play well into into policy so then you want to establish something around policy and generally you want to have policy consume your identity so the with policy if you if you make them declarative so there's a few engines that exist in cncf but there's others as well throughout the entire community so if you if you're able to say i want this family of certificates or identities that are cryptographic is secure and you're able to add that into your policy so you can say the front-end server of this application is able to connect to the back-end server or back-end database of this particular system you can model that which means that if something else is trying to connect to those systems it violates your policy and that gets you a fast feedback on your observability platform that's something went wrong this is actually key because if you look at many previous attacks they managed to break in through the front door through to car to struts that on an unpatched system or or some other similar technology and then once they managed to get to capture that system and then they end up extracting out information from from the perimeter but if you have this policy in place it says system a is allowed to talk to system b and is allowed to send these type of messages because it is that it's playing that role then the scopes down the types of attacks and the attacker does not necessarily know what policy you are running on the other side or what are valid messages you can send so this actually ends up increasing the risk to the attacker and simultaneously reduces the value to the attacker that's really important whenever you look at a security control you always want to consider how does this increase the risk to the attacker and how does it decrease the value to the attacker like that it is pure economics to them and this this also plays all the way up to advanced persistent threats because even apts they even they have limited resources they still have to make decisions on where they're going to attack and if you look like you're well defended and you're not going to get much value out of it they'll actually go find software targets in terms so we also want to have policies over time we want to make them human readable so people can audit them and and create them and we want them to be machine readable so that the machine can implement them a really good heuristic is you look at how GitOps works imagine having a GitOps system that allows you to control and manage your policy through that so you have a place you can commit your your code here your policy you're able to get that policy reviewed they go to the right stakeholders in the same way like you would with a code pr you know it's like oh i have something checked into something that touches the database so i'll get the database admins to look at it i have something that it's going to touch this particular area let's make sure that i bring in the right set of owners for that from the various groups and and that gives us a path towards also maintaining that policy over time it becomes something that is visible to the people who needs to and those we can actually tie that that identity as i mentioned to the mutual tls transport credentials so we actually look at the transport credentials you're not saying i am this you're relying on your cryptographic certificate to prove who you are then control all of this doesn't matter if you have no way to control it so this is where you want to start looking at things like how do i how do i build automation around it how do i add observability to it how do i control this like if you're controlling a single cluster you can install things like istio linker d you'll be in good shape if you want to control a large number of clusters many of them ran by different teams and start get a more uniform approach then we really need to start thinking a lot bigger about how these interactions occur so it's more like an intro versus inter approach there's also issues around how do you how do you log where do you keep your metrics ensure that you do your sla so all these are important if you don't have good control over your system you're you're not going to achieve your your goals so again framework identity policy and control so now that we have a zero trust definition time check how much time do i have left nine minutes thanks so one of the things that we want to do is we want to consider what do we actually want to model as part of our policy as part of identities and at the root of it all is trust uh we know we call it zero trust but that's actually what we want is to establish what can i trust what should i trust and if we can model trust then we we're able to describe the relationships and how much we want to trust it how much suspicion do i have of a given system does that suspicion uh is that over my threshold or under my threshold that i'm willing to to trust it and if we maintain these models of trust the overtime that also gives us the ability to sunset the things that we no longer meet our our trust so this concept of trust even though we call it zero trust it's actually about managing the the trust that's there and this to hit a to hit zero trust in a large organization as well you have to also get cooperation so you have to start working with your infosec teams get transparency between between the various engineers and people who are who are there and so the i mentioned before at the start you have to get the software to be able to make use of the zero trust components the the applications that are there and you want to establish a good relationship with with infosec and one of the ways that i found is effective is you always want to start with something to small something you can get a small win i'm saying it's an easy win but it's a but something that's tangible so if you start with an application you say we're going to apply zero trust controls to an application this is something that you talk to your infosec people about they're they're going to be interested in because they know that this is where the world is heading and this actually gives them something small that limits the risk and gives you the ability to experiment and uh you want to focus on in the beginning you want to focus on interest service communication as opposed to inter service you want to say how do the the individual components internally communicate with each other and that prevents you from affecting the outside environment in the beginning in the long run you want to actually control inter service that's where your high value is but in your initial version when you're doing that first application you want it to be something that is smaller in scope smaller in size reduce the risk make it makes it palatable and also allows the system to pivot if for some reason the security model doesn't work out and one of the things you want to do as well is you want to regularly share your findings with your infosec team engage them in from the start tell them what you're going to do get feedback from them treat them as a partner like they're they're not a brick wall they're they are partners in us getting to where we want to go hitting our hitting our requirements and as you start to develop that trust you actually find that the conversations will will shift and to give you an example previous organization that i did some work with they uh i had a group of engineers who vented for quite a significant period of time about infosec saying oh you know they're doing all this terrible things all this red tape that's going on and after about 20 minutes i stopped them and i said have you considered their side of the uh have you considered infosec's point of view on this because you're talking about the red tape you're running into they're living and breathing it so any advice you can give them or any information you can give them maybe there's a process change that you could that would help you understand what they need in order to help you succeed you help help help them help you don't just sit there and complain about it and in fact in some scenarios they may even say hey we don't even have these controls it might be something that you can build easily that you can that you can work through cncf or some other similar group and get those controls built and automate those particular portions and end up in a better place so the next time you run into these scenarios you actually end up with an accelerated path as opposed to getting stopped and having to do this back and forth and missing your deadlines because the collaboration was too late and once you've done that and you have that first application you get that early win then show how that intra service uh path ends up working in inter service over time as well how you can if you're careful on how you demonstrate your intra service communications you can then show how these could then be applied at the broad in the broader sense as you add more controls in a careful way and the other thing that as well remember we were talking about policy and standards once you have this in place you actually have something tangible that you can point towards policy and standards because if there's not a policy if there's not a standard we can't have thousands of little exceptions everywhere you have to actually get it into the policy you have to get it to be to be part of the standard so you could say policy we're going to use your trust workload identities standard we're using spiffy you know the procedure here's how you install spire so by helping set these things up and actually collaborating with infosec with them you actually become a a collaborator with them and you end up helping them de-risk the things that you want to see there and you actually get the things that you want in there while at the same time helping maintain that maintain that security make sure you also engage with the community as well so there's a lot of really great resources we have cncf security tag we have the kubernetes six security group and all of these all of these groups have people who are very interested in seeing you succeed in this particular space and so and people from different walks of life some from vendors some from end users so engage with the community they're they're here to help they're here to to help also set follow like guidelines that people can follow as well so there's a lot of different areas that you can actually help collaborate with and find what those best practices are across a wide group and then those feedback into your into your organizations so it ends up becoming this feedback loop where you get a wide variety of people and a lot of eyes on on things that we end up with something that's way better than just a small team in a company by itself looking at so definitely get involved bring bring your colleagues bring your friends you'll get a lot out of it and finally make sure to help your peers learn because these type of things it's it's not it's not something that we can do by ourselves you know we we need to make sure that we de-risk it by making sure we have a lot of people who don't understand and can work with it they can also help us find where the holds are and at the end of the at the end of the day we all want to practice very important we want to practice self-care we don't want to burn out we don't want to end up in a in a bad place physically and mentally and the only way we do that is by helping our peers helping our colleagues learn and helping them and help set up the system in such a way that we can that we can step away for for periods of time um so if you notice a theme effective communication and collaboration is key so keep this in mind if there's nothing else you take out of this keep keep this thought in mind um and finally there's a little term that I like uh superior out there I'd probably but you're the uh the way you say it but it's like there to know so don't stop learning don't take ownership go ahead and uh spend the time to to learn not necessarily saying work harder but work smarter work with your friends collaborate with people so thank you very much thanks so much frederick awesome staff