The Artistic Science of Building Lean-and-Mighty Security Teams

Hey, good evening everyone. Uh thank you for showing up. Um there is one more unfortunate soul after me who will be talking about policy before you go to the beer. So, please be gentle with them as well. Um I'm Santosh and I'm not going to tell you anything that you don't know already. And uh this is talk is not for everyone. So, unless you're actually leading a security team and you're having some problems, unless you're actually part of a victim of a security team where your ass is sorry, your manager is actually trying to help you or not help you. Or you're in an organization where your security team is actually screwing you. So, whichever way, that means I should

cover everyone here. So, it should be useful in one way or other. So, I'm not going to bore the hell with a lot of text on your uh laptop uh on your PowerPoint, but again, Microsoft and I can't do a death by PowerPoint thing. But, we'll try to keep it interactive and feel free to stop me and ask questions. Um and I want to have this as a more of a discussion. Uh I have with the unique privilege of building and scaling six security startups so far. I'm working on my seventh one. And um I have successful in few and successfully failed at few. So, here I am sharing some of my learnings with you all. Okay? And this

is all about all open uh no, no. It's a closed AI call. So, this is not about AI. So, we're going to talk about human beings. How about that? All right. So, security leadership many times fail because they try to grok the context in which business is operating. What was business is looking for? What is considered to be value for the business? And how business is actually being considered in the marketplace is the very critical piece of the puzzle that people try to fail. One of the things that I'm clearly seeing it as for some reason this is moving. So, we're going to do this in the good old way. Uh cool. So, startups are optimized for survival. So,

if you think about a startup, they are actually optimized to build a product market fit. They're trying to go and take this. So, whether you're building a security team inside an organization where I we normally call them intrapreneurs, like there are a lot of brave souls that I can see in this audience who is leading security teams inside large organizations, big techs, or whatever. Or you're actually a leader of a security team who is trying to build and assist a startup, this applies to both of you. So, we're trying to Okay, cool. PowerPoint is failing me successfully. Cool. How about we do this? Good old style.

Cool. Is everybody able to see well? Okay. You're not seeing anything. Great. How about that? Better? Okay. Sorry, guys. For some reason this is I got a Mac adapter to Microsoft, but I forgot about PowerPoint. Yay. That's fine. We're good. We're going to Okay. Technical problems.

I can't get that work. Yep. All right.

Change your mirroring. Okay. This one. Change your mirroring. That that that's fine. That's that's Yeah, yeah. That's fine. Okay, fine. It's okay. That's fine. We're going to work with this. All right, cool. We're back to building the rocket ship. Essentially, what I'm trying to put the piece in the puzzle. We're building something that is actually hitting the product market fit and we're trying to see that the security features that you're building are good enough to make the product successful to kind of do that. When you miss that piece and when you try to kind of build and operate only in the in the lens of securing the organization without truly understanding the business context in which you are

actually building [clears throat] the business, you fail to you know, you tend to actually go and see some failures. So, this is something that we have seen again and again. So, one of the key areas where I see startup teams and security teams fail is they jump into implementation of solutions without understanding whether that team whether that particular value is actually articulated into the business strategy or not. Sometimes they don't even understand why certain things are like because unless the business sees that it is going to enable and unlock a business opportunity, it actually helps us with a particular customer conversation and a conversion, that is not going to work it. So, zero trust and like patch the hell

thing, everything patch everything within within 1 week. And all these initiatives are great implementation ideas, but it may not be applicable everywhere where you're going into. So, it's super critical for you to understand the whys behind what is it actually that is driving and unlocking the business. Particularly for intrapreneurs, it's the same thing. Why am I given this head count? Why am I actually working on this particular problem rather than something else for the business and how it actually maps to the business outcomes and how we're going to do that. So, if you don't do that groundwork, you're bound to fail in that area. So, it's super super critical for you to think about those lines.

When it comes to your alpha team, super important, you have to think about it as more like a co-founder mindset. Doesn't matter whether you're in a small team or a big team, is your alpha members, the first set of hires that you're going to hire for your team, has to be absolutely like co-founder. When I say co-founders, those are the people who are willing to give up their jobs, give up their comfort place, willing to put everything on for the mission on which you are in. Right? When you're hiring for that team, so you have to be very very mindful of what you're going to do that. So, those are not just bringing skills to the

