Welcome, and we are live. Welcome, everyone, to our CTF live stream session for the Cloud Native SecurityCon North America. I hope you're enjoying the CTF challenges so far, and we have two sessions and a set of great speakers and fabulous co-hosts that will join me today for a session of some Q&A, some questions and answers, and then we'll go through some of the CTF challenges. Okay, so let me introduce you to co-hosts for this first session. Welcome, Alyssa Miller and Gab Smash. Hello, it's great to be here. Hey there, good to see you, good to see everybody. Awesome, great, and the floor is yours. I'll let you run the show. I'll be here as backup if needed. Good deal. Awesome, so do we wanna bring in our guests? We have a couple of awesome guests today, Gab. We do, yeah, so who do we wanna pick first? So can we just start bringing them in because I wanna make sure we get the names right, but I know we got Allie's hanging out out there and there's Mark has joined us. Yes, we have Mark Manning here. Anders has joined, Andy's popping in and Lewis is here. Yes, this is Lewis. I love it. This is the real Lewis, not the fake Lewis. I can see both. It was exciting. So I don't know, we wanna round the horn this thing and see what's going on with y'all. I think you should probably introduce yourselves. We start, maybe we'll just start next to meet this side there, I can do the same, Mark. Hey, how's it going? Tell us about yourself.  I'm a person with an InfoSec background. I used to work for NCC Group, doing a lot of source code reviews, doing a lot of Kubernetes security stuff. And yeah, I'm getting into a lot more cloud lately and now I work for Snowflake as a security architect. Nice, nice. We can Anders next? Yeah, I'm Anders. I work as a developer advocate for Styra, which is the creators of the Open Policy Agent Project, or OPA, which I'm gonna refer to for the next hour or so. Yeah, I come from a background in identity, primarily. So I worked for the last three years or so with OPA and Access Control. Before that, it was all about identity, identity of workloads, identity of users, and clients and so on. So a lot of OAuth, OpenID Connect. So it kind of came as a natural next step, like once you've established identity, like what do you use that for? Like, and so I got into authorization and yeah, here I am. Awesome, I have former DevRel myself, so I have a special place in my heart for the Dev Advocates, you know? Love it, love it. So Allie, tell us about you. Yeah, hi. I'm also a developer relations engineer and developer advocate. I work at New Relic, and I specifically focus in security and making security more digestible for beginners and newbies. And I actually live stream here on Twitch, so if you wanna follow me on Twitch, I'm at ending with Allie, where I do a lot of learning in public of teaching myself security, most of my practical knowledge, I've actually learned live here on Twitch. So I do a lot of different lessons and education on Twitch, so. We need more people like you in the industry for sure. Yeah. All right, Andy, do you wanna go next? Hello, hello, I'm Andy. I'm a founder and CEO at Control Plane, where we do cloud native security stuff. I'm a little bit dev, a little bit of ops, a little bit of security in there as well. Very proud to say I've just finished writing a book. Shout out to Mark, some awesome review work there as well. And of course, to Lewis, who's over there. And James, we were both instrumental in making that thing more polished, fixing the bug bounces up, all that kind of good stuff. I'm a Santa structure as well, Sansec584, again, with the Morden capable, yes, this is Lewis aiding and vetting in that. And yeah, like a zealous CTF maker and player and enjoyer. So yeah, super pleased to be here and really looking forward to today. Congrats on the book. You'll have to drop the title for us so we can get it. Oh, okay. It's called Hacking Kubernetes, perhaps predictably. Perfect. Very straightforward title. I love it. I have no idea what it's about. Yeah, I know. It's impossible to tell, isn't it? My word and I begin to. Yeah, I suppose one more thing is like, I'm super stoked as well. I'm actually at Kupon in person. So yeah, this is the conference center wall. People can be contained for the moment. So yeah, if you need me to go and like high five anybody or like respectfully wave at them from a distance, I'm your man. I mean, there's a few if you could find Ian and Kat, Castro, you know, those two, they might, you might know them. Yeah, just maybe. Just maybe it was contained in intentional pun because I like it if it was. Yeah. Well done. Well done. So Louis, other than editing books for Andy, I'm betting there's probably a little more you do. I help select covers for books. So I'm very proud to say that the book has got a duck on it. So I think that's a highlight of my year, possibly last 10 years to be honest. And I'm not in Kupon. I'm back at home in Wales, which is, well, England is the sidecar of Wales, but hey, I'll deal with that next week. Yeah, so day to day within control plane, I do lots of training. I used to go to lots of different places but I pretty much give training in here now. So this is my training dungeon. No, no, it's, it's, it's lovely. It's been great. We've had to change our ways over the last, however many months. And it's, I just got to meet lots of people to get to help them out and it's super awesome. And I get, I'm going to point that one and point that one. I get to work with these every day and it's phenomenal. They've really helped me push my career and super awesome people. And thank you for having me. Don't follow me on the internet. There's nothing that interesting to find. Yeah, that's pretty much it. Colleen, no, no, this is not Louis from now on. I should change my name to that. That would be perfect. Absolutely. So James is hanging out with us too. And James seems like he doesn't necessarily want to admit association with Louis and Andy, but you know, we'll see. James, tell us a little bit more about yourself. Hi everyone. I'm a security engineer at control plane with these two. And I sort of deliver security consulting-y type services for these guys. I was previously a security consultant. So that's very much my wheelhouse, what I'm not helping Andy with books or help building these awesome CTFs. So as people love the CTF, they should thank you is what I just heard. Well, there's a huge team of us at control plane that have all put in lots of efforts. So I'd be wrong in them just saying it was me, but it's been a lot of fun contributing to it. Anything positive goes his way. Anything positive his way, anything that's not so great, I'm here for that. All the hate mail goes to Louis. I got a special service for it. It's not the first time. We'll put his email in chat. Make sure you all know where to send that stuff. So Andy mentioned the cloud native security stuff. So I'm curious how you guys got into cloud native security. I mean, what does it even mean to say cloud native security? I mean, I think everybody kind of has their own idea of what cloud native is. And then, okay, on the top of that, we put security and then sometimes on top of that, we put cloud native application security and then there's gonna be cloud application security brokers. I don't know, it keeps going, right? But how did you guys get here? I mean, Allie, let's start with you. How did you get involved in this area of the world? Yeah, so I was thinking about the right way to say this. I'm going to reverse age myself. I'm gonna baby myself in a way that I can't do. Baby myself in a way, because to me, it's only been cloud. There's never been on-prem. So when I get, okay, I'm sorry, like I'm baby, I know. So to me, yeah, I know I'm making myself be baby. But to me, whenever I am doing anything, it's always been cloud first. So to me, they are synonymous. I am now actually learning more about how it used to be done back then as I dive more into Kubernetes and how servers are still somewhere in the world, still being hosted. But to me, it's always been cloud first and I've always had an interest in security and I've always had an interest. I've always thought people who work in security are the smartest people in the world and people that I've always looked up to, like Alyssa and Gabby, I follow you both on Twitter. Fan girling just a little bit. But I've always thought people that work in security were such amazing people and just thought in such a different way. And so I was like, how can I learn to be like that? And to me, that first step was figuring out just how everything works from a security aspect to a technical aspect. I feel like security is a great way to learn just bits and bobs of everything. So that's how I ended up here. So for the record, I am now following you on Twitter. Yeah, I need to do that. I need to make sure I am too. Even though it doesn't say that you're following me. So I'm on- I'm on lists. I'm on lists. So you're both on the security list. I can definitely understand that. I just give you a hard time. There we go. Yay, cool. So let, I'm not gonna say it that way. That would be cool. So Anders, I'm guessing that you like me probably didn't start in cloud native but I could be wrong, so correct me. No, you're definitely right. I remember my first job as a developer when we were done coding, we would deploy our code to a USB stick and we would walk across the office building to the operations people who would then take that and actually install it on our servers. So yeah, that's, so I'm that many years old. So how did you end up in a cloud native world after that? Yeah, that's a good question. I think eventually that same organization where I stayed for a couple of years, they eventually understood that things had to change. There was like that whole gap between development and operations was, it just wasn't a viable model. And of course, so like slowly, but still we tried and adopt like DevOps practices, try to be more agile and so on. And then eventually I ended up working more in identity systems. And of course in those like those standards around for something like 20 years. So once you learn something like OAuth, you can kind of work on that for the next decade or two. But yeah, and then coming into authorization and OAuth or in OAuth powers, there's really no standards and there's really a lot of ideas on how to best do that. That was kind of a shock for me coming from the identity world where there's all these like very strict boundaries on what you're allowed to do and not do. So yeah, and to answer like how I got involved in the cloud-native space, I guess this crew OPA which is of course one of the graduated products in the CNCF. Awesome. And props to that organization for creating the antithesis to DevOps at like extreme levels. I mean, talk about creating silos. That is amazing. USB sticks to deploy. I'm speechless. Gabby, have you ever worked in an organization that did that? No. Nope. Think of the security though. There's so many. There's no way your USB stick is going to get hacked in that 40 yards it takes to upload it to the other server. You were before your time. All right. So who wants to go next? How did we get into cloud-native? We have porn at Mark. Oh, is it? Hi. I think Mark's being volunteered. Yeah. Mark's being volunteered. That's fine.  So I want to go all the way back and describe myself as like a great, great grandfather of technology or something. But I was a pen tester doing network penetration stuff and when virtualization was just starting. So it was kind of like, that was the first revolution that I saw in the industry. And somehow I migrated to an application security background doing Android and mobile stuff. And I swear I'm going to get to, like, where we get to cloud-native because it doesn't make any sense how these are related yet. But I saw Android and iOS that were doing, like, sandboxed processes. They were doing, like, isolated kind of container processes. And I was like, oh, this is awesome. And when containers started becoming adopted, Kubernetes was around. I was like, this is the future of all servers. We're going to have, like, containerized processes. We're going to be isolated. So I started adapting what I was doing for, like, application security stuff and looking more towards what's Kubernetes doing. Like, let's help secure this thing. And of course, that didn't really flesh out what I wanted it to this thing. And we don't have full sandbox per se. But we've got some level of isolation. It's cool. So I think I was just pushed into cloud. I had a whole bunch of customers. And it was just the industries moving into cloud. Like, who's doing on-prem stuff? In fact, earlier on in my career, I was flying everywhere because everything was on-prem. I had to go to, like, data centers. And I had to go to physical servers and stuff. And then it just stopped. You say, oh, it's all remote. We'll just give you a shell. We'll just give you access to anything you need. So I had customers that were just in the cloud. You need to adapt or die in the security industry. So I was doing a lot of Kubernetes stuff. And I built a team at NCC Group. That was just doing containers and sandboxes and Kubernetes security assessments. And we kind of built some staff around that. So now here I am working at Snowflake. And they're like a cloud company and full cloud native. We don't have anything on-prem. We can't even imagine what an on-prem server would be at this point. So here I am. I fell into it, I guess. Mark, that was kind of like a choose-your-and-adventure novel. Yeah. It was exciting, right? Definitely. It's exciting for me. And I'm living it. That's awesome. Yeah. I mean, it's kind of interesting the way that it, I mean, some of the stories already, just like it sort of happened, you know? It's crazy awesome. That seems to be like the way of things with tech careers. But Eddie, how'd you end up here? That is a fine question. I was very privileged in that my first job out of uni, I ended up doing something that I was perhaps under-qualified for at the time. So there was a small startup in Bristol, which is out on the west coast of England close to Lewis's proximity. And it was a software-as-a-service back when that was actually a definition of something, business-to-business management system. I was the first employee, so I had the incredibly fortuitous position of doing operations, doing the development, doing PCI compliance, back when we still stored numbers of people. That very quickly failed to be the case. And everything was rack-based. So everything was like you were buying space in a colo. At that point, you weren't actually stacking them and racking them yourself, but still renting servers. He does this occasionally. He does this just freeze frame for a moment just to get us all on our toes.  You got us again, mate. Historically, I was saying we had availability issues, and then everything froze. So there's some sort of resonant-inductive coupling with silicon. I'll be careful what I say. And yeah. So Amazon opened EU West 1 in, like, someone will probably call me out, 2008 maybe. And we just jumped on it. So going from that position where I'm just kind of the de facto, this thing needs to be done. There's a cloud over there. Why don't you try and unify our approach to the way we deliver services? And that was it, kind of steamroller from there. And then after that role, I started to be a consultant. And I just found that regulated industries had more interesting problems. Everything in engineering is a compromise, and often it's trying to, like, fit something into a shape that doesn't really naturally fit. And yeah, slowly escalating through different organizations. And then finally cloud native turns up, and everything just makes sense. You can kind of take the big multi-talented Linux system, squeeze it into a microcosm, and then run, or bin pack them, kind of add in an item. And it was pretty clear from early musings with Docker that there were lots of security opportunities. And yeah, it's just all kind of steamroller from there. So yeah, again, very fortunate to have that luxury. And I often wonder for people joining the train or getting on the ride at this point, what must it be like to have all these foundational layers before you even get to the containers and Kubernetes at the top? So I think all the way down through. So yeah, big up alley doing it all in public. Definitely the best way to learn. Yeah, there's a lot that I'm, there's so much that I feel like I'm always learning. And it's, especially as I've been digging more into Kubernetes, it's just been like, so much to break down and just be like, oh yeah, like this is, this is how it's done. And this is like why I feel like I've been like missing in my education as I am continuously learning. So yeah. Yeah, it's a super nice thing that kind of, at some point for me, like, I've learned so many different concepts and suddenly they just all seem to kind of amalgamate and make sense and like a cross reference. But yeah, certainly it's just like perseverance and making mistakes is how I learn. You mentioned the regulatory environments. I think Gabby and I can both kind of identify with that. Me from the financials and Gabby and her industry. Yeah, I love regulations. Yeah, but Cloud helps us address some of those regulations, things like data localization and all that fun stuff. Yeah. So, Louis, how did you end up? You're with Andy now. You're doing this cloud native thing. Did you just kind of like drag you, kicking and screaming or was this voluntary? Oh, I don't know what I'm allowed to say on that point. I think we're exclusively, I'm just with control plane now. And it's, I'm not anywhere else. It's with control plane. Yeah. My career, it's been very, you can look on LinkedIn and if you can figure it all out as how I got there. Congratulations. I don't have a clue. Please tell me that the main point for me was about five, six years ago now, I just hit this like lull in my career where I was a developer. I got into it off a level of developing. I just, for me, it's puzzles. Everything that I see is the case of how do I fix it? How do I make this? How do I solve that problem? And I got into this position where I wasn't solving any problems whatsoever. And, and it was last Sunday, it was World Mental Health Day. And at the time I was also suffering from depression, which I wasn't aware of because it was a biological thing. But it absolutely sucked. And so, but then having solved my depression made me realize it was like, I like solving problems. So I kind of jacked in my career of being a developer. And then it was like, what's interesting. And at the same time I was starting a family and then containers and it was like, stop, stop containers. That's that's going to help me because I need to be like, I'm going to have a child and they're going to be screaming in the night. I can't work till like 4 a.m. So I started that way. But then for me, it's always conferences as well. It's events like this. You get to meet people who are like minded. Sometimes you feel like you're in a bit of a hole on your own and no one else can really understand you. Then you bump into all these amazing people in these conferences and you're like, oh no, actually, we're kind of alike. It's kind of okay. It's a nice place. And so from that I saw Andy on stage hacking containers and it was just like, hello. Hello. Security always scared me because I never felt like it was a defined line that I could achieve. Whereas actually then I realized this is the perfect puzzle for me because it's something else constantly evolving. It's always something which I can work further on. And so from that point, I've worked my something off to get to this position where I could work within control plane and it appears that I get to work with. So I thought like, you know, Andy and you're going to hear more about James. But we've got some of the people behind the scenes as well helping us today, which I need to mention, such as Michael, Steve and Carl.  And it isn't just career is about being a better person as well. And so that's just what we do. And yeah, so probably in a year's time, I guess I'll still be in this kind of branded top. But that's where I am. And I just think I thought that's the main thing I just say to people is this like whatever position you're in, especially with the CTF and that's that's a puzzle that we've made for you. It might feel tough at times, but don't worry because it is supposed to be really tough. And we're here to help. But at least by the end of the day, you're going to learn another way as to how to break something which is always fun. We do like breaking things. All right. To finish off that trifecta, I guess, James, you're the last one. Hello. So, yeah, as I mentioned earlier, I sort of started starting my career off as a security consultant. So I guess I was quite fortunate, I think, to have that as my first sort of grad job. Because I don't think I appreciated it when I applied for it at the time, it exposed me to a huge variety of orgs and environments and ways some places do things. Some places do things badly. Some places do things well. And sort of early in my career it was invaluable already because it sort of it exposed me to all those different things that perhaps would have taken me many more years to to witness and learn from had it been like a normal job-cycling scenario. I sort of started off in, I guess, what you might call a more traditional security kind of penetration testing thing, where I was looking at, like, windows and Linux boxes and maybe a bit of mobile here and sort of you're expected to sort of know a little bit of everything and also largely based on premise environments. And the more, as sort of the years went on in that role, this newfangled thing called cloud or probably not so newfangled by the time I was looking at it, but more and more places were using it. I guess it appealed to me just, I think, partly due to the elegance, but yeah, I became part of the team that looked after a lot of the cloud and especially the containerization element of those bits and pieces and just their exposure of looking at how different orgs built things in different ways and how they screwed things up in different ways. I think really is how I learned. And then sort of fast forward a little bit today at Control Plane where I sort of still to a degree look at various orgs and how they screwed things up, but also sort of giving back that advice and contributing to the security process. Awesome. Those are some insightful answers. I think it's really interesting how everyone's kind of got a different, a really wildly different career path, but we all end up in the same industry. So a few of you mentioned that you really enjoy working on the CTFs and also solving CTFs. So my question for you is if you could use one tool and one tool only to do a Kubernetes CTF, what would that be? I know. I was waiting for that answer, but come on, we can get more creative than that. I know, right? I mean, that was the answer I was going to say was just terminal. Terminal. That's hacking right there because then you get everything. You got to be more creative. Play with the API. Crew, right? Like the plug-ins for KubeCuddle, like Crew have a bunch of like scripts that are baking and that like to me is kind of like the metasploit of Kubernetes or just got a bunch of scripts that they aren't necessarily like new things you got to compile and build. They're just these dependencies you can yank into your box really quickly and start attacking different stuff. I like that. The metasploit of Kubernetes. DJ, Yuffie says they would use Splunk. I saw that. It's interesting. Other thoughts? I mean, because I kind of, you know, I knew we were going to kind of go into this path and I was thinking about it myself. I mean, kind of along the same lines, Mark, but I was just thinking like Perl, like, you know, I'd be out there when my thought was just, yeah, how do I, you know, probe and abuse the API because I mean, that would have been my first thought. So, but yes, I did also think about the console. Well, I think it is right. Or is it like everyone's saying bash because that's you don't know the environment you're going to get. Are you going to get remote cut execution? What kind of shell? What kind of environment are you in? Like, what if it's Windows? Like, everything's out the window. You don't know what to do. So I think like the core Unix tools, running Netstat, LSOF, you know, like bash. What can you do? Like the find command, running strings. Like, these are all simple tools that are on most boxes, but they're so important for the CTS. So is that like a statement on, like the types of issues that people have, typically in their cloud-native environments? Or I mean, what are your thoughts? Is that, because I feel like, okay, if I'm going to go hack a web app, you know, it's probably Burp Suite or something like that is going to be like the universal tool everybody says they want, right? But when it comes to, you know, things like a case cluster, we don't really have like that, that tool set that necessarily stands out other than, yeah, the terminal windows. So do you think that that kind of says something about common mistakes that people make? From my perspective, yeah. I mean, we are not dropping O-Days on people, right? We are exploiting misconfigurations. We are taking bash scripts and weaponizing them. We're just doing kind of script kitty stuff because that's what we're targeting and that's the most common configuration problems that we see in cloud environments.  It's like, let's write some tools to speed up, you know, common misconfigurations and stuff like that. I wonder what other people think. It also shows just how new this all is because having a tool like Burp Suite, web apps have been around from day one. So a tool like Burp Suite has come out of it that allows for that extrapolation and easier interpretation of data and information you get, but with how new cloud native is and even a tool like Kubernetes, you don't have that time period to be able to create an extrapolation because if things are moving so fast that you just have to keep pushing forward, you don't have that break point where you just be like, oh yeah, like I can actually build something around this, but I just have to keep going and figure out what's wrong and you're going to do it on the one thing you know, as we all said, bash terminal command line. Yeah. I think Alyssa mentioned that before, just like the idea that things need to be statically compiled and maybe we can curl bash them down into the pods when we're exploiting stuff. Like we're not voting up Burp Suite and jars and Metasploit interpreters into a pod. We probably don't have the time and we probably don't have the execution environment to do that. I'm kind of curious for Andy's thoughts because Andy, you literally wrote the book on this. Yeah, I suppose, yes. It actually goes to print today, so it doesn't exist for another month or so. Yeah. I think, yeah, I mean, it's a really strong point. We're not searching for vulnerabilities in the code base itself. There are huge buzzing projects going on against Kubernetes which kind of deal with that for us. Obviously, because it's a purely declarative system, then best practice is easy to statically analyze and we've got a lot of tooling and this makes the whole pipeline story into the defensive DevOps build out really effective. But then as a kind of emergent property of that, there's so much complexity in the number of permutations that we can have set up that even though we can statically analyze for like a known good baseline on various different parts of the system, it becomes misconfiguration, as Mark said, and just the interplay between two things that are not correctly configured. Maybe that's on a kind of per name space basis. Maybe that's the way that the cluster sits in the sort of wider topology of the cloud account because, I mean, there's something in Kubernetes docs which is like the four Cs of Kubernetes. You've got the code, the container, the cluster and the cloud, I think that's right. And we model the applications already compromised because we say the application is compromised. What about the topology and the network policy around it? What about the node isolation? What about the services and the workload identity that that can hit up in the cloud? And all those things kind of inform how the architect is built. So the question there becomes like, not only do we have misconfigurations in the file system, can we escalate to root really easily within the pod, and then all the container breakouts generally require root or cap or some capabilities. So that's kind of the first line of defense because the security context is hard enough. Then, again, assuming that that's broken out of what identities can be integrated with in the cloud based upon what the service account has. To some extent, again, you can statically analyze those kind of things. But then, of course, if somebody can just exploit like a metadata API and security where you can hit your cloud provider's metadata API, pull back the instance role with like an old school, well, an old school token service, and then just escalate to the cloud account, well, you can just go and image all the disks and it doesn't really matter about your configuration of the cluster itself. So having everything to clarity is super useful, but then the way that we kind of work our way out and around those, it is just a standard set of tools that we want to... The difficulty is doing it contextually and understanding the developers' intent and trying to figure out where the holes would be rather than just kind of like spraying scans across the whole thing. But yes, a meandering way of saying, I agree. Awesome, yeah. So as someone who's never done a Kubernetes CTF, I'm super curious. How would you go about solving this CTF challenge? So without giving too much away, where would you start and what would you look for first? That's an excellent question. It kind of depends. Speaking generically, like old school enumeration and discovery techniques are still completely relevant. Cloud native doesn't throw away the baby with bathwater kind of thing. It just brings in some other abstractions and allows us a more fine grained model to hang policy around processes, basically. So I love Nmap, actually. I suppose that's another tool with a decent scripting engine to it as well. So yeah, starting off with an Nmap enumeration is often a useful thing to do against cluster. In this case, in the first thing we're going into, there's some application level injection that we've got to play with. Again, as Ali says, it's been around since the dawn of time. This is the way that stuff gets pwned. Remote code execution, foot in the door, and then what's my privilege? Can I escalate? Can I enumerate? Can I attack the visible horizon? All that good stuff. So I haven't really said anything that I hope. Well, so why don't we take this? This seems like the perfect segue into. We're actually going to do one of the challenges live here. So James, I think is that you that's taking control here? Yeah, I haven't heard James yet though. So if you could just check it's Mike. Otherwise, I will speak on behalf. Yes, it is. I'm so thankful for that. James, just really quickly, if you can increase the size of your terminal, it seems like you're opening a bigger one. Yeah, absolutely. Sorry, I'm just prepping a couple of windows. So whilst you prep that just for today's CDF, if you are looking for a cluster, if you could DM the Taskmaster, Taskmaster has a load of clusters ready to go. They're on the other side of that door over there. We'll send them across your way. If you need any help, reach out to Goose. Other than that, just make some noise on the channel. Someone will find you soon enough, and we'll definitely be there to help you out. And Lewis, if someone who's watching now wants to get started, where should they go? So you need to sign up for the security days, and then you should have had an email with credentials. That's where they need to go. We will promote this at the end. There's an open source version of Simulator where we've already got scenarios out there. And then if you are interested in this, well, we're always running game days anyway. And for us, it's always just about letting people in and just playing about. So if you are interested, just reach out to us. Again, I put myself down on the Internet there, but you can find me on the Internet. I've got a double barrel surname. There's only one of me, which is a terrible, terrible thing for me. I'm always more than happy to help out. On Twitter or on Slack? On Twitter. Yeah, you can get me on Twitter. You can get me on Slack. I'll put all my details in Slack as well later on today. But again... Drop them in the chat also. I'll do it. It's my Twitch streamer. I'm sorry. I'm trying to get everyone information. It's bringing me out. I'm trying to get answers. I'm just going to let you down. Nothing. There's no interest in my streamer. It's just a contact. Just a contact. I know. We'll take a soft line on it. We'll discuss it. It's okay. Cool. Sorry, Andy. I was going to say, we've got a theme permeating the CTF today. The conference is in LA. And so we have a Hollywood theme going through. And the first film from which we have taken inspiration is Inside Out. And yes, more will become apparent. Over to you, James. Thank you, Andy.  I'm hoping you can all see my screen and it's blown up enough. But just shout if you can't, I'd love a little bit more. So we've got two sort of web pages that are exposed here. And the reason we sort of started through a web application is we wanted to simulate a little bit more realistically how an attacker might gain access to a container or might exploit an application. So if we explore the web pages available we can see we have a status page, which just tells us some information about the system. Just tell us it's down, nothing too interesting at the moment. Then we can also see we have like a utilities diagnostic page. So of interest, initially we can see this ping box which if any of you have any kind of hack the box or traditional CTF experience, you might recognize this as a potential command injection issue. So what I'm going to do is open my network tools and firebox just so I'm recording network traffic. And let's have a look at what happens if I try and use the functionality legitimately. Zoom in the screen please. Yeah, I'm not sure if it resets every time I refresh that's all I know. So you can see through entering an IP address here we have the output of the ping utility. Is anyone from the room has a bit of a guess at what's happening here? I'd say it looks like developments come out for retirement for a couple of days. And I think it's something that we could do with this potentially. I've been inclined to agree with you, Liz. So what I'm going to do next is copy in my network tab I can see this is the most recent post request apologies if it's a bit small, I can blow this bit up. I'm just going to copy the request out as curl. So that will allow me to over on the other side here. Hopefully, even if there's loads of junk in here this is this will be the authentication token. But essentially we have the same request that we made when we press the submit button in the web application on the left hand side. So if we enter we hopefully get the result. Excellent. This proves we can duplicate what we're doing in the terminal. So hopefully in the stream you can see the last part of this command or last part of this curl request, sorry. Looks a little bit suspicious. So we're seeing there's a JavaScript function we should note that it's appending ping-c3 and then the the input which is an IP variable, right? So starting to think about how can I break out of that how can I change the IP to something more fun? Mm-hmm. Yeah, exactly. So not only can we specify the IP because we're passing that c3 that looks like we're passing the whole command in as the request. So if we try that again but we can edit say get rid of all of that and maybe just say if we try replacing it with ID we'll see that we can specify the whole command here which is great news for us. So we have a command ejection, command execution floor in this website. We can see that we're running as the engine X user. So that kind of tracks given that we potentially might be using engine X to serve our website over on the left here. The next thing I'm going to do is throw a reverse shell. This might be more familiar to some of the sort of classical pen testers or security folk amongst you. So this is where we will be connecting a bash shell to an IP under our control. So for this purpose I'm using a service called ngrok and what this does is it allows us to basically listen on a public IP on the internet and get that connection proxy back to our local machine. So the command I'm going to use to do that is going to be netcat in the container here. So I should say there are a few different ways to achieve this. For example we don't, without doing a little bit of further enumeration, we don't know that we might not have the netcat binary installed in the container but for sake of argument we'll assume we know that. So so we can run a command that looks a little bit like this and then talks to our ngrok endpoint. Here's the following interesting. So getting a DNS error here so this indicates that there might be a DNS problem in the cluster so we can work around that by resolving the ngrok URL to its IP address and then using that in the command. Cool, whilst you're doing that James I'll just mention as well that if you've done our CTF challenges before we'll come straight into Shell and so this time around we wanted you to have to do it this way to say like we haven't given you credentials to start with and the next couple of scenarios you've got credentials but we're just trying to show you this is how it can start so if you're always wondering well as an attacker someone sends me credentials it is in the case, that's what we wanted to show with the start of this. Back on our ngrok screen we can see that we've got the ngrok tunnel spun up and in this middle panel here we have our reverse shell and prove it's alive so this is essentially the same command we run before but now we have our reverse shell which gives us a little bit more flexibility so I'm now going to start enumerating around the cluster to see what kind of container it is see what's available to us so we're inside of a pod we can do anything that we want here what are some other tactics other people are interested in exploring here what would you do when you first get into a pod? Being British I'd wipe my feet first and take my shoes off before I go into someone else's pod so one of our favourites is Am I Contained by Jesse Frazell if you can get that running it shows you a lot of what you can do from that point so big shout out to Jesse as ever I'm pretty much, this is what Andy would say anyway so I'm just saying what Andy would say we've got some really done I'll leave Shari from chat says capsh-print nice so what that is is it's going to be listing all the capabilities that are available to the pod implying that maybe there's some overprivileged access to this pod can I break it out of the container what can I possibly leverage also Jay Beale says Am I Contained I'd be a good check too so this will live as you say will list us our current set of capabilities a wild pop appeared which you may recognise as the default set of Docker capabilities so no privileged container so there's not a trivial breakout so you've got a couple of links floating around no go I was going to say the mounts, I'd like to see what volumes are mounted inside the container good chat so I think we've been meeting and we don't have the mount binary so now we start looking at the proc file system can we get the information from the mount command without running mount we've got a request for another zoom is it possible to get a zoom in please yeah absolutely try to maximise without wrapping too much but hopefully that's a little bit better definitely so yeah that's a good suggestion on the proc file system we could look at proc one mounts and this will give us a good indication of what's mounted in the system there's our favourite path Run Secrets Kubernetes service account come back to that later maybe is anything else standing out what was the movie again that we're basing this one on emotional status seems a bit unlinuxy inside out this is a really great call out there looks sus definitely says alright so that's aggressive it's like we went for inside out rather than 7 because I would just be precious right now so at least we did that as you say not very Kubernetes well these are terrible negative feelings so I automatically want to replace them with something positive after a little bit of sadness though so if you were to search the movie inside out do you see the core characters cool so what do we reckon is there a list I was just going to say for searching on IMDB quickly I was just going to mention if you have a character that we're potentially missing and I say it's any big inside out fans on this but we got sadness and joy missing from these emotions okay so what do you reckon we should do about it if they're missing maybe we should find them what do you reckon another files or maybe um someone in chat says find or add it's JBL says find or add kubectlc if there's a service account token and run secrets okay let's have a look J's taking us in another direction I like it well we can always come back to the old emotional status another point grep for sad I feel like that's yeah I feel like that would be fruitful okay wait where do you think we should grep slash yeah it's just everything we could stay here for a little bit alright how long is this I was going to say we got like three minutes left maybe underslash I can't allow that one I'm going to save us the weight on that one and tell you it's not going to come back with anything let's get to now but we also see it also says emotional status here okay well I suggest we maybe follow what J was saying and have a look at kubectl so okay so as probably no surprise given the earlier mount entry we can see that we've got a service account mounted in so we could try and talk to the kube api server with it just to make you aware james we've got about five minutes left and we've got like one minute left we've got one minute left I was going to ask if we can tie it up here okay yeah we can absolutely just run through the rest of it if that's yep cool so if we use the service account token and the dns address of the kubernetes api server verify that we can talk to the api server like so so we might then want to start poking around a little bit maybe get pods for example which reveals that we have a limited service account but it does tell us the namespace and the name of the service account can i and who can do just the secrets so so for example we could do something like that see we can't get secrets so we could if we had a little more time maybe download something like rack s which would allow us which is a crew plugin it was just a standalone binary beforehand but allow us to enumerate through the access the api calls that we are allowed to run and which ones we want but we might also realize that given that the emotional status was mounted under var run there might be some form of config map that we are able to look at yeah jb will just put in chat to look at config maps uh-huh so we can and lo and behold we can see there is a config map so let's jump into it dash oh yaml so let's have a little look at what it is looks familiar so next step is we might want to update that to something that has the values we want in it so as Lewis mentioned there's another couple of um another couple of character promotions in the movie Lois you remind me what those are please for your dreams certainly oh Ali you go I just know one sad so um and you need to see the movie it's a great movie sadness and joy I know I need to see the movie cool so uh what I'm going to do is move into a temp directory and then paste in a pre-written yaml file with the with the um with the new emotions in them then if we look at the yaml file we can see the is that's the full range that are in the movie so we can look at if we can apply those cool so that looks like it was successful now go back to and give it a minute it might update so in standing with this config map why can't we have just appended to it why can't we have just appended sadness and joy to the file I'm going to assume it's mounted read only swing and a hit so now if we go and look at the build status we might notice that it has changed and the system believes or is happy with the config that we've provided it and potentially has given us a bit of a hit as to what might have happened next sockets make me hope that there is some kind of local socket unique socket exposed somehow in the pod now let's have a look so in our testing it sometimes takes a minute for the sockets to align properly because of course the CI system is never instant are you going to be passing the Docker socket into this path potentially that would be cool or exciting yeah so the concept of this scenario we've inside out was in the movie and without giving too many spoilers the memories are changed and altered causing different effects to happen and so within this scenario you've had to go in and change the memories accordingly which is then causing change in effect to happen from the cluster which is allowing us to go on to that next level so within a couple of minutes we might see that within far run our friend proper mounts do we need to drop this connection potentially and see because when we set up initially we could rerun that potentially spin up into another pod or anything to that effect so I believe it will kill our connection for us but as the demo gods appear to be against us perhaps we will have to force it so I can just re-spin up my connection through rerunning the is engine X doing the actual socket opening to be reloaded from the configuration like if you kill engine X it will kill the pod so there is a deployment modification so it waits for the Kubernetes deployment to be redeployed so we're waiting on waiting on Kubernetes scheduler and controller at this stage there's some good chat in the chat right now um blogful certainly it's all good Eureka is best yeah blogful has pointed out that they reverse engineered the status stock PHP page to identify what these things were which is a great shout and it's a question do pods have a concept of hostname of bash history well yes if they're baked in if somebody's done something dynamic at build time but once the pod restarts then no, that's a bad rule and it's lost so we can wow so Docker is in this pod next to your engine X service is that what this is we uh yes so Docker CLI is installed but equally you could curl it from somewhere given this pod has internet access so if we run this command we'll see that we can talk to a host Docker Zeeman I would say uh just a reference to anybody that's interested BOTB like the static binary go line tool can interface with the Docker socket to do a bunch of these workouts so if you didn't want a full Docker binary to interface with it you could use BOTB so unfortunately I got bad news because this has been awesome and I know all of yours are really enjoying it too but we do have to wrap up so lots more to be learned obviously James thank you for running through this and thank you everybody for all the great suggestions the ideas and it's cool too to see in this CTF how maybe there's different ways to go about finding the same information same as when you're pen testing something like this or trying to define those volumes in your own environment so but yeah unfortunately we got to wrap up so thank you everybody Mark, Lewis, Anders Allie, James Andy, Gaby it's been a lot of fun yes thank you all thank you thanks all quick reminder we'll have another session at 3pm pacific time where we'll go through and we'll talk to some more questions and you'll have a new set of hosts and we'll dig further into what's available in the CTF until then good luck good luck good luck everyone


