2. Andrew Gontarczyk, CISO of Pure Storage: Building a Security Team

Welcome to the Security Podcast of Silicon Valley. Thank you for joining us on the podcast. I'm here with a very special guest, Andrew Gontarczyk. Did I butcher your name?

That's okay. It's okay. Gontarczyk. Gontarczyk.

Andrew Gontarczyk. There we go. He is the Chief Information Security Officer at Pure Storage. For those of you who don't know Pure Storage, Pure Storage is a storage company that revolutionized the way storage is thought about.

They introduced flash compression and they go after the enterprise market, so definitely B2B sales. Fairly recently had gone public and now here they are with Andrew leading the security efforts. So thank you. Thank you, Andrew, for coming on board.

Thanks for having me. You bring a lot of great experience to the table, including, I see you're at Symantec, previously Vice President of Information Security. Before that, lots of experience in the security world and the financial space, along with a great stint at IBM. So I'm humbled to be in your presence and thank you for joining us.

Thank you. So today's show is going to be about building a security team, a world-class security team. And so how does a CISO build a world-class security team? Or, you know, even maybe a better question is, how and why do you know that an organization even needs a security team?

Yeah, look, it's an interesting question because, you know, I guess there's a lot of, in the security space, there are a lot of, you know, standards and things that you can reference that tell you all the things that you need to have in place. And we can kind of talk about that a little bit. I think those things do have value, but the bit of your question around what sort of team does a company need and when do they need one, I think is, for me personally, it's been quite a sort of epiphany, maybe, for me since I came to the U. S.

As you can tell by my accent, I'm not a native. I moved to Silicon Valley three years ago for the Symantec gig. And being not from a tech company background, like being more sort of corporate security and what have you, and also then through the work that I did at IBM doing a lot of consulting to industry, I come at the security problem probably from a more traditional security standpoint rather than from an engineering standpoint. And what's interesting with that, especially in a place like Silicon Valley, is that it's obviously very engineering focused and engineering driven.

And so, you know, the question then comes, especially for me with working at Symantec for a while and then the Symantec sold their enterprise business and that sort of came to an end. So the team that came over, there's a bunch of us that came over from Australia to help them with their security journey. That all kind of got dissolved. So we had to go find new homes, which I was fortunate enough to find a new home with Pure.

But what's interesting is that, you know, you kind of look at yourself and go, well, what's my value proposition in Silicon Valley, especially since, you know, it's such a tech heavy environment with so many really, really smart people. And so, you know, I personally felt a certain sense of inferiority and awe at the mega brains and the super smart people that were there. And the conclusion that I drew, and actually my old boss at Symantec, who's now the CISO at Okta, we discussed this a few times. And I think the value proposition that we bring, and this sort of goes to the what sort of organization needs, what sort of security team, is that I think our sweet spot is we're builders.

So we like to build capabilities and we like to do those sorts of things. And I think tech companies go through a phase of, you know, they're at the first early instances of being a startup where it's really focused on building the product, getting investment, feature, function, and all those sorts of things. Right. And typically security in those, in that phase, isn't high on the priority list.

Now, it depends on the product. Like if you're a security company, then typically there are some security thoughts there, but they're very much more from an engineering standpoint, right? They're driven from the perspective of, I need this security feature, et cetera. And so, you know, assuming success and traction, you know, the companies then go public.

And depending on where they're at, they're still probably selling to smaller end of town to the more sort of commercial side of things. And then as they grow, they want to get to more enterprise. So deals and customer base and enterprise customers have higher demands from the perspective of just the boring stuff. You know, the, have you got policies?

What are your processes like? Do you have incident response? Do you have monitoring? Do you have all these things?

is that, as I mentioned at the beginning with the standards, do you do all that stuff? And so, you know, I think my sweet spot is that helping companies with that transition, right? Because it's a build, it's typically kind of greenfields from the perspective of security capability, but it brings, you know, the team that I kind of set up and the capability that I am trying to establish is for that next phase, that next chapter in the company's journey where they can start to evidence those things and, you know, start doing all that security goodness that customers expect from a trusted company and from a trusted brand.