table. There might be people who write like who are subject matter experts, but they are actually setting up the cultural framework in which your service and your team and your growth is going to be paid off. So, be be very mindful. Do they have that co-founder mindset mindset? Are they willing to give up for the mission? Are they willing to stand in when it fails? Are they willing to have that mindset to iterate and come back and stay with you along the process? Super super critical for you. There are two types of people that you can hire. One are doers, people who will ship and ship stuff. And then people who are multipliers, right? Who knows how to handle things,

how to multiply things, how to scale things. Super tempting for you is to hire all builders early on. That is great, but then you will end up having a congestion of a lot of subject matter experts trying to solve independent problems separately with their excellence without bridging the pieces together and turn it back into the product market fit. So, you may want to be very mindful of builders versus multipliers. Like what is the order? Like say, right? You bring in one or two subject matter experts who can actually turn things, make things happen, and then you bring in multipliers who can actually scale it, stabilize it, turn that into a platform, turn that into a repeatable solution,

something that you can apply and productize and take it forward. That balance is super critical. Right? I've often ended up having sometimes too many experts, right? Individually trying to lift the boulders while while not being able to collaborate with others to try to do that because they're stuck in that box of expertise. Hey, I'm a PKI expert. I'm a network security expert. Right? And then I'm not I'm going to be focused on only that particular aspect without being thinking about how do I uplift the whole thing to actually help the business. Very critical because we have seen some mistakes where we have done where like, you know, it was things. This is one other area you may have to think about.

It your team need not to be have all security experts. Think about hiring people from your engineering teams, your partner teams, your customer teams, right? Um I've hired Barry from Bing to come and help me with Xbox, right? I've hired Saurabh from, you know, customer support team to go and build Windows security team. Very very diverse set of technical and, you know, cultural and context that they will come and enrich your life. The other aspect I want to talk about is investments beyond security. Actually, for your success, there are so many other teams that are beyond security that will be actually playing a critical role in that. Right? Think about all the foundational security things. Think about your CI/CD

security. Think about your developer experience. Think about your, you know, platform teams. Think about the teams that are actually going and shipping the security features. Think about the teams that are actually consuming things. All of these things are outside the security realm that are directly affecting the success of a security program in a company. Often security leaders tend to lose sight of that and they're very much focused inward towards building a strong world-class security team without investing outward on all these different areas of the company that also equally have to be mature. When was the last time a security leader was successful with vulnerability management team without actually convincing a Brazilian engineering teams to actually go and patch and build that

infrastructure to do that. Super super critical to recognize those gaps and recognize those key stakeholder points across your organization where you need to invest resources, time, and effort and alignment for your security outcomes to be successful in the company. So, think about uh one of the first things that comes to my mind is asset inventory, right? So, this was one of the neither we know our assets nor a freaking inventory that actually track them, right? If any company on the planet who actually claims that they got asset inventory right, they're wrong. Right? The second one would be vulnerability management, right? These are the two things, right? That seemingly obvious, but nobody got it right. It is for because if they are

caught because this is not just about a systemic issue about security being doing one or two, it's about investing in the company's cultural transformation where everybody is aligned with the security outcomes and most of the work is outbound. You're trying to convince your engineering leaders, your business leaders to think think critically about their security needs and how you're going to work through that. Right? Lot of the business talk is all about, "Yeah, when can I get FedRAMP? When can I get ISO? When can I get SOC 2?" You're not going to get a SOC 2 without knowing what the hell we're actually trying to protect. "Oh, that's not my problem. That's that's someone else's problem." No, that

is going to be a security problem unless you're investing on it. So, think critically about all the areas that you need to go and make investments for. You need to go and fight head-on for. You need to go and fight prioritization for. And that will actually tell and help you to go and gain that success model that you're looking for.

Okay, this is my favorite thing. So, in fact, I was hired to Microsoft at Salesforce, right? My job description was, "There is friction between engineering and security. Go fix it." Easy. Right? Um so, again, developer experience is amazing. So, that friction between engineering and security can completely kill that option. We have seen yet many many high highly sophisticated, well-built security features and tools have lost its um you know, uh value and adoption because of the friction because of lack of developer empathy, not being able to think through that in the developer ecosystem. On the flip side, right? We had great success with Azure green team, which was amazing. We built the world's dumbest thick client and the world's stupidest