We have said 1230, okay, okay. This is like one of those cases like the Indian Railways like, even if you reach the station before time, you cannot take off before time because you've already committed the time to the passengers who will join the next station. So we just want to respect that. But I'll just get it started just informally there. So all the people who are here, how many of you are coaches here? You provide some kind of coaching, okay? So roughly about one-third. The remaining two-third of the people, do they use any coaches in their organizations or teams? They would like to raise their hands. Do you have internal or external coaches? Okay, so I saw some hands going up. So one question to all the people.  Minimum viable coaching, okay? Because I didn't invent it but I just thought of, I just did something last year and after I was done this nice-sounding name and I thought minimum viable coaching sounded very cool. And I haven't come across that as a term. I don't take credit for that but I thought this was, I just wanted to kind of mix up those, mash up those two things and create something there. But when you hear this term, minimum viable coaching, what comes to your mind? Anyone would like to share whatever comes to their mind? Anything? You still have an impact but the minimum that you can do as a coach but you still have an impact somehow. Yeah, fair enough. That's fair. Anyone else? Know your limits and still create some kind of an impact. It's still be of value to the teams that you are serving. Fair enough. Okay, you will say something. What's the best you can do in a very short period of time? Okay, fair enough. We'll see. Come again, learn when to let go. So that's interesting as well. So we'll see what I, I mean, this is an experience report. This is something that I did last year and I'll talk about what I did. I'm not by enemies professing or claiming here that this is the way to go because I don't even know whether what I did was right or not. I'm just sharing it and you be the judge and you tell me if it makes any sense to you as a community here, right? So this is a short session and we'll probably finish it in 15 minutes. I have very less number of slides. And then depending on how much you can hold it off not going to the lunch table, we will still continue doing that, right? So this is about me. My name is Tathagat Burma. I'm mostly, most people call me TV. That's more handy. I'm trying to be a flat TV rather than a curved TV. So that's a fun part of that.  I went to Antarctica. I lived there for 16 months and that's a real penguin there in my hands in Antarctica. So 16 months, one six, not six zero, one six. Yeah, yeah, I would love to go there again. So that's the thing. Okay, so when we talk about coaching what comes to your mind? I just want to show you a visual here and kind of get your sense of it. What in your view is not coaching? Anything that I would like to, I can learn from all of you. What do you think is not coaching? I've just put one visual here. Maybe that probably biases your opinion but I'm just trying to get all of us to think about it. You can call out words that come to your mind when you think of, hey, this is not coaching. This is not something that really I would relate to coaching. So mentoring is not coaching. So that's, okay, you've taken the discussion to a very high plane then. I was just trying to keep it a little lower level and saying this cannot be coaching, right? But I agree with you. I think mentoring and coaching are two different words. Directing is not coaching. Giving solutions, right? So giving something in the hands of people on a simple plate and say, hey, this is a solution. Go run with it. It's probably not coaching. I agree with you. You were saying, come again? If you yell at somebody, okay. So yeah, that's another part of it. Yelling at somebody may not really qualify as coaching there. As we can probably see here, there's an angry coach here. Anyone else? Training is not coaching. So yeah, we heard that once. Training is not coaching. And of course, we all might have different take on that, but I think broadly we agree. Training is not coaching, right? Being not transparent or being manipulative is not coaching, okay? Fair enough. Leading or walking ahead of the team is not coaching in your view. That's leading. That's not coaching. Okay. There might be a very, in my mind, at least there might be a very blurry line between these two things. And there might be on and off kind of a thing there, but I take your point. I'm not saying that that's not the case, but I do take your point there. Dictating probably may not be coaching there. Not actively listening is not coaching as well. I think as coaches, we have to probably have a very active listening capabilities there, right? So that is my personal definition. I think the way I look at it is coaching to me is enabling self growth.  The child is already programmed to grow. The mother nature has already programmed a child. Billions of years of genetics has already gone in. Without you, the child is destined to grow. Make no false impression about it. As somebody who's really helping the child, we can only facilitate the thing. And that's why I mean, in my view, each of these three words, enabling self and growth is important there. So this is at least my perspective of what I look at it from a coaching point of view. So with that, let me just talk about the journey. I will not name the client. This was one of the clients with whom I started working last year. And this is a small company which is duly based out of, it's a software products company based out of India and US. And they, between these two locations, they basically had the team there. Great set of people, wonderful success in the past, and they were really looking at, hey, how can we be more agile? They were not really looking at cheap version of adopting agile per se, but they really wanted to change themselves internally. So that's where I got involved there. And my coaching stance was really, I said, hey, so I was discussing with the sponsor of it and we kind of mutually agreed upon it. I think it was not by design, but we kind of stumbled onto that, which was like, okay, I'll do something. And then I started calling it minimum viable coaching. And I'll explain that in a moment what it means or an MVC. So here is how the MVC, and people are familiar with the whole notion of minimal viable something, right? I mean, this is something that we have learned so much from Steve Blank and Eric Ries about the whole customer development and the lean start of thinking that this whole minimum viable something, something is basically all about the Pareto's law. And the Pareto's law, we all remember, right? The 80, 20 of something, which basically says that 20% of the root causes are responsible for 80% of the effects. So it's basically focusing on vital few as opposed to trivial many. That's the thinking that we have basically. So I then said, okay, I think that's an interesting idea and we probably can take, instead of really having the whole nine yards of coaching happening here, maybe there's an opportunity to kind of pick and choose some of the stuff there and see how we can make a difference to this team. So this is how it happened there. And my engagement was there for about six months. So here is what I did on the month one. The month one, I went there and spent about three days with the team and the first two days, first two days was really about teaching the way, right? I mean, the teams were kind of new to agile. We are thinking and scrum as a framework or something that was chosen. We all were in a room like this and basically the idea was that, let me teach you the way, right? And then at the end of the day, I mean, at the end, so it was not like a regular kind of a scrum or agile training. I'm of the school of thought that anybody who undergoes an agile or a scrum training, at the end of the day, they must come out of the room by defining their own agile process. I think none of us have any business to embrace any ready-made standard agile process because in my mind, there is no such thing as an agile process. It's a misnomer. So what actually happened was that even though I was kind of teaching them the nuts and bolts, the ulterior motive of that session was really to teach them to find their way. So the idea was not to really come prepared with a very canned presentation script and then download everything of them for the next two days and then they go away and start implementing something in a very scripted manner. The idea was that for one and a half day, have an immersive set of conversations, explain the context, not sell it to them, let them make their own informed decision about it and then at the end of the day, have a working session where the teams will define how they want to become agile, right?  Now trust them because here is my school of thought. If you really believe in your teams, you talked about trust, great perspective there. My definition of trust is that if you do not really trust the team to decide what software process is good for them, then you don't really trust them at all. So if you believe that trust is there, then there cannot be boundary lines around it, which means if the team says scrum is useless, throw it away. Kanban is useless, throw it away. Let the team decide what is the right thing for them. Why are we imposing something on them, right? So my point of view was, I'm just going to be there in terms of teaching the way and tell them, hey, these are some of the things that people are finding interesting. You guys decide, and these are the context, these are the pros and cons, this is where it has worked, this is where it does not work and let the people figure out what is the right way of doing it. More importantly, teach them to find their own way. Or even I can go to the extent of saying, teach them how to pave their own way, right? That kind of stuff there. So this happened in the first rendezvous, right? I mean, the first time when I met up with them, we had these conversations and I did that. And the second month onwards, my role changed dramatically. I was only doing a show the way kind of thing there. So I was the lighthouse that was basically coming and telling them, trusting that there is an able captain, there is a ship there, the guys know what they are doing. But once in a while, they might get caught up in the fog and my job as a lighthouse is only to help them and say, hey guys, you need to turn. That's the only thing that I was doing basically. And this is something which was very different from what a lot of us coaches are used to, because this is something that I was doing only one day a month. I was not in situ, located with the teams. I used to travel to that city in the north, I would spend only one day with the team. And during those, during that one day, I would have a bunch of meetings. If there was a knowledge gap that the team had stumbled upon, I would make sure that I would, actually I would start interacting with them like two weeks before that. And if there was something, they would say, hey, we are not really getting it. We have tried that stuff and all that kind of thing. Then I might create like a one hour capsule and we would have some kind of a training. But then most of the time it was like, okay, show me what you have, what are the results there? What have you learned from there? What is it that you want to do? And majority of the times they would come up because these guys were not something, they were not looking for my visits to learn something from them. They were looking for my visits so that they could show something back to me and say, you know what? While you were away, we were able to learn so much. So I would basically go and have a very high level conversations about it and say, hey, you know what? This is what is happening. These are some of the things happening. We would discuss something. Once the team came up and they started. So after one month, they on their own, they dismantled the role of a manager. They decided to self-organize themselves. The managers themselves said, hey, we are happy that we have a framework now which doesn't expect us to be managers anymore. So they had abandoned the role of a manager. The next month I went, they had become a self-organizing team, dev QA all together working as pods together. Nobody was telling it to them. They were figuring out and they were discovering patterns by themselves and doing that kind of a thing. And whenever I would go there every month, once in a day, this was the kind of news that they would tell me. And they basically were not looking for a social proof from me as much as they were looking to basically have a dialogue with somebody and say, hey, we did this and now because of doing it, we are seeing these are the challenges. What do you think would be the way to get forward? So they were not looking for social proof. Don't get me wrong. These guys were young stuff. I mean these guys were, and the results were very astounding. I was something, these were beginning to happen. So for example, in three months, I started seeing that they are, so I will use some conventional measures also. And I'm not saying that I got simply blinded by them. So I started looking at the velocity of the team. And these guys for three, for four or five sprints after sprints, their velocity was like going at 40 degrees slope up. And I said, this cannot be happening. I said, it's a zero sum game end of the day, right? I mean, who's pushing, who's cramming all that work into there? So I went, I wanted to talk to the people and I said, hey, are the people really signing up for it themselves? Are they looking happy? Are they looking cheerful? Is there a kind of a collateral relationship that I can see between the throughput of the team and the employee engagement? Because if these are orthogonals, agile is not working, right? We don't want to really squeeze the juice out of people and say, you know what, you don't matter. That's not the agile way of doing it. So these guys, I was surprised actually when I found that the employee engagement was moving in tandem with the team capacity, team productivity, team throughput. And these were some of the things that you cannot lie, right? I mean, these guys want, these guys already had their number which was working for them. So my engagement went on with them for six months. I was very happy that I had fired myself out of that engagement because I was not needed anymore. These guys had gone to the point where they were truly self-organizing. I mean, the only thing to, the only thing they didn't do to tell the cell, the founder of the company was, hey, we don't need you anymore. Everything else was on kind of a thing there. So based on all the things, let me just share with you my learnings here. These are some of the things, I think these are the five things that I learned from this engagement. The first thing was respect the Kochi. Now I know there is no such word in English language as Kochi, but if you Google for it, I assure you that you will actually find a word with the description that there is no such word in English language. So I think you can bear with me for a moment, right? But I think you all understand. It's like we have created a word mentee instead of prodigy in the mentor mentee relationship. I'm just using the say, I'm just giving a little spin to that word and saying Kochi. I think a lot of times we go with the mindset, as I said, that I'm sitting on this high pedestal and telling people, you know what? I am this great guru in agile and I'm coming here and I'm going to teach you guys how to do agile. I think to me, this is nonsense. Now, to me, the person who deserves the most respect in the food chain is the person who's sitting in the trenches and is closest to the problem being solved there. Everybody else is only doing power pointing. And the more you do power pointing, the less respect we have. I mean, I'm doing power pointing, so I'm careful here, right? But that's just been my thing. And these guys, so this was a group of about 50, 60 engineers and these guys were cross functional. They were about five product managers whom we were kind of aligning them to the thought process of what it takes to be a product manager in the context of scrum. And these guys changed it very well.  They figured out, they would go out on the web and read the stuff and come back and do that thing there. So my respect for this whole conversation has shot up a few notches actually because the more you trust people and the more you say that I may peer to you as a coach, I think it can change the equations in a big way. The second is discard the coach's ego. A lot of times we go with this massive, massive chip on our shoulders is like, hey, I have these like, have you seen those people on LinkedIn whose list of credentials and certificates is longer than their names? I normally take snapshot of it and put it on my Facebook stream actually, right? Because there are some, I mean, these are some very funny conversations like tak, tak, tak, tak, all the alphabet soup and the credential soup is right behind them, right? I think we get into un-voluntarily this whole coach's ego and we get into this point that hey, you know what? I have done this $2,000 certification. How can I be wrong? That kind of stuff. To me, I think the most important advice I have learned for myself and I would give to the fellow coaches is hang your ego outside the door and then walk in humbly. I think that's the best way for a coach to really be of value here. The third was adapt your stance. A lot of times, okay, let me just back it up a little bit. Most of the times we don't even understand and know our stance. We typically have a one track mind and we just go with that thing. I think the first thing is to really understand and say, hey, what is my stance as a coach? How do I really attack the problem? How do I really go with a group of people? How do I really start having conversations and so on and so forth? And then after that, really be able to understand and say, you know what? Probably horses for courses is a better strategy. We may never be able to do a one size fit all and say, come what may? I'm just going to repeat the same thing. Repeat the dose till the patient dies kind of a thing there. I would rather want to do something like a horses for courses strategy. The fourth point, again to me, very important and very dear to me. Teach thinking. Don't teach techniques. Don't teach tools. And for goodness sake, never teach tools. It's sometimes you might have to teach techniques, but I would say if I were you 80% of the times I would teach them to think. That's more important to me. It goes beyond even the whole the Chinese saying of saying that teach a man fishing and he will thank you for the whole life kind of thing. I'm not talking about teaching a skill here. I'm talking about teaching thinking. How do you really go out of the box? How do you really change it? Which is, what I would say is I won't say I'm an accomplished teacher of thinking, but I was an accomplished student of how to teach thinking during this because six months that I was with them, I think my only value addition to them was that I was able to teach them a little bit of how to think, solving their own problems by themselves. And the last thing is enable self growth as I said in the beginning there. I think it's important a lot of times, and I know I've been in the software industry for the last 25 years. A lot of times as a manager and a senior manager, the more number of people report to you that your ego is actually more and more inflated, that you know what, these 200 people, they cannot do anything without me. And it gives a major kick. You talked about the vacation test. I think it's an awesome thing. I've tried that in my career 15 years back. Went on a vacation for two weeks without telling where I am. Team was much more effective without me. I went to the town hall and I told the guy, this is the guy who did better than me, he should be made the manager. I think that calls for a lot of courage for people to accept it with humility and say you know what, people are actually doing better than me, let's give them a chance there. So in my view, it's not important to really say that, oh as a coach, I have to be there five days a week. A lot of times, how many of the people here, since we have a room full now, I just want to do a quick test here. How many of the times you as a coach or you have a coach who's coming in is in your organization, let's say more than three days a week. Can you raise your hands? Okay, so I see about 15% of the hand. Remaining people, is it like how many days? Five days a week, three days a week? A one day a week, anyone? Okay, I see one and two days a week. Okay, few people. Five days a week, anybody? Like your coach is totally embedded with the teams that I see a few hands going up there. A lot of times, it can actually give me a false sense of prowess about myself and say, you know what, I have to be there in the office. I have to be with these teams. These teams will not even be able to do it. Retrospective without me. You know what, I'll say, who cares if they cannot do retrospective today? The point is, if you as a coach do not have a disengagement strategy, you probably are not the right coach for the team anyway. Because you are not grooming the team to be independent by yourself.  So this is how I would see that. I think as a coach, I've got a great opportunity. And again, I won't take credit for that. It's something that originated in the conversations. We stumbled upon one day a month and we found that pattern would extremely well. So one day a month was a pattern in which we would like do the stuff that I talked about there. I just want to end it with one of the famous quotes that I love, if you want to build a ship, don't drum up the people to collect good and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. I think that to me is the essence of coaching. A lot of times we really go and very get fixated on the method process and tool, this is how you have to do daily stand up, this is how you have to do planning poker, this is how you have to do CFD. I think that's not important. That's of no value to be honest. What's more valuable is, if after talking to you, even if it's 15 minutes a day, people go back with so much of charge left and so much of spring in their feet that they want to go out and do something there. I think that to me is much more important than that. So these have been some of my experiences there. Since it's a short experience report, I'll be writing the report and putting it up on my slideshare as well, but this was a small presentation I wanted to talk about. We are done with the presentation. We still have 10 minutes there before the official lunchtime. If those who have any questions, I'll be happy to take them. Six months. Yes. Yes. True. I think the biggest role of a scrum master is to fire themselves. If scrum masters are believing that they are going to be a permanent resident of the team, they are in a wrong business. The first thing the scrum master should be able to see is, and in my view, a better scrum master will be able to, because we have to understand the deliverable of the team is an increment of a software or a working software or whatever we call it. What is the deliverable of a scrum master? Anyone? It's a self-organizing team. So, and does a self-organizing team require a scrum master? I worked with two clients who actually fired their scrum master because they were so good as a team, they said we don't need a scrum master. So in my view, a good scrum master should have a strategy to get fired as soon as possible. If a mediocre scrum master will take 12 months to get fired from the team, a good scrum master might need only six months to get fired. I mean, jokes apart, but that's how I see the whole thing. Oh, absolutely. Yeah, and I think I've seen, I mean, when I was a manager, I used to think the same way that as managers, our job is to make ourselves redundant. If you are not willing to, I was doing one session with the team earlier and I was asking them, do you guys want to get a promotion? I'll give you a sure shot remedy for how do you get a promotion? And that solution was fire yourself out of the job.  Why don't you delegate something to me? Fair enough. I'll just give a indirect answer to that. I spend a lot of time with startups.  Most of them are in an incubation or an acceleration program for something like three to six months, which means in three to six months, they have to come out with something that can be put on the table as a product, something that can get a little bit of traction and something that might be of interest to the VCEs or the investors in some shape or form there, right? And 90% of the time, these are exactly the same personas or the same type of people that you talked about. In fact, much more junior. They are like two years to four year experienced guys there. The problem with us in the corporate sector is that our mental model says that unless you monitor them and micromanage them, these guys will not work. We are still in the theory X. Whereas these guys cross the street, go to and say to help with this corporate thingy, I'm just going to do my own startup. And they say, we don't know, we'll figure it out. We don't, we'll make mistakes. We will learn from these mistakes there. And in the same six months period of time, forget about being self-organizing. For them, this is a matter of survival. If these guys cannot develop something, the burn rate will actually blow them totally out. And these guys will be obliterated completely. So their survival is at stake. Everything that we talk about in the classroom, these guys do that and much more, without the framework, without the jargon thrown in. But in my, and that's where, that's the reason I go to those watering holes. Because I learn so much from them, not from the classroom, not from sitting in an agile classroom, but actually seeing it on the floor of an incubation center, that these guys are actually innovating on a dime. These guys are sprinting on a dime. These guys can change their direction 20 times a day, without worrying about what is agile, what is XP, what is what there. So, and these guys are not just doing at a code level. If we typically look at the whole business model canvas, so those who are familiar know all the nine boxes of that, we are basically iterating literally on all the nine boxes of that. Because your product is the entire nine box business model canvas and not just one single the value proposition that we talk about. So, I haven't given deliberately a direct answer to your question, but I hope you've got the gist of that. The point is, I think we have to change our mindset as leaders, coaches, and managers. Because these guys, if they don't, I mean it's not, what's not important is whether we trust in them or not. What's important is whether they trust in us or not. Because if they don't trust in that, believe me they will just cross over the street, go there and in two years they might float a company and they might hire you as an employee. So that's a call whether you, I mean there's nothing wrong in working for them. They are great, great set of energy, high energy, you know, but that's a call we have to make there. We have to change our mental models of what really makes a team self-organizing. And unless we change that, none of Agile and Scrum is going to work. I would, again, to me, salary is actually a function of the wage market that we are in. And it really depends on that. I mean if you do a startup in the Bay area today, within six months, your valuations, each of the person, if they don't see a valuation of a million dollars, they'll walk away from there. But if you are in Bangalore today, they might start from there and they might reach the same kind of a number in like one year or one and a half years kind of a thing. I think everybody is probably having the same thing. What is more important to me is, as Nareesh talked about Dan Pink's autonomy part of that, I think the whole notion of autonomy and the ownership is to me much more important in the context of a startup, then going up 27 layers in the hierarchy and asking for it, hey, can I buy a photocopy, can I photocopy a page or something? I mean I'm exaggerating for effect. But the point is most of the organizations are, most of the 20th century organizations and management structures were built for efficiency and scale and not for creativity and chaos. Whereas these startups, they thrive on creativity and chaos and not an execution and scale because that is not the problem they are solving today. And that becomes the problem. The moment you talk about efficiency, you are talking about predictability and the predictability can only come when you are going to repeat the same thing 10,000 times in exactly the same manner. So the only way, I mean, how many of you have read here Frederick Winslow's scientific management book? I would encourage you to read that book. He wrote it in 1911 and he actually refers about a guy who was like six foot six, a recent immigrant to the US who was working in Bethel and Steele and this guy says his job was actually to pick those iron things and move from this point, point A to point B. And he says, hey, I'm going to pay you a few more cents. Are you going to pick up more iron in that? And that's exactly what he did. So this guy was built like a bull and he actually said, okay, you pay more money, I do more work. Unfortunately, for last 100 years in our industry, we have just picked up that word from Taylor's book. You pay more money, I do more work. Unfortunately, as Daniel Pink demonstrated, it doesn't work in the knowledge industry. So pay and motivation have no correlation. I mean, sorry guys, I'm a result I know and all that, but money does not motivate us. It is the autonomy that motivates us. An autonomy mastery and purpose which Daniel Pink talks about. So at least I firmly believe that it's not about money. These guys and a lot of guys I've seen in the, I mean, look at the guy, what's his name? The WhatsApp guy, the founder of WhatsApp. I'm sure all of us have read the story about him if he was to stand in the food stamp line and actually get the food stamp and do the stuff there. What kept the fire in his belly going all these years? It's not about the money, nobody knew that WhatsApp is going to be a $20 billion what it became. He just was possessed by the whole idea of solving something and the autonomy that he had in terms of, hey, I am the master of my, I'm the CEO of my destiny. As Robin Sharma says it, Robin Sharma in the book, the leader without title, he says, be the CEO of your destiny. I think that is something which is missing there and that is something we heard about Doc actually talking about the 20% earlier in the morning. I mean the whole 20% of Google which actually incidentally came from 3M. 3M has been doing 15% for the last 60 years and Google basically copied the whole stuff there. The whole idea was that when you do the 15%, it is actually, it's your own baby. It's not your manager who's telling you do it this way, do it that way. It is you who's deciding when to do, what to do, how to do kind of a thing and that actually has a rub off effect on rest of the day because you are able to feel empowered that, hey, this organization allows me to actually take decisions about what I really do. I think we all human beings suffer from a very incurable disease and that is known as reciprocity. So if I am nice to you, there's no way that this niceness will never be reciprocated. You will find a way to reciprocate it back. So if the organizations are good to the people, people invariably find a way to reciprocate that back to the organization. And that's what we saw. I mean, it didn't come in the early morning thing, but I remember when I was at Yahoo, one of the things that we talked about was, hey, this 20% thingy, how does it really, and Marisa had come from Google to Yahoo and this was one of those interviews that came up. So like, hey, 20% means we barely are able to get the work done in, so 20% means that people work 80% of the projects and 20% on that 20% thingy. And the whole thing was, no, that you don't understand this 80 and 20 part of it. People actually don't work 80% and 20%. People work 100% and 20%. The reason why they go out of the way without getting paid extra for that is not about money. It's about the autonomy and the ownership of whatever idea that they want to do that. So I hope I've been able to share some perspective there. I think you had a, instead of this, the Richard Feynman book actually, surely you're joking Mr. Feynman. Because when he was actually, I think he was at Caltech and University of Chicago gave him a job offer to join at four times the salary. There's a very funny letter which some of us, it is not politically correct for me to share in this forum but I would encourage you to have a look at it but the sense of that was Feynman told University of Chicago that by giving, when you pay me four times the salary that you are going to pay me, I'm going to be able to enjoy all the vices that I have always secretly thought of sharing and that will derail my physics research completely and that's the reason I must politely decline the offer of four times the salary. I think it's important for us to know what is important purpose in my life. Money, there will be always somebody who will throw another 10% more and that's a call people have to make. Not so much but now that, I mean I never thought of it that way but now that you asked me, if I have to go to a startup I'm actually much more respectful to the people for what they have done as opposed to having a taking a higher pedestal and saying that you guys don't know because I have a lot of respect for anybody who goes, who has a life outside PowerPoint and is actually able to put something on the table as a real live working product. Whatever domain they are doing it. So these are the guys who are actually when I go and talk to the startup guys and they show something software, it's an app, it's something there. There's one of the team that I was actually grooming. These guys are making robots that do painting for example and these are four bits Pilani graduates, four year pass out. They're just living a dream actually. They're just working day in and day out. They're based out of Hyderabad. They're just doing that kind of stuff there.  What is daily stand up? You guys don't know what to do that never crosses my mind. It's always like, oh this is awesome. How are you guys doing that thing? How about this? And then I have to be in a very, I have to nudge them to think in a particular manner as opposed to even showing a mirror. In a corporate I might actually, I think as a coach my job is only to show a mirror and help them discover their blind spots but in case of the startups it is actually encouraging them because believe me that set of people is the one that their heart breaks 10 times a day. Not too many of us can actually take that level of rejection that community takes actually. So I would say and I asked people actually how many of you go and volunteer your time with the startups there and I literally find the number very close to zero and that's when I really request people from the bottom of my heart. Please go and spend time with these people. It will change your perspective. It will really change you as a person because when you have to face rejection 10 times a day it all the theory of agile and everything goes away for a toss. You come out much better human being, right? So I think my stance is actually more respectful towards what they have done and it's only to kind of say and because again the thing is it's like I think Jared Spool had written that article on the UX thing. What is the difference between criticism and critique? And he gave a very nice metaphor and said most of the time in the industry like code review somebody was talking about it and said code review or some design review the biggest problem in our industry is that there is a bunch of five people who have never spent any time on that understanding the domain. They come and start evaluating the work of someone who has spent last six months working on the design document and they start trashing the work there immediately. That's exactly how the design reviews happen in our industry today. Now that would be the fastest way to lose the respect from those entrepreneurs, right? So you have to be, I'm not doing a favor out of the way and I'm just not being molly-coddling them. I'm actually just being a little more sincere about the fact and being more respectful for what they have already accomplished there. Okay, I think the lunch is served outside. So thanks for being here and yeah, see you around. Thank you.