And so, you know, I think companies in the early stages need to be cognizant of security and need to try to do their best, but I don't think you want to be over heavy-handed with those things just because it gets in the way of growing the business and getting investment and actually getting traction and being successful. But there is a time where you will have to catch up if you want to go after the bigger end of town because security, you know, as we all know, is such a huge, huge topic. All the boards, all directors, et cetera, are talking about it. It's in the press.

So you can't not get away from it. It's just a question of timing. That's a long-wrangy answer. I hope that kind of.

. . That's a great answer. You know, I really like this idea, actually, of when is the right time to land a security team like this?

And it sounds like you're suggesting that the right time is when you need it to secure your next phase of top-end growth, when you're losing deals to security teams in other companies that are saying, hey, where's your processes? Where's, do you have a SOC 2? Do you have, you know, HIPAA compliance if there's a VAA in place or something like that? And to really drive that growth forward, security is important.

And you use the word trust several times in, you know, you're talking about trust with your customer. Even the perception of being a trusted brand can be one of those things that that's very delicate, right? So in terms of the different flavors of security, when I think of security, I think of maybe product security teams that build features into the products that a company ships. And I think of also maybe infrastructure security teams where we're securing our own in-house infrastructure and bringing processes and remediation to whatever happens to be in our own infrastructure.

Just the tools that we need to run a company in-house. And then, of course, there's red teams and there's blue teams. If you want to talk about sort of the defensive, offensive, the feedback loops that we, but in your experience, is there, when you build out a security team, do you want all of those pieces in play or do you look for a particular type of security team that get the dynamics between these different types of security teams interacting with each other? Yeah, so it's interesting.

I kind of use the analogy of the sausage and the sausage factory, but then I've also, I think I've evolved that more to the car manufacturing plant and the car, which is kind of the same thing, but the ingredients of a car are a bit more tangible than different herbs and spices and meats and other things that you put into a sausage. But the analogy kind of goes like this, right? So let's stick with the car manufacturing plant and the cars. You want to make sure that the cars don't kill people.

So the cars need brakes and they need to be well-engineered. The cars need all the safety features. They need a good engine or whatever it's electric car, et cetera, et cetera. They need all those bits and all those bits need to be designed and engineered and all that sort of stuff.

And to me, that is the sort of product security side of the house. And there's two dimensions to that. So one is the feature design and build. And the other bit is making sure that the security requirements are injected into that work as well.

I kind of, you know, my background is fundamentally architecture. So every problem for me is an architectural problem. And so, you know, in that engineering side of the fence, you want to make sure that you have a good set of what I refer to as security non-functional requirements that everyone should be sort of applying to. So the difference here is, say, you're building an authentication feature, like you're going to build MFA.

So that in itself is a security feature, but that feature needs to have auditing. The administration of that thing needs to have appropriate authentication to be able to manage it and configure it. It needs to have integrity and be compartmentalized so it can't be modified or compromised as a feature itself. So every feature has a bunch of security requirements on top of it.

So I put that into the car piece. And then the other bit from a security standpoint that the team has to solve is the actual factory. You know, you've seen the footage of car manufacturing plants. They've got those big robot arms that swing around and move cars and da-da-da-da-da.

And whilst there's people in those factories, there are people. in those factories. And you want to make sure that those machines don't kill the people by swinging randomly and electrocuting somebody. You want to make sure that the cars, that the welds are solid, that the particular level of QA and all that sort of stuff.

So to me, that's from a product and engineering standpoint, that's sort of more the CI/CD side of things. And then to your point, the infrastructure piece, right? So just like, what is the ecosystem that it lives in, whether it's AWS or on-prem or Azure or what have you? How are you doing all that?

How are you doing your account security? How are you doing your, you know, gold images and builds and all that sort of stuff? So that really got nothing to do with the car slash sausage, but it's got to do with, you know, are you securing the front door of the factory? Does the machinery have the right power, the computer systems that support those robots, are they secured?