um dashboard that looks like crap. Uh but, it works. And that's it. That's the only thing that works. It works and it looks ugly. It looks crappy, but it works. And when the developers started using it, they saw the value and it just became organically viral in the dev community without security doing a thing except I claimed the win saying like, "Hey, I cleared 150,000 management certificates of of all Azure subscriptions." Now, I didn't do much. Actually, we built a crappy tool, but it works. Super super important to understand where the motions are and think like my wife is a not social media influencer. So, I always think like, "Okay, what actually clicks and what goes viral? What goes

viral in a developer community about a security thing that they are excited about? How do we build that into it?" Super super critical because otherwise, you might be building something great, but it doesn't work. Then the last dimension to think about is scaling security functions is not just about talent propagation. It's also about cultural transformation. How do you going to put the right cultural seeds in your culture? How do you going to curate that culture early on? And how do you going to consciously scale this? Right? We talked about like, you know, external versus internal hiring. It's not just all about just bringing in security experts into the game, right? Having a mix of engineers versus things,

right? We have seen one many times that one client one crack in that foundation will completely ruin security team's culture, its dimension, its trajectory, and its relevance to the business. So, super critical for us to think about, "Okay, what are those cultural norms that you want to protect and prevent?" You have to be very very intentional about it. Lot of people ask me question, "What is culture means?" To put it in a very simple way, the difference between what you think and what you say and what you do. Simple. Some people call it politics. Some people call it nonsense, BS, whatever the adjective you want to use. It's difference between your thought, your verbal articulation of your thought, and

your action. If you get alignment between all these three things right, that's a healthy culture. People say what they think uh you and then people do what they say. So, watch out for those claws and then see like, you know, if there is any um you know, deviations from that. So, some of the uh bets that I it went through in my life, right? So, it's always tempting to see a very brilliant person that comes across extremely talented, super technical, right? Uh and you just get wiped up wiped wiped with that individual and you really want to bring them on. Right? So, one of the core things that you have to be watching for are they

coachable? I have hired intelligent jerks and unfortunately, I had to fire some of them in my career. And I've also hired certain people who were intelligent jerks and then been willing to coach, willing to learn, and some of them have been very very successful in the industry. Right? In fact, Microsoft has one of the youngest uh uh partners in at Microsoft happens to be one of that person. I'm not going to take the name on here, but it's an amazing success to see an individual who was considered to be uh you know, rough around the edges turns out to be, you know, making um impact, right? That is touching millions of and if not billions of

peoples on this planet. So, think about coachability. Think deeply about this and how do you going to do that, right? So, it's it's an investment. And if you can't invest on coaching someone, don't take that risk. It's okay. Right? We may get another person. We may get another mediocre person, but he they might be able to produce the results, but the cost of hiring an intelligent jerk and not being able to invest cycles to help them, grow them into a great well-rounded professional is going to be very expensive. Particularly red teamers in the room, right? They all start with cocky edges on that side because they keep finding things that nobody could think about and

then they get very excited about it. So, it's very very important to think about it. And on the on the other end is the psychological safety. At the end of the day, you want to go and build a team that is, you know, that is feels comfortable. On the same campus two two buildings away, like I remember going to one of my mentors, uh Avi Ben Menachem, and talking about how I'm struggling with uh with someone who is not willing to take feedback in the right way and I'm failing definitely not to help that individual. And he gave me a gift called Radical Candor. How many of you read the book? Cool. So, a lot of people, right? So, he

told me about how my ruinous empathy is actually affecting that individual not to grow and how to actually do that. So, the best analogy that I can think of in psychological safety context is a knife. A thief will carry a knife. A surgeon will carry a knife. Both have the same exact instrument, but the intent is absolutely one is trying to take away a life where other one is trying to make the life. That's exactly that same kind of knife you have called feedback. You need to learn how to apply that feedback with the right intention to help the other even at the risk of that other person's hurting hurting their feelings or being able to, you know,

