Beyond the Debate: Security as an Enabler & GRC Maturity with Withrop Welch, Fractional CISO
TLDR;
- Instead of debating about Security vs Compliance, look at Compliance as a gateway to Security Use Cases & Requirements.
- Alignment is the key factor in improving collaboration between Security Team and other teams in the organization. Not only building trust but also building Security Champions goes a long way in designing a successful Security Program.
- The only way to fight & win against Vendor / Tool Sprawl is understanding your Future State Architecture and mapping out your roadmap. Once done, work the best fit tool / vendor. Instead of buying the new shiny toy.
Transcript
Host: Hi, everyone. This is Purushottam, and thanks for tuning into Scale2Zero podcast. Today's episode is with Andy Welch. Andy is a seasoned cybersecurity executive who has led security, GRC, and risk strategy at multiple companies like Yahoo, IBM, and Goldman Sachs, to take a few names. He brings a pragmatic and executive-level lens to building secure, compliant, and resilient organizations.
From fortune 500 firms to emerging tech. He is passionate about building trust, resilience, and security cultures that last. Thank you so much, Andy, for joining me in today's conversation.
Andy Welch: And thank you so much for having me. That was a fantastic intro, and it kind of causes me to reflect really quickly on what an incredible journey my career has been. It's taken me around the world, introduced me to some of the smartest and most dedicated people I've ever worked with. And it's just been a fun ride. One thing to add, I actually got my start in KPMG with clients in the financial services, healthcare, and higher ed industries. And that experience really was foundational and it shaped the way I think about risk, trust, and business alignment. But overall, I think if you're curious, you love to build things, solve hard problems, cybersecurity is an awesome field to get into.
Host: That's a great start to the podcast because most of the time, security is not seen as that exciting. Thank you for making it look exciting, right? Because we need more people in security overall. One question that I would like to start with, like we often ask this question to different leaders and we get different response based on their role and position, and things like that, or their career. What does a day in your life look like?
Andy Welch: This is a really fun question, and I'm gonna give just a tiny bit of context before I begin. So my wife and I are both builders at heart. It's just kind of how we're wired. So for me, that shows up in the work that I do in cybersecurity, for instance. I love designing systems. I love solving complex problems. I like helping organizations grow in a secure way. For my wife, it takes a kind of slightly different form. She runs a little farm, a small farm.
So most days,I started early with her feeding animals and checking things outside. And believe it or not, I play the role of occasional farm hand. And when needed, I go and help fix fences or mend pens or carry heavy stuff around before I dive into work. Once I'm inside and sort of focused on work, I'll do what most people do: grab some coffee, I'll catch up on emails while I'm listening to a podcast or news playing in the background. My work days are usually pretty jam-packed and full.
But I really love what I do. So it doesn't really feel like a grind. For me, it's sort of like I'm energized by kind of getting into the groove every day. Around lunchtime, I try to carve 30 to 60 minutes for a workout to reset. And then I typically wrap up around five or six on most days, try to spend time with our kids, help with chores, that kind of stuff. It's not a glamorous life, but I love it. And it's a meaningful one for me. And I feel, I guess we do.
I feel incredibly fortunate to have a career that I care about and a wife and a family that keep me grounded.
Host: I think the biggest thing is, you feel happy about the work that you do? And I get a sense that you do. That's all that matters at the end of the day. And as you said, security is a stressful job. And if you're having fun while doing it, then it sort of reduces that stress a little bit. So love how we have started the podcast today.
Andy Welch: Yes. Yeah, I couldn't agree more. Yeah.
Host: Yeah, please go ahead.
Andy Welch: I think, you know, knowing sort of my builder background, it's so exciting to have those challenges to come to and bring to the table every day. I couldn't imagine having a more sort of stable, static career. I just really love the field, love all that it provides. And it's just a fantastic career for me.
Host: So today, we are going to talk about some of these things. So hopefully we can touch on some of these. I'm pretty sure we cannot cover everything that you have learned throughout your career. So we'll focus on lessons from leading security and GRC in high-stake environments and how to turn security to a growth enabler because often it's seen as a blocker, right? So...
Andy Welch: Yes.
Host: I know that you have led security and GRC for multiple organizations. So it feels an appropriate question to kick off. Security versus compliance. I know it's an age old debate. John Giglio, one of our earlier guests, said that if you do security basics the right way, then compliance automatically follows. Having said that, compliance often is the driver for security programs. It could be regulatory requirements. It could be a sales need.
Like getting shocked to sometimes is more of a sales requirement than a security requirement anyway, right? So how do you see this debate playing out between compliance and security?
Andy Welch: I think that perspective is generally correct. Doing good security does lead in general, to good compliance. But I think the short answer from my perspective is security and effective compliance really shouldn't be at odds with each other. So just kind of ground us for a minute. I tend to think of compliance very broadly, covering both external requirements. So the things I think most people traditionally think about when they think about compliance like regulations, contracts, maybe court mandates, and the like.
And then internal obligations, security policies, controls, complying with the mandates of the organization that you're a part of. So it kind of has those two dimensions. And I think if you use those lenses, it's almost impossible to build a credible security team and program without thinking about compliance.
For me, practically speaking, compliance mandates should really function almost as a form or should function as a form of security requirements. A strong program should work hand in hand know, security team, translating business and legal obligations into actionable requirements. Compliance is sort of part of that mix. Compliance generally with really good compliance mandates, I think, tend to focus on what needs to be done, not necessarily how it's done.
And when you think about it, that's kind of directly translatable to a requirement. If the requirements, if the compliance requirements are clear, specific, traceable, if they're good requirements, they become great inputs to the security roadmap, not blockers, and they can be prioritized just like any other set of requirements could be. So in the end, I think it's less about compliance versus security and more about really understanding what compliance
obligations are and working them into the program's roadmap and requirements.
Host: I love how you simplified and how you build that relationship between both of them, right? Because often, you're right, often it's seen as, hey, I'm compliance focused or I'm security focused. And there is always that debate. Now, when it comes to, let's say, your team, your execs, or your peers, how do you show them that it's not like these are not two different
different things rather, they are very correlated, and there is value in thinking about both at the same time. How do you do that?
Andy Welch: That frank conversation right at the beginning, of how asking, you frankly, how do they think of requirements, right? A lot of people, when you ask sort of basic questions like that, will come up with a bunch of different answers, but very rarely will they sort of internalize. These are essentially a set of requirements, just like any other set of security and control requirements. And if you sort of view it with that lens and have that conversation.
It becomes a much easier sort of way to view how to take that input, how to take that work and weave it into the existing program's plan and trajectory. If you sort of think of them as two different things or bolt-on things or very unrelated things, then it becomes very hard to kind of picture how you're going to have one team communicate and pass the value of what they're doing to the other team and vice versa.
Host: Right, right. So now another question that comes to my mind is, let's say compliance has been there forever. There is a lot of focus on security. How has some of these challenges around security evolved throughout your career? I'm pretty sure you have seen a lot of technological shifts and security requirement shifts. I'm just taking an example. Let's say we used to be in data centers. Now we are in cloud. Now we are talking about AI.
So, how have you seen the challenges of security evolve throughout your career?
Andy Welch: This is a wonderful question, actually. And let me start with, I don't think the fundamentals have actually changed too much. So things like the security triad, confidentiality, integrity, availability they still guide how we identify, manage, and think about risks. But the context of security has shifted dramatically and very radically. So, as an example, earlier in my career, we didn't have the mature security frameworks that we have now. A lot of practices were like experience-based, maybe even like tribal knowledge-based, if you will. But as the community matured and we shared our practices, we talked about what we were working on, we saw the rise of structured frameworks. So NIST, ISO, and others. And they gave us sort of a shared language for how to talk about different aspects of security, how to put them in different categories.
how to measure our success in those categories, and essentially gave us a way to define what good security looks like.
What has evolved is the scale and complexity of security. The attack surface has exploded. Threat actors are way more sophisticated and the speed at which they operate has just, it's gone insane, it's increased dramatically. Despite all of that change, though, I still find getting back to the basics, the CIA triad, to be a great foundational tool to think about it. And kind of coupling that with the frameworks that are now available.
We're able to more effectively deal with some of that dramatic shift in growth. And for me, what's exciting and challenging is how we apply those things to modern contexts like cloud, AI, compliance, et cetera.
Host: Okay. Yeah, I love that. Sticking to basics, basics has not changed in any way. Now, challenge is with all of this complexity that you mentioned, there is also, from a security program's perspective, it also becomes complex to manage the complexity of your IT infrastructure, your attackers thought process, technology changes, and things like that.
As leaders of security, you have to often make sure that your team, your organization understand the value of it, the security strategy that you put in together. And we also hear that security leaders have to make a choice between having that alignment, security strategy alignment, versus having a balance of what is business goal and what is the security goal. What are the biggest hurdles you have seen when it comes to the alignment of security strategy with
within enterprises.
Andy Welch: I think this is one of the biggest hurdles to successful security programs versus security programs that struggle. From my perspective, it's absolutely essential to align the security strategy with enterprise strategy and growth. When you think about it, the only reason security really exists is to protect the enterprise, its people, partners, customers, and brand. Without that, we wouldn't need the programs that we're building. So there is like,
at its very core, a foundational linkage between the two. Having said that, the biggest hurdle, I think, is gaining access to the right people on the business side to have conversations about their motivator. So, without that access, it's incredibly difficult to truly understand where the business is headed and what goals are evolving. And you need to have access to those people in a way that's persistent and regular, based on value. So you need to understand sort of what their motivators are, what value you as a security professional can provide, and you need to kind of keep that dialogue with those key stakeholders opened and refreshed, and regular. That's actually, I think at the end of the day, one of the biggest hurdles because identifying the right people that are, you know,
involved in driving the business forward, becoming relevant into their conversation together and continuing to help them grow while they help you understand where to steer security is a difficult task. It's really difficult to do that. And I think many organizations may not spend enough time really focusing on that objective to keep that alignment steady.
Host: So it's more like having business champions or security champions in the business, on the business side as well, so that they also see value. They not only see it as a blocker, but an enabler to bringing, maybe building trust with end customers. Any tips and tricks that you have to build that relationship, build the champions, and overcome some of these hurdles?
Andy Welch: Yes, so I think the strongest relationships between security and the business are built on shared trust basically, mutual trust, shared goals, and clear communication. And I think the best way for me to answer this question let me give an example. earlier in my career, I was leading a penetration testing game engagement for a large financial services.
And to execute the engagement, I was working with one of their senior IT leaders. And right from the beginning, it was very obvious he was sort of hesitant to work with us. Didn't really, he'd like missed meetings. It was hard to get on his schedule. It was just very frictional, right? I talked to the broader engagement team and what they told me was he basically had experiences in the past with other consultants that delivered tool-based assessments.
and kind of dropped all these problems on his desk with no context, no sort of value, if you will. So he viewed the work that we were doing as potentially frictional with very little value and a lot of red tape for him. So that was sort of an aha moment, right? That's a value problem. And that's an alignment with the business and the business objectives problem. So took a step back rather than pushing forward. And I kind of thought about it, and I sat down with him.
and basically talked to him and I sort of assured him that my work would be risk prioritized, operationally relevant, focused on action. I gave him the pitch, right, of the value that we were going to do. But the key is I also invited him to come and participate with me and my team whenever he wanted to. So we had a little space carved out at his office. And the very next day, he joined us and sat down and kind of, you know,
talked a little bit with us while the team was working and kind of asked a lot of interesting questions. And very quickly, it turned into he really spent a lot of time with us, and his input was incredibly valuable. It gave us faster access to systems. It gave us an idea of what systems were more risky versus less risky from his perspective. And it helped us craft a much, much better deliverable. And by the end of the engagement,
It was like a 180 degree turn. This is sort of an example of like being value-focused, understand that security, you know, if we're a checkbox or sort of a tool-based automated low value capability, we're going to be marginalized, right? And if we kind of behave as partners and we invite the business in to the extent that we can and we provide them value, that's really the best way to overcome. those hurdles, particularly when you're trying to align strategy with business.
Host: There are so many threads that we can start from here. Like, there is often a friction between engineering and security because of that, right? That security says that I have a new shiny tool, and here you go. are 10,000 vulnerabilities to go fix. And that's when engineering is like, what are you guys talking about? Right. And that's when that trust, that relationship, also goes south.
So I mean, I love the example that you gave, right? Where you are not only doing the regular, let's say, showing the value, but also you're going extra mile to having, let's say, an office hours where you have open space and folks are coming in and collaborating with you with their challenges. And you're showing how you can make their life better and not make it more difficult by sending them 10,000 more alerts, right? In a way. I love that example.
This is in line with one of the questions that we got from Bonnie, one of our common connections is, one of your past colleagues says you are an emotionally intelligent guru. You lead from the front and guide those around you, even those that aren't direct reports. How do you make time to support not only your org, but other aspiring leaders who come to you for wisdom? How do you respond to that?
Andy Welch: That's a really wonderful thing to say. So thank you, Bonnie, for that kind note. And reflecting on it for just a minute, I genuinely enjoy learning from others and sharing what I've learned. I think the best way to put it is I see it as part of my job to create fertile ground for people, no matter whether they work on my team or other teams or around me, whether they report to me or not.
If I do that, it helps them grow their careers and programs as effectively as possible. To your point, this kind of ties back to my example of the penetration study. I'm creating fertile ground for us to have a conversation with our client in an ongoing and meaningful way. What's interesting to me is that approach almost always benefits me too, just like in my example. I learned a ton about their environment and about their priorities that I would never have known.
if I didn't have that really close partner relationship. I've learned that mentoring and collaboration across teams using some of these tools and techniques pays dividends all the way around to all parts of program. So for me, making time for others is not a distraction. It's a core part about how I lead. And I just couldn't picture leading in any other way at this point.
Host: On a similar note, we have another question from Robert Heinz, who is asking that you have experience both as a helper, as a consultant, and as an owner, like an executive leader, when it comes to security, right? How does both of these roles help you in becoming more effective in the other? How have you seen value being a helper to the owner and vice versa?
Andy Welch: This is also a really, really fantastic question. And each role has unique strengths and challenges. So as a consultant, I could step into a lot of environments quickly. I could spot patterns. I could offer guidance and fresh perspective. I had sort of a broad view across all different types of industries and technology stacks that I could bring as value to the table. It taught me to listen super deeply and to ask better questions.
and to meet leaders, sort of where they were in their journey, right? You have to be very nimble; you have to be able to be relevant. So all of those characteristics were things that I learned. If I contrast it a bit, as an in-house executive, I carry full accountability, not just for strategy, but for execution, team culture, long-term outcomes, et cetera.
And that kind of ownership demands, for me at least, a different level of investment. The shift between the two also changed my leadership approach. As a consultant, influences, I think, earn through insight and credibility. And as an executive, it's earned through consistency, transparency, and building a culture people want to be a part of. That sort of fertile ground culture is very, very important.
Doing both is making better at each. So, bottom line, I bring the structured outside in thinking of a consultant to my leadership roles, internal leadership roles, and I bring the empathy and
realism of an operator to my advisory work, which kind of balances out and makes, I hope it makes me a better executive in the end, but I think it
Host: So again, I like how you structured it so that you can clearly see the value of one role to the other, like the impact of it and the value of it. You mentioned culture a few times. So that's where I want to go into the culture part. And this is often the biggest challenge that we see with security. Because we spoke about, you gave that earlier example, right?
going extra mile during your pen testing study. Often, security teams have to work with cross-functional teams. It could be engineering, could be product, would be like execs and things like that. Do you have any tips and tricks? How can security teams work more closely with these teams so that they create a culture of security throughout the organization, not just that security works in isolation?
Andy Welch: One key step I think is fostering a culture, whether security or not, fostering a culture of what I call, I call it this with my teams, the culture of positive friction and open feedback. What do mean by that? So I actually actively ask my teams to critique me. I won't sort of like sit back and
have a discussion with them, talk to them about planning, talk to them about budgeting direction, FTE loads, whatever the topic may be, without actually literally asking, do you see a way that we can accomplish this in a better way? Because sometimes there are just angles on a problem that I haven't seen yet, and that somebody else might. So I welcome that debate. I actively welcome and push for that.
For me and my teams, there's no penalty for respective disagreement when the goal is better outcomes. And this carries to the teams and partners I work with. If you think back to even that penetration study example I gave you, I was welcoming that client to sit with us, knowing that we might have some frictional to positive frictional conversations that we did, and that was a good thing. So that kind of environment, I think, encourages ownership and creativity.
And it leads to stronger, more adaptive security thinking. You have to take a little risk. You're gonna put yourself out there, and you're gonna say, Hey, could we be doing this better? And you have to be willing to understand you may find ways to do things better, and you also have to be willing to take those in and learn from them and add them to the program and become better. I also continually reinforce the mindset.
And we've talked about this a little already, but I'll say it as it bears, I think, repeating, security must be value-driven. And it shouldn't be rigid or top.
When the team sees that, like, the security team really starts to see and understand that fundamentally, their job is security, but part of that is to help others succeed in building secure things, it completely changes the energy of the conversation and the nature of relationships.
And that's how I think we most effectively develop that or start developing that security-centric culture.
Host: So being open to critique and all of these means you are being a little vulnerable also, right, in front of your team, which is often not the most comfortable thing to do. Any advice on how to get started on that? I know that you have been doing it for a while, so you may not feel like it's such a big deal, but I'm just trying to think about leaders who are just getting started.
how to be vulnerable, how to be open to like, open critiquing and things like that, right?
Andy Welch: I think, Make a really good way to start, and this works, I guess, best on teams that are already established, but a great way to start is with your direct reports. So if you're very nervous about taking this approach and wondering sort of how to make it successful throughout your organization, maybe even several layers down throughout your organization, don't start with every, don't bite off everything at once. Start with your direct reports and test sort of the waters.
Try the idea out. When you're having a conversation with one of your direct reports, maybe just the two of you in confidence, think of that positive friction. Try it out. Have a conversation. And then at some point in the conversation, ask questions like, Hey, what do you think about this? Or do you think we could be doing this any better? Or have you seen this work in any different way? Sort of tease that out. Give yourself a comfortable environment.
try it out and see how effective it is for you. But for me, I know like at any level of my team, they can come back and have these sort of positive frictional conversations with me. And not only is it not discourage, I encourage it. Like I welcome, if a team member, no matter who in the team, comes to me with a really great idea that nobody else in the team, including me, hasn't thought about before, that's a golden opportunity.
for us to just quickly elevate our output beyond where we would have been without that input, basically. I think start reasonable. Don't try to necessarily do the entire team structure at once. Start with your trusted people first so you're most comfortable, and then branch out.
Host: So start small and then slowly scale up and yeah, that's a very good advice because often what happens is when like when you want to test out a new program, we want to go all in and we start with a big yeah. It's like the first day when you go to the gym, you want to use all the equipment there are.
Andy Welch: Yes. I get really excited. Very great.
Host: And then the next day you're sore and you cannot do anything, right? Like you don't have a structure, and you don't think about starting small. So yeah, makes sense. And I want to shift gears slightly to more around security programs and running them and the learnings from them. GRC implementation is very important to a cybersecurity program, right? What is the current level of maturity you see when it comes to GRC?
in most enterprises today.
Andy Welch: I think honestly, in many organizations, the maturity level of GRC integration is pretty low. I mean very often, GRC is seen as, I guess, if there's a way I can put it, GRC is seen as the assessments team, right? The group that shows up after the fact they have a checklist or some audit program or tool that they're running, and then they get similar to my penetration study example, they come up with a list of problems, maybe some ideas of solution, but all of the problems that they come up with they come up with after development and implementation has occurred. So they become a true source of noise and friction when you think about it. I mean, how would you feel if all of a sudden this external group came up and did all this stuff, dropped a huge list of complaints on your desk, basically, maybe with some idea of how to deal with them from their perspective?
and then kind of walked away or maybe monitored if you were kind of closing the gaps, but that's it. It would be really difficult to see value in that, right? And in that mode, GRC becomes quickly marginalized. Business teams see it as slowing things down and like a barrier, red tape barrier, as opposed to providing value. So, and the truth is it's really, I think, easy to fall into that trap rather.
Assessments are important. They're familiar. But if you don't grow a program beyond that basic essential capability, you're really going to have a program that struggles. I think the real shit of GRC happens when it moves upstream and it becomes a valued partner in the process, not just a reviewer after the fact. And that means embedding into development and operations directly. To do that, you have to understand their workflows.
And you have to help them make smarter security decisions as decisions are being made. In that way, you're much less of a blocker, you're much less of a person that slows things down, and you're seen as a really valuable accelerator that's gonna help them achieve their goals quickly. So it requires a lot of investment. You gotta sit with these folks, you gotta speak their language, you gotta build those relationships of trust, and you gotta be brave enough to offer those that advice and really kind of continue to be that trusted advisor. But in that role, that's good.
Host: So I think this is where shift left became popular, where leaders said that maybe we should start think about security way earlier than after your application is in production. Any other advice you have when it comes to implementing GRCs in a better way?
Andy Welch: Yes. So I think, just give me a minute here to sort of think.
So I think the most important thing is clarity. If I really had to think about how do we move an effective program. So when I first joined Yahoo, I had to really build out the GRC program. And one of the first things I did is I clearly defined the program's vision, scope, and value proposition. And then I made sure that everything that we did tied back to those things.
And that kept the team focused. And it also gave me a way to sort of communicate what we did, what value we brought to key business stakeholders. It was a lot easier for them to think of us as something different from the assessments are us team, right? Which I think was largely what people viewed the organization as before I got there. I think if you're in that mode,
this is something you should really pursue. So practically speaking, I also like to approach GRC team structure a bit differently than some other organizations. Many organizations align GRC by governance, risk, and compliance team. I mean, it's in the name. Why wouldn't you align it that way? Rather than do it that way, I like to split the teams by internal and external focus. Let me explain what that is.
So the internal team handles internal objectives, things like policies, control standards, risk oversight, internal compliance. And the external team manages things like external obligations like regulatory engagement, third-party risk management, contracts for M&A deals, customer and client business partner assurance.
Think about that structure. It helps each group specialize and actually aligns them better to the way businesses are actually structured and aligned, versus trying to take a team and sort of lay it out by government.
Host: Let them do everything, right? You're doing everything. Yeah.
Andy Welch: Yeah, exactly. So by aligning it into those types of teams, I think it builds a more natural relationship with key business stakeholders and it builds a much, much stronger.
Host: Yeah, I see the value in it, right? Because from an internal versus external, there are very different expectations that come with it. So catering to those needs, different level of mindset, and different level of skill set sometimes as well. Like if you need to cater to the government, then you need to have expertise in the frameworks that cater to it, versus if you are
Andy Welch: Yes.
Host: internal focus, maybe you don't need to, right? So in that case, you have a very different expectation, very different expertise is needed as well. Okay. One of the things that you mentioned earlier was around the friction between security and non-security and things like that. Non-security part of the organization, and often security teams work with a lot of tools to do assessments and things like that.
And this ties back to what you mentioned, like GRC programs are maybe not implemented the way you would like them to do, like it's not integrated really well. So how can security leaders, like let's say utilize, leverage some of these technologies or some of these tools and not make it like a tool fatigue and let's say you have 10 tools, they have their alerts.
and then all of that you're just pushing it to let's say engineering our product. How do they manage that balance?
Andy Welch: Okay, so this is one that I sort of have learned, I guess, throughout the years. When I see organizations struggling with multiple tools or I guess some people call it vendors for all, I think that's what you're getting at as the question. It's usually a core symptom of one thing. They never had a cohesive security architecture or long-term plan. Usually what that means to me is they built these capabilities reactively over time.
well-intentioned. What they did was they picked what seemed to be the best tool for each issue at the moment they had to solve the problem. That ad hoc approach almost always leads to overlapping tools, integration gaps, and huge bloated cost, right? The first step in fixing it is recognizing it's not just a tool or tooling issue. It's definitely a strategic issue.
really have to take a first like to recognize it. You have to kind of see it happening. And then you have to take the time to take a step back and, you know, block and basic block and tackling map out your future state architecture, and build a reasonable roadmap to get there. I just said that very quickly. It kind of sounds easy. That's definitely not easy. It's going to take investment time, focus, negotiation and coordination, and justification across multiple teams. But seriously, the payoff.
should almost always becomes a leaner, more effective and more affordable program. You get better outcomes with less complexity and far cheaper costs. So I would sort of say, if you're feeling that type of sort of vendor sprawl tool fatigue, get on it. Really address that as one of the core projects your team works on.
Host: So this is some like I'm trying to like map it to a real-life example, right? Non-security example. Things like, let's say, in your house, you have all Apple devices, Apple TV, let's say phones and things like that. All of a sudden, you see the best Android device for let's say video calling or something like that. And you say that, hey, I want to buy that.
But that doesn't integrate really well into your ecosystem in a way, right? So it's best tool versus best tool for me in a way. Like how does it integrate with other parts of my ecosystem? So yeah, I love how you put it, right? That just looking at a best tool, buying it doesn't make sense unless it fits really well into your organization and your own security architecture that you have put together.
Andy Welch: Yeah, if you think about it, that one example of the Apple versus the Android with one application is a problem. All of a sudden, now if you choose four or five more different applications versus that central ecosystem you have, you can imagine it even gets worse over time. And that's kind of what tool fatigue ultimately is.
Host: Right, right. So there is another scenario as well, right, when it comes to like vendor sprawl or tool fatigue is let's say Yahoo is a good example. Yahoo was an active M&A and divestment environment where, let's say, if you are acquiring an organization, they have their own set of tools. Yahoo has their own set of tools, which is maturing. How do you sort of find a balance so that your security teams can show the value?
without even affecting the business overall. What have you seen? What have you done in those scenarios?
Andy Welch: So this is great because we did a lot of work within GRC, specifically with M&A at Yahoo. And I think really the core is just like we've been talking about. Sort of the theme is you've got to become a valued partner to those business groups. You cannot be a bolt-on.
organization, sort of at the end of the business deal or at the end of diligence in the business deal. You've got to be, to your point, left shifted and part of all the way from deal thesis to...
diligence all the way to DL execution. And so this kind of get to what you were talking about.
Okay, I've got a really great, another really great example here of something that again that happened earlier in my career. I was working with an organization that had just purchased, just acquired through M&A deal, a new software package that they were very excited to integrate and to start a new revenue stream on. Unfortunately, the deal team
never actually engaged IT or security at all until after deal closed. We can believe that. So how does the conversation goes? All of a sudden, you know, there's a conversation that happens of, hey, we've got this great new tool. We think it's going to be fantastic for our company. Can you integrate it? Like how long is this going to take you to integrate it?
The outcome of that conversation was that, in this case, was that the tool itself, the architecture of the tool was fundamentally different than the architecture internal to this organization. And actually kind of redoing the tool to a new architecture or adding new architecture in to support the tool or changing architecture for the tool would have been far more expensive than it was worth.
And the deal actually collapsed, if you can believe that. So it was actually that moment in time when I realized security really had a place at the table and was, especially in today's world, it was a really critical part of the material value of the deals. And once I learned that, I started working with the management team, saying, Hey, let's take this as a lesson learned and let's figure out how to not do this again.
Right? And we started to push our way in, if you will, to the deal teams on some of the deals they were working on. And it became really clear, you once again, we're sitting with them having conversations about the deal thesis, about diligence, we're offering real interesting questions and insight, and the deal team is seeing this, it's like really having a material effect on their deals.
So by the time we were done sort of with integration, my team wasn't pushing to get in or trying begging to get into these deals. They were picking up the phone or writing emails directly to us saying, hey, come on in. We've got this new thing we're working on. We want you guys to come in and work with us on it. So it really kind of changed from a, you know, we're begging to get into a, and this is actually funny. This is what I tell my teams on these types of problems.
You know that we will know that we're successful when we stop having to beg to get into these meetings and they come to us and they say, here's what we have on the agenda. Can you guys afford some time to come here and work with us on this? That's like the key moment where you know you've achieved that victory.
Host: This goes back to the culture again, right? Like how you build that culture so that the teams feel comfortable bringing security in early than very late stage where you have already invested a lot. Like, not from a maybe money perspective, but you invest a lot in terms of effort and then security comes and says that, hey, this won't work. And then again, security at that time is seen as a team of no. So yeah.
I love how you tied it all back. Any other such scenarios or high-stakes situation that you can think of where your way of leadership was tested, and if you are open to share that.
Andy Welch: Totally, and there's one that sticks out so distinctly in my mind as much earlier in my career. So here's sort of the scenario.
I was leading a breach response for a major healthcare organization. In turn, that would happen was that they were compromised through a vulnerability in common desktop environment, CDE, on their Unix platforms. It was a very sophisticated attack. The intruders had root access.
and they deployed tool kits, had full lateral movement, and full control of the system. So, pretty big breach. Started out as a very normal engagement, you we worked really closely with the IT team and operations to contain, eradicate, recover, you know, all the basic steps. But I distinctly remember this one afternoon where one of the operations leads pulled me aside and he just had this like really concerned, shocked look on his face. I knew something was wrong, right? I'm like, okay.
What's going on here? He told me that one of the compromised systems was a control platform for an MRI scanner. I'm not an MRI expert, so I didn't really know what that meant. I mean, I was thinking things like maybe it's some downtime hardware, like it's expensive piece of hardware. There's some hardware risk here. Maybe it's a patient care thing. They're going to have to take it offline to fix it before they can care for patients. So I asked him, was like, what's sort of the impact here?
And he explained that the system controlled the scanner's cooling functions. Okay, you know, that's interesting. But again, you know, maybe it's, maybe it's just a hardware issue that's going to be expensive to replace. So I kind of asked him a little more, and then he kind of broke it down. said, okay, if the system is tampered with, it could trigger, I think what they call, if I'm recalling this correctly, a rapid quench. I was like, what's that? And he's like, it's an uncontrolled,
deep pressurization, I'm trying to do this slow so I can remember it correctly, of the liquid helium used to cool the MRI magnet. And then he says, it's technically not an explosion, but it behaves like one. And I was like, wow. Okay, now I get it. I mean, this could turn into serious physical harm to anyone nearby. So that was a very high stakes.kind of situation.
And really quickly what we did, of course, we took the machine offline as quickly as we could. actually, it's a good kind of outcome. We were able to discover that they had system backups. There was a little bit of nervousness because they hadn't been tested in a while, which is a problem, but we were able to restore from a backup to a period of time earlier than that flawed CDE existed. Test out the system and then get it back online in time to care for patients. But that was a really high-stakes situation where we had to really quickly reprioritize what we were doing. We had to really get the right focus, make the right decisions on how we were handling it. And it really stuck with me. Security is always just about protecting data. Sometimes it's about protecting people. And this was one of those times that it really came forward and made itself known.
Host: Wow. And this also shows that there are so many attack vectors in a way, right, which attackers can exploit and so many ways they can get to it unless we have alignment that culture of like the trust that you have built with other parts of the organization. It's very difficult to for, let's say in this case, right, for the person to open up and share in these details. And
with that trust, when you share all those details, that helps you to remediate it in much quicker way, right? Versus taking hours or days to figure out what exactly is going on.
Andy Welch: 100%. If you can imagine, the reason we were able to address this machine so quickly is because we had the trust of operations, we had the trust of the backup team and recovery team, we had the trust of the network team. We all came together recognizing that this was such a high priority, and we prioritized people to do a very specific sequential step, process to get the thing fixed and back in service. So patients could actually get patient care was also sort of early.
Host: Yeah, yeah, yeah. Yeah, I love it. Love that example. Love that situation that you went through, and you shared that with me here. And that's a great way to sort of end the security question section as well.But before I let you go, I have one last question for you. Do you have any learning recommendation for our audience?
It could be a blog or a book or a podcast or anything that you would recommend.
Andy Welch: I Do actually, I'm gonna do two if you'll allow me, real quickly. So the first is a podcast called The Knowledge Project by Shane Parrish. It's not security specific, it's about decision-making, mental clarity, that kind of stuff. I really took a lot of value about first principles thinking away from it, sort of breaking down problems into their fundamental truths.
Instead of relying on assumptions or analogies. And you can kind of hear that, I think, in some of my answers. I really do try to break things down into what they really are so that I can.
fantastic, fantastic podcast. And that type of thinking is really important during a breach or high stress situation, you those types of things. you know, resource. The next thing I'll recommend is for security and GRC folks, especially those that are involved in third-party risk, M&A, customer assurance, any kind of collaboration with legal, which I think is occurring more and more often with security and GRC teams. I highly recommend the course creating effective contracts. It's a course offered by eCOR now, and it's great. It will not turn you, won't turn security and GRC people into legal experts. Don't sit directly with me. The idea is you're work better as a partner with a legal term, a team rather. It gives you a solid foundation into how to think in contract terms. And the outcome of that is,
You start to think the way that the legal team does, and it makes that partnership more valuable and more effective, which has a huge amplification on getting good security terms, et cetera, to all those.
Host: You can collaborate better. Yeah, these are great recommendations. So when we will publish this episode, we'll add it to the show notes so that our audience can also go and learn from there. Yeah, with that, thank you so much, Andy, for joining today and sharing your knowledge. I hope that our audience gets value out of this conversation.
Andy Welch: Fantastic.
Thanks again, man. This was so fun, and it's been a fantastic conversation for me as well. I also hope that it really kind of helps and entertains some of the audience, and I look forward to perhaps working with you again in the future. Thank you.
Host: Yeah, absolutely. Thank you so much.