Can they be accessed externally, et cetera, et cetera, et cetera. So, you know, so for me, the scope of security is not just the factory and it's not just the car, it's both and they both have to kind of work. I think from a sort of mental standpoint or philosophical standpoint, the principles are kind of the same. You know, that authentication feature example applies to everything, whether it's any widget in any dimension, you need to think of what are the security requirements around all those things that you need to solve for.

But it's very much build and engineering. And then the rest of it is really around the assurance that those things are there. So in my team, we have a product security team, which is focused on a lot of those areas and we can go into that a little bit in the talk, in the conversation. We have an security operations team, which is focused on sort of two things.

That's sort of the blue team type elements, some offensive security elements, but also the operational running of our security tools. So just for our listeners, what is a blue team? Right, so basically you'd have two dimensions, right? You've got the defensive and the offensive capability from a security standpoint.

So the red team is the team that attacks. And, you know, there are plenty, you know, depending on the size of the organization, a lot of larger organizations will build their own red team capability. And their job is to basically simulate real adversaries. So in the sort of offensive security space, there's, I guess, three layers in my view.

I'm sure there's more and I'm sure there's a lot of people that'll correct me and there's better ways to think about it. But I have a terrible habit of oversimplifying things. But you've kind of got vulnerability scanning, which is just the machine knocking on the door of every piece of infrastructure, just making sure that nothing's stupid there and you've got the right patch levels and all that sort of stuff. And typically those vulnerability scans are the first step that a penetration tester would use to identify any potential kinks in the armor that they can exploit.

And that's penetration testing. So it's very fixed scope. You've got a couple of IP addresses or what have you, and you do what you can in the time that you're given to find as much as you can and do as much as you can. And then lastly, there's red teaming.

And red teaming is another way of referring to it as objective-based testing. So you would have an objective of compromise the CEO's laptop, you know, steal their email, for example. Or you could have compromise our source code or how susceptible are we to ransomware, for example. So very targeted attacks.

So targeted attacks. And those, you know, depending on budget, are limitless from a time perspective and limitless from a resource perspective. And they can do whatever they want. So, you know, I've worked with red teams that have done the USB drop in the lobby of an office to get into people's machines.

They do phishing and they do all that sort of stuff. Because typically what you'll find is that most organizations, because there's so much good information out there, will do reasonably well unless they're completely negligent or just under-resourced to close down the outside. There's not going to be anything overly stupid that'll allow an attacker to get in through the direct front door because they've got locks on it and all that sort of stuff. It's the people thing, right?

So phishing and all those kinds of things is usually the way that they get in. And then that tests your defense in depth. You know, if you've got good defense in depth and good detection, if someone does fall victim to phishing or spear phishing, they, you know, hopefully you'll be able to detect it and what have you. But that's usually how they'll get in and then they'll go through environments and exploit that.

And then depending on how good your internal security is, depends on how long it takes them to achieve their goals and objectives. So that's the red team. Your question was about the blue team. The blue team is effectively the security operations center.

So their job is to detect and respond to what the red team does or more importantly, to what a real adversary does. And the point of the red team and the blue team is kind of referred to as purple team, which I find kind of a bit strange as a name because it's more of a process rather than a team per se. I guess maybe it's the two colors just mixed together. That's exactly right.

But the idea is, you know, you do a red team and then you train and teach the blue team what you did, and that helps them write the detections and make sure that they cover the gaps of what have you that they have in their detections and ability to respond. You know, security is fundamentally, security is a process. It's all the journey. Yeah.

It's a process that you keep on iterating through, you know, like that's sort of the offensive defensive thing. But the other part of it is governance, risk and compliance. And how do you measure and justify investment in things? That's all risk-based, you know, like where we started with this conversation is when do you need a security team?

You don't need them day one. And the risks don't justify the reward. You know, being a security boffin, yeah, make everything super secure from day one. But that's not practical and it gets in the way of the business.

And so you've got to let the business grow and have something tangible that is worth investing in to secure. There's no point in investing a lot in securing into something that doesn't really exist yet. And so the risk part of the business, which of the security function is, I don't know, I think a lot of technical people find that stuff really boring, but I find it extremely valuable, mainly for the fact that it is the function that helps you demonstrate the value of security. And it also helps you motivate and drive security across the organization.

Security is a team sport. One of the things about security that's interesting is that the security team itself doesn't actually do the bulk of security work. It's the rest of the organization that has to. Because you don't own everything.

Security people are the technical people, et cetera, but everyone else owns the infrastructure. Everyone else owns their business processes. Everyone else owns their product. We don't own the P&L for those things.

And so our job is to influence. And the best way to influence is with metrics and data and visibility. And that's where the governance and risk and compliance kind of functions come in because they're invaluable for that. And I think a lot of people don't invest that much time in that.

And I've noticed in Silicon Valley, risk is generally, and risk management, especially in the younger companies coming up, is not a very front of mind thing, which I get, makes sense. It's sort of beginning that evolution. But I think for having a successful security capability, having some investment there and working out with your stakeholders what's important to them and what makes sense to them, which because it's going to be different in every organization, I guess that's the sort of black art and magic and lack of science, but more art to the equation that you need to kind of work through in terms of, well, what do I get? What do they want to know?

What do they want to know? What's meaningful to them? And hopefully you've got good leadership that is actually hungry for stuff rather than people that aren't. And, you know, organizations that have security teams to tick a box, like they exist, but there are also organizations that are very genuinely want to make sure that security is well looked after and they ask good, insightful questions.

And, you know, I'm blessed at Pure to have that. So I have a very captive executive that care, that they really care and they ask good questions and it gives me, it makes my job a lot easier, right? Because it's, I have specific questions that they want answers to. So it gives you good things to focus on.

I'm super happy to hear that. You don't find that in every place and it can introduce internal challenges that you have to navigate. Then you have to throw into the bucket of stuff that you're dealing with anyway, but having a captive audience and the willingness to move forward together can go a long way. The rest of the security is often the tail wagging the dog, right?

And, you know, the risk that a lot of security people have, like pure play security people, which I am one of, I've had, I guess I'm lucky to have had the broader experience in financial services and things. There is a tendency for a lot of security people to be all doom and gloom, the FUD kind of fear, uncertainty and doubt, not necessarily deliberately, but that's just the way that they think. It's a mentality. Yeah, sometimes.

Yeah, right. And it's not very constructive and it's sort of devoid of the business aspect of the equation of, do I really need that right now? I get that this is not the greatest outcome, but we've got to focus on prioritizing our resources, both from a people perspective and a financial perspective, and we need to balance. And, you know, the business is all about taking risks.

And I think some security people don't, they just don't think about that all the time. It's not front of mind for them. And it leads to a lot of frustration. They go, why aren't they doing blah?

This is crazy. And so, well, because they've got a thousand other priorities and they've done a little bit here, but cool. If it's not enough, well, we're here to keep on motivating them and driving them to do more. But that's the kind of ongoing sort of challenge and balance of the gig, right?

Yeah, no, for sure. I know exactly what you're talking about there. I mean, there's two types of security folks out there in the world. There's those that will walk into a room and everyone else.

The room will be like, ah, good. You know, Andrew is here. He's going to help us build what needs to be built. He's going to help us collaborate in a secure way, and we're going to meet our deadlines, and we're going to ship this awesome product, and we're going to meet our rigorous security standards, and it's going to be nice and consistent with the rest of the, you know, the security story that we're sharing with our customers.

And then there's, you know, the type of security folks, which, you know, I've bumped into them here and there, but much less frequently, but you step into a room and then the perception that you bring with you is very much negative. It's like, uh-oh, they're just, he's going to shoot it down. They're going to say no. And then it becomes more difficult, actually, to build those relationships and influence the business in a direction that's healthy for security and the business together.

You've got some background noise. I have a little bit of background noise here. That's okay. So tell me, Andrew, when you're trying to fill one of these roles, because a large part of being a leader is, you know, building teams.