look like, you know, you're trying to do some harm to them. But the end of the day, right? You're here. You're using that feedback as a mechanism to make them better and help succeed uh in the circumstances in which they are in. Super super important and you have to be vulnerable. You're you have to be willing to be vulnerable. You should be leading by example. So, if you screw up, you should be able to do that. Right? So, I had the unique privilege of bringing down Xbox Live uh at Microsoft because I'm so excited to applied new uh updated version of tripwire and that didn't go well. So obviously this is that's the learning right like

then I actually spend a lot more time in in in with the autopilot team in Xbox to how to how to actually deploy and scale and you know in a in a in a regional way so that like you know in case if something goes wrong we have a mechanism to stop roll back etc. This is 10 years ago nowadays it's all common but back then we have learned some experiments with a lot of expensive mistakes. Putting things into context essentially think about your business context. You've been hired and you've been given the responsibility to build security teams because of your technical chops. Now your job is to actually understand business. What is sales doing? What's

marketing doing? What is legal doing? What's HR doing? What is you know product doing? The better you understand that you will fit your security narrative into that and that is how you will help the business to gain momentum. Of course the first set of hires are going to shape your trajectory super super critical for you to pick your choices and be in the There is a reason why I said it's artistic science because it's not a science. It's not complete art either. So you have to go learn experiment and operate and feel free to be convection have a strong conviction around that. Again investments outside security is is a big piece of the puzzle. So many times

we tend to look inward and trying to feel like where am I filing? Why am I filing? Did I hire the wrong person? Did I pick the wrong OKR? No, think broadly what are the external investments that you need to make to make things better. Even if you have to lose a good candidate for a partner team probably that might be a good thing because they're going to help you succeed in the long run. And then again so don't lose sight on your cultural nuances. It's super super critical for you because that's going to make a big difference. With that I'm actually opening for questions. And then you have an opportunity to not let me come back to you as the guy who

cannot actually make PowerPoint work. All right. So sorry. Yeah, okay. So Hi. Sorry. Yeah, I want to make sure. Yeah, questions please. Yeah, Carson. Hey Sandesh. Thank you for sharing. I remember your startup culture good talk. One of the phenomena that I have experienced as a manager is I have this very strong connection and empathy with my team and as a consequence that sometimes prevents me from delivering difficult messages especially when they're people I believe in. Further it sometimes gets in my way of believing oh maybe next semester they'll do better. So how did you and how do you all see others reconcile the need to show empathy and togetherness and safety with their teams especially when they are

executives with the need to say look this person is performing. Yeah. Now if you're a parent it's easy. Right? And then if you're a parent for a teenager it's going to screw the hell out of you. So I've been both. So yeah, I Carson's question is like how do you balance between empathy and actually still driving meaningful outcome. So I think it all starts with the intent. So most of the times what worked for me is I start the conversation with the intent. Hey, my intent is to help you succeed. And I'm already recognizing given the position at which I am in right? I recognize that it is not actually going in the right direction.

And then I will pause and say I'm curious to know do you even agree and do you have the same kind of alignment in that. Most of the times they may not even agree that there is a problem and then you go straight with a solution screw you. So you got to pause and let them actually ideate and see like if there is a common agreement yes I think this can be better. We can optimize this. We can go better. Once we agree upon that like the problem is thing and then your intent is to actually help them. The third dimension will automatically pop up where you can have the figure out the mechanisms to do that. Yeah, that's

why it is an art but I have seen that happen right? When we when I didn't do step one and two it definitely backfired. Yes, please. Something that we struggle with where our mission which is I'm really fond of where we really want to hear. Uh-huh. It's we can support pretty often the problem of mental health and tech support so contractors or Yeah. In your experience doing that we already have that situation as well. Does your approach still approaches Does your approach change at all when it comes No, I I think see contractor versus FTE versus TPM versus engineer we're all human beings. We're all actually working on the same mission. You should treat everybody in the same

way. Of course there are pockets where you're not going to share certain information etc. etc. Like I have my TPM always joining my my stand-ups every time. I actually treat my TPM like my direct. It doesn't matter who he reports into because he's a critical part of my machine mission. The same thing with a contractor who is actually augmented to a at all. So we know as security people how to compartmentalize security information versus when we treat people I think I will draw a much bigger circle. As the longer the circle the longer inclusive you are the better it is for you compared to the other way. Okay, we're at time but I'll be here

more than happy to take any questions and if you want to kick me out please fill the form. Right? See you. >> [applause]