At the end, we didn't have a fair chance, to be honest, because today, unfortunately, the referee had a bad game. The referee was a disaster. We have to be completely honest. All right, this breakdown is brought to you by DraftKings, and yeah, the coach of Vancouver not happy. His team is down in a best of three series, one to nothing versus LA, and in this game, they're losing one to zero. We're in extra time, they have the corner kick, and they put it up and you see the red shirt? That's their goalie. He's playing up for the extra attacker. The ball gets headed back. Oh, he was setting up for a big kick, but the ref just dropped him. It got in the way. LA has the ball now on an odd man rush. They're gonna kick it, make a nice, easy play to the open dude, except that's off sides, because there wasn't two defenders back. There was just one defender back, because the keeper wasn't there. But he doesn't know that. He's kissing his hand, praising the sky. Meanwhile, they're all over the ref. They're just all over him. Like, what are you doing? Why'd you tackle our player? Hey, that's off sides anyway. You got the call wrong. Hey, two wrongs. Ref's like, get me those. Get me out of here. Oh! Coach is screaming and yelling. Italian coach for the White Caps. Maybe your new favorite coach. He's screaming. Look, they're preying on the sidelines. Please, please take another look. No, no. And then he's screaming and yelling. He says, you messed this up. You messed this. Va fan goal. Va fan goal, he's screaming at him. Red card. Boom, you're out. Sent off. Coach, I believe the other coach got sent off in the first game of the series. So MLS just putting on a show. He's going to kiss the crowd on his way out because he's Italian. Of course, he's going to do that. Thank you for coming out. Thank you for coming out. He's mad though. Steaming mad. Seeing red high fives. We'll give some high fives. They missed. Va fan goal. Oh! Ba da da da dee dee dee dee dee. Ooh, fa. And then he's going to kick this sign. Not the best kick for, you know, your coach in soccer, football. Not the best. Decides not to do a third kick on the crest. Maybe uses crest. And then the referee goes and looks at it and they're going to be like, he's going to say, yeah, you know what? Okay. Whistle. I went to the box. No goal. It was offside. You guys were right about that one. Va fan goal. Ba da da da da da. Anyway, he was so mad that when he showed up to his press conference, he looked like that, but he asked the reporters right away if they were rolling. So JJ Adams tweeted, the presser starts off with Vanny Sartini asking if we were rolling. Hey guys, we rolling? And then they say we're not rolling, but we're a bunch of reporters. So we're probably going to report whatever you say. And he then went on to say that if ref Tim Ford ends up found floating face down in False Creek tonight, the cops might come looking for him. This didn't go over well with the umpire union in MLS. They were pretty upset. They said that was a terrible thing to say. He didn't stop there. He kept saying a lot of things in his post game press conference. And it's really, it's really, it's a good watch. The referee was a disaster. We have to be completely honest. The referee was a disaster. Everyone can have a better, a worse performance than other one. Today they have a worse performance probably of this season. I actually like him as a referee. But if we're being honest, it was a terrible, terrible performance. Now apparently there was other calls throughout the game that were all so bad. Even though this guy is usually his favorite referee, he was bad. I don't understand to be honest, why he didn't stop because every time that the referee touched the ball, he stopped and he gave the ball to the team that he was in possession of the ball. I don't know why we were in possession of the ball and we lost possession because of him. I don't know why he didn't give us possession immediately. Just questioning the rules there, our guy. And I believe the rules are that if the ball hits the ref and changes possession, then yes, he blows the whistle. But the ref is just part of the field, I believe. I did some research, I tried to look this up. It seemed they changed the rules on if the ball hits the ref and changes possession, but they have not changed the rule of if a ref and a player collide, it doesn't stop play. The ref's just part of the field. It's the same thing as a player tripping over the grass. And yeah, I mean, he just, he's going to kick this ball. It's going right towards him. The ref thinks it's going to his left and he's trying to get out of the way. They collide, obviously not on purpose. I don't even think he could do that on purpose. Ref stood his ground pretty well, big tough guy. The press conference gets even better as it goes. Someone asked the coach, they said, hey, do you think your players seemed nervous? I think they seemed a little nervous. First big game, big crowd, this is what his answer was.  It's pretty simple. By the way, no question about the referee to the players. Okay, let me take the old defiance. How about that? Gotta love the Italians and their hand motions. I mean, by the way, don't ask my players about this at all. I just told you, they were nervous because the ref was bad and if you go ask them, if I'm right or wrong, if that's true, you're done. Okay, all right, I like that. I like this, he does the hand, he does the hand motion as he's talking and then he does it again silent, see? No, no, not even talking right there. Just nope, nope. If you were thinking about it, no. Then everything became funny.  We were so focused on defensive set plays that we considered a goal on offensive set plays. Let's put an American flag instead of Canadian, maybe they treat us better. On that note, Coach Vanny, Yohei, he didn't look nervous tonight. I thought Yohei... Thank you guys, gonna miss you.  He came back the next day because he had to apologize. The bad choice of word that I made was to play some self irony on myself and on the behavior that I had on the pitch when I got sent off. In order to play ironically and to remark to myself that I don't have to do these kinds of things, brought me to make bad choices in the word that I chose. To say that thing and sort of for that reason I'm sorry, I should have done a better judgment to choose the right word and but there was no malicious intent and intent or violent intent in my word. There was just a thing that I do every time that is make fun of me when I'm not doing things properly. And that's the reason why I wanna say again that I could have done much better and I did a mistake and I'm sorry for that. Basically saying his tone, we don't know the tone because it wasn't rolling, we just have the tweet about it. His tone was, oh my God, I really lost my head. I really went crazy out there.  If that guy ends up dead, I'm now gonna be a suspect because I just was out of control. And he was putting the onus on him and making fun of himself for losing his mind more so than coming back, sitting down and saying, if that dude's found dead, I'm probably gonna be a suspect. That was the difference of tone. He's saying, hey, I believe him. Still probably, don't say it. Or are we rolling? And then have the answer be yes. So your full tone can be on camera. Either way, ref body slams player, coach body slams ref. MLS is having fun. Thank you to DraftKings for sponsoring this breakdown. And thank you guys for watching. We got a lot more stuff coming out. So if you subscribe to the channel, it'll be a good time and I appreciate that. Goodbye.