And so when you're team building, you know, what's the most difficult part of filling one of these open roles? What do you look for? What's hard to find out there that you really think of as critical and important? Yeah, that's a really good question and a really difficult one to answer.

So a couple of things, right? The classic answer to this is it kind of depends on the role. But for me, I guess the most important thing that I'm looking for is ability to execute and deliver and people that take accountability for things. And, you know, the thing that's associated with that is obviously their personal interactions with other people.

So, you know, the example that you just gave, you walk into a room and there's people that people will be very open armed with and go, thank God you're here, versus the people that are just going to tell you that you can't do anything. It's all insecure. And the best thing for us to do is just shut down the company so there'll be no risk. You know, I think security, again, very cliche, but we do need to think of ourselves as an enabler.

And that means sometimes agreeing to and endorsing positions that might make us uncomfortable. A willingness to compromise will go a long way, right? That's right. And, you know, the concept of compensating controls.

Like you need to be holistic in getting the outcomes that you need and you need to work with the business to balance that. So for me, I want a team that delivers and executes, right? That delivers on what we say that we're going to do, that is proactive and, again, is viewed as an enabler to the business and is viewed as valuable and contributing rather than sort of a drain, right? And I think so from a personality standpoint and what I look for and from a resume standpoint is somebody that can give very clear examples of what they did in things and what they were accountable and how they kind of achieved it.

And then the other bit to that is just the sort of personality, cultural fit. Are they going to be good in the team? Not just in a security team, but more broadly. Obviously, you know, in my role, I'm hiring kind of more senior level people that are leaders in the team rather than the more technical engineering folk.

I think they're probably the two things is execution and delivery. You know, one of my pet peeves, I guess, is just people that talk a lot, talk a good game, but don't deliver anything, don't roll up their sleeves and actually do any work themselves and think, well, my job is I'm the manager or the leader. And so everyone else does work for me. I'm just going to push stuff left and right.

You know, don't get me wrong, as a leader, that's a large part of the job, but you need to be able to get your hands dirty. Yeah, roll those sleeves up, like not be afraid to get a little dirt on your shirt or on your hands, right? Exactly. I mean, that's where the rubber hits the road, right?

So even as leaders, I think it's important to understand the little nitty gritties of what's going on underneath the hood, the details and the grit. So, I mean, do you have a favorite interview question that you like to ask? I have two. Well, another guy that I used to work with in Australia, we both, over a beer years ago, we were talking about, we have this one particular question that we ask and it really sorts people out.

But this is more in the sort of architecture technical space. And then the more generic one, which I like, is the, just tell me what your first 90 days are going to be like. Like, what are you going to do in the first 90 days? Oh, that's good.

Oh, that's good. Very open-ended. But what's interesting about that one, and what surprises me is how many people answer that question badly. And it's, you Google anything, there's a book written, The First 90 Days.

Like there is plenty of literature about your first 90 days. So if you can't have a good answer for that, that's problematic. And I think that one addresses the execution, delivery, and accountability piece. I've had a lot of people that I've interviewed and really for the first 90 days, they're just going to be meeting people and getting their lay of the land.

To me, that's a fail. That's your first 30 days. Your next 30 should be formulating a plan and a strategy. And your last.

. . 30 should be kind of locking that in and getting traction on it. You know, like, what do you love?

I love that word, the traction. That's a beautiful word. Well, I think it's important, right? Because if people come in and talk to you and go, well, I'm just going to meet people and get a lay of the land and meet people.

It's like, how is that helping the organization? That's great for you, but that's not really helping me or anybody. It's just. .

. And 30 days is quite generous to, you know, just meet people, you know. Look, and all these things are kind of loose and fluid, but I think, you know, at the end of a 90-day plan, you need to establish yourself in the organization, especially at a leadership level. What do you stand for?

What are you here for? Yep. What are you going to, where are you struggling? Like, I think it's also important to call out, look, we need to get all this stuff done.

There's no way we're going to be able to get this done for reason X, Y, and Z, or blah, blah, blah, right? You need to, by in 90 days, be able to have some real conversations around what's going to be good, what's going to be bad, where do we need, where's opportunities, blah, blah, blah. Hey, I need to change the team. I've looked at it.

This team's all wrong, whatever, or this team's great, but I need more people. Yep. They're the sort of conversations you should be able to have within 90 days. If you're coming in and just telling me that I'm going to meet people and talk to people and get a lay of the land, that's too long.

So that's one. That's the general sort of leadership thing. The other one for me, which I think is a great security question, and it's helped me sort out a lot of different candidates, is I draw, and now I do it on a Google slide or a PowerPoint and share my screen, obviously, because we can't do it in real life. But in the old days, I would get on the whiteboard and draw a really simple three-tiered architecture.

And you could argue it's a bit old school, but it works. I probably need to refine it a little bit to be a bit more modern, but it's basically presentation layer, app layer, database, internet, and a user with a line through all of them, right? It's basic 101, three-tiered app. And then I just hand over the pen to people.

I'm giving away a lot here. I hand over the pen and say, secure it. There you go. And it really gives you a sense of how they think about security.

Like, what are they thinking about, you know? And do they understand certain networking and zoning and stuff? Do they understand authentication and authorization, user provisioning, and all that sort of stuff? Do they understand logging and monitoring and all that sort of stuff?

Do they understand, you know, the integrity side of things with resilience and, you know, HA and blah, blah, blah, blah, blah, DDoS, all those sorts of things. And so it's sort of, I use this for architects when I hire architects. It just gives me a very good sense of someone's breadth and also, again, it gives you a sense of. .

. Yep, as well. Like, you could dig into that too. You just keep on asking, like, for one more layer in and one more layer in before you know it, I'm sure you're looking at assembly, right?

Well, you could. Absolutely, right? Absolutely. And, you know, it's just, and it also gives you a sense of their ability to solution and actually contribute.

Because if they can't answer that question and don't know what they're doing, then they clearly don't know how to solve the problem. And then if there's a team that they need to help do that, they're not going to be successful in doing it, right? So it's sort of how do you, you know, it's very simple. Here's a simple business problem.

It's a web app. Yep. Secure it. Yep.

So they're my two that I think. . . That's great.

They're two reasonable ones. Those are great questions. When I'm thinking about security teams, one of the things that I often think about is the diversity. And I know we often think of diversity as racial diversity or sexual orientation and being part of diversity.

And those are important pieces to diversity, but everyone brings a unique piece of diversity to the table. And even if it's something as simple as having, you know, both green team members and very senior team members on the same team, I've noticed that when you have a very diverse team, you have a lot of different perspective that is brought to the table.

And as long as you foster a culture of openness and humility and always learning and always hungry, which it sounds like you do, then a disagreement now becomes an opportunity for someone to learn something new about how the world works or see the world from a different perspective of here's a perspective of the world where that's not a problem anymore. So any special diversity efforts that you make when you actually are building out the team? I know sometimes we just, we get what we get when we're hiring folks. So, you know, now we're going into some really philosophical dimensions of the conversation, which is good, right?

So a couple of things there. And a personal challenge that I'm going through with regards to recruiting at the moment, but just more philosophically, diversity is. . .

Interesting subject because I think outwardly, diversity is described the way you just described it in terms of sexual orientation or race and what have you. But if you have. . .

Gender, yeah. And gender and what have you, right? Yep. The issue, though, with that, and I was listening to, I think this was in The Economist a little while ago because I do a lot of bike rides, right?

So I just ended up The Economist and there was an article talking about this. And they were saying that, okay, but if you have men, women, you know, different sexual orientation and races all coming from the same university, is that really diverse? If they're all the same socioeconomic background and went through the same college system, then yes, on paper, you've kind of ticked these boxes that people refer to, but that's not necessarily diverse, which I thought was an interesting, oh, yeah, interesting point. That gets you thinking, doesn't it?

It really, I thought that was a really interesting point. Yep. So in terms of the dimensions of diversity as currently described in organizations, I think I'm really supportive of them. I think any of those sorts of things you can look at and you can poke holes in all of those dimensions, but the long and the short of it is the intent of them and the overall outcome, I think, is the right thing to do.

And I think focusing on those things is important. But to me, they're less important because the most important thing is what you were talking about is diversity of ideas. And I think for me, one of the challenges of being in my role now as being the CSO is, and I think this is the beauty of being more junior in a team, is that I'm kind of expected to have the answers. And I don't like personally to have, to be the guy that sits in a room.

Like I'm a guy that sort of, I think one of my main strengths is when there's people just floundering and not really sure where to go, I'll just go in and make a call. But that's what I'll do. I'll just go, okay, guys, we've got to move, so let's move. Yep, that can be very helpful.

It is, but what I struggle with is when no one, like I really like people to challenge me. I like people to give me an alternate position or ask me questions because the problem is, oh, I'm the boss. So people kind of sometimes, and I've seen the suspicion in the financial services where it's very, very hierarchical. People go, well, I can't raise this.

And I openly kind of encourage people to challenge me, to tell me if it's a stupid idea or if they can make my idea better. And so I think, you know, having diverse opinions and more importantly, having the freedom, because I think, and again, getting very philosophical, but every opinion is a diverse opinion because it's not yours. Right. Right.

So, you know, I think the diversity thing from the perspective of what we described earlier, I think that's just a human goodness angle of be good to human beings. Everyone is a human being and they all have a right to be here and we shouldn't discriminate on any level. And we're all part of the same species. We're all on the planet and we all have an equal right and for the opportunities and things that we do, right?

So that's one part of it. And I am fully supportive and encouraging of any measures that are done to break down a lot of existing stereotypes and, you know, prejudices that people have just from a societal standpoint for generations of how we've gotten to here, right? And that's, I think it's naive to ignore it and assume that it's not there. It is there.

We need to actively work on it. And everyone has their own biases and all that sort of stuff, the unconscious bias stuff. Everyone has it. Again, you're a fool and naive if you think you don't.

And you need to be aware of it and you need to work through it. But that's one part. The other part is, I think, you know, for me culturally in a team and how it works, you know, it is important to encourage people to ask difficult questions. It is important to feel empowered to do so as a more junior member of the team.

You know, like I'm sure everyone does this and I've done this numerous times. We're sitting in a meeting and you have this view that I should know this, but I don't understand what they're talking about. And it takes a fair bit of courage to actually go, hang on, can you just, I don't understand, what is this bit? I don't understand this bit.

Right. And I've got to tell you, for me, 90% of the time when I've done that, a good two or three other people in the room go, yeah, I was wondering the same. That's a great question. Like, what are we talking about?

What is this? What is on the board? I'm so sorry. I don't understand.

Please help me. Exactly right. And, but again, usually you're not the only one in the room that feels that way. And so I think, yeah, so I don't know.

I don't know. I think diversity of ideas is just creating a safe space for people to voice them. Yep. Ask the stupid questions.

And if someone asks genuinely a stupid question, don't make them feel. Like they're learning, right? Everyone's learning and all that sort of stuff. And I think you just got to be really encouraging.

And, you know, for the most part, like, you know, my philosophy is creating space. I don't know whether I'm that good at it, but that's my philosophy. My job as a leader is to create space, so to kind of engage with the business, engage with my stakeholders, constantly grow our scope, constantly grow our influence, which fundamentally translates to creating problems for us to solve. Right.

That's the definition of space. And then the rest of that goes to the other team members to try to fill that space. And hopefully that space that excites people, gives them things to do, and keeps them passionate about what we're trying to achieve. But I don't see my job as micromanaging and all those sorts of things.

Yeah, I don't know anyone that likes to be micromanaged either. And that idea of creating the space, just setting up the motives behind the scene, the context for the business to move forward, for everyone to see how their individual contributions add value to the business and are not just adding value to the business, but are interesting and challenging along the way, right? That's where I've seen really great stuff happen. But you know, we're talking in the security space, but that applies, I think, across the board very philosophically.

And it's great because everyone retains a strong sense of agency. You know, everyone is able to make their own decisions. And when you're able to make your own decisions that are aligned with the business interests, but you're still driving it, you're owning it, you have a strong sense of ownership over all of that. And that's where the magic is.

That makes me really happy to hear, Andrew. I mean, look, like I say, that's philosophically how I think I am. I try to be. I'm sure I'm not perfect at it because, you know, the balance there is that whole getting stuff done.

And sometimes you give people a lot of space and they flounder and they don't get on with it. So you've got to kind of lean in a bit and help them and go, guys, okay. Well, time is an important part of the space too. Like Einstein got that one right.

Theory of relativity, space-time continuum. We're bound together. So there's no decoupling those two things, right? That's it, right?

But I think what you just said there about accountability and ownership, like that's what people get excited about where they have their accountable or something and they deliver it and they go, look what I made. That's a success. Yep. Without first a bit of struggle, like there's no success there, right?

So how about a tough question? Don't feel obligated here on this one, but there's one thing that keeps you up at night. What would that be from a security? That's a really easy question.

Oh, is there? What I don't know. So the problem is that with every organization I've ever been in and from a technology standpoint, things are moving so fast. Things are growing so fast.

What keeps me up at night is what I don't know. Like, you know, the goal, if you look at NIST, right? The NIST CSF, the first column is identify. It's one fifth of the pie.

Know what you've got. Because if you don't know what you've got, how can you protect it? Right. You bump into black swans or the unknown unknowns.

And it's that fourth quadrant of knowledge that can definitely bite you. And you don't even know it's coming. That's right. Because if you know it, then you can, you know, the theory is that you've either dealt with it or you've risk accepted it in some way, shape or form because you've decided not to deal with it right now.

You're going to deal with it later because whatever you're looking for, budget, priority, da, da, da, da. But once you know about it, in some level, it's in your control. You're making decisions. I suppose that's why some folks are driven to buy cyber insurance to cover the unknown unknowns.

Look, cyber insurance is just a no brainer, right? It amazes me that it's even a topic of conversation. It's like, you know, you have insurance when you drive a car, et cetera, et cetera. To me, that's just, that's just cost of doing business, especially in today's ecosystem.

I mean, it's not a question of if, the question of when and how bad is it going to be. So insurance is, in my opinion, a necessary risk management strategy. But yeah, no, to me, like the thing, what keeps me up at night the most is definitely the what I don't know. That can be on many, on many, many fronts.

I mean, you know, an example of that on a less technical level is data loss, right? Especially if it's like PII or what have you, because that has more regulatory and other sort of commercial financial impacts versus IP loss is a slightly, just a different kind of subject matter. So I'll part that one for a second. But if I look at.

I look at PII as an example. You know, data protection is a nightmare. It's everywhere. It's just, it's near impossible to control it fully.

And the more you control it, the more you piss off your users. So there's a balance there. Does that keep me up at night and cause me huge amounts of concern? Maybe not like cold sweats, but in terms of knowing, I'd challenge any, any CISO or any security professional to be able to say, I know where all my data is.

It just doesn't, it's just a good luck with that. So it's just one example of the challenge, right? But, you know, I think for me, the issue is more in the technology space, you know, especially like if you look at like all the cloud services, AWS and all that sort of stuff. Anyone in the org, depending on your governance, but anyone can spin stuff up with their credit card, this, that, and the other.

And it's just, yeah, it's a challenge. All right. Well, thank you so much, Andrew, for jumping on the show. We want to leave our listeners to any last words, final thoughts.

Final thoughts. This is where I think I should try to be profound and deeply philosophical, which I think I'm neither of those. Well, we could just wish everyone to enjoy the rest of their day and stay tuned for more episodes of the security podcast of Silicon Valley. Yes.

Thank you very much for having me. It's been a pleasure. Andrew, the pleasure was all mine and wish you the best moving forward with Pure Storage and securing all of that valuable data. Thank you.