(0:07 - 0:23)
Welcome to Absolutely Critical by Fortress, where leaders across government and industry share how they protect mission critical systems in environments where disruption, compromise or failure simply isn't an option. Welcome to the Absolutely Critical podcast. I'm your host, Lee Mangold.
(0:24 - 0:38)
Every organization depends on a web of outside partners, vendors, suppliers, service providers to keep the lights on and the business running. And with that dependency comes risk. Risk that doesn't stop at your front door.
(0:38 - 0:49)
It flows upstream through your supply chain, downstream through your customers, and sideways through every connection in between. And we know this. The frameworks exist.
(0:49 - 0:59)
The acronyms are everywhere. TPRM, SCRM, VRM, there's no shortage of guidance telling us what we should be doing. But here's the thing.
(0:59 - 1:21)
Knowing what to do and actually doing it are two very, very different things. Most organizations get stuck somewhere between the policy document and the daily operations between the executive briefing and the team that actually has to make it work. And today we're going to talk about that gap, the space between the strategy and the execution.
(1:21 - 1:49)
How do you take third party and supply chain risk management off the whiteboard and build it into the way your organization actually operates? Not as a one-time project or as an annual checkbox, but as a living, breathing practice that scales with your business and adapts as the threats evolve. And today's guest is a longtime colleague who has worked with this exact challenge. Our guest today is Jeffrey Sweet.
(1:50 - 2:29)
Jeffrey has over 35 years of risk management experience, starting with a decade in the U.S. Army as a military policeman, where he handled everything from law enforcement and customs level inspections to criminal investigations and protection and personal protection of dignitaries in Berlin, including during the fall of the Berlin Wall. Moved into IT security, first with defense, finance, and accounting services, keeping critical federal pay systems secure. And then at Huntington Bank, where he led a team securing technology assets and proposed a dedicated team focused on vulnerability management over defense and encryption.
(2:30 - 3:13)
From 2007-2010, he worked as a senior security consultant at DPS Sciences, serving clients across manufacturing, insurance, transportation, and retail, helping companies build their security programs and policies from scratch. And then, how I became introduced to Jeffrey, in 2010, he was recruited to American Electric Power, one of the largest utilities in the country, where he rose to security director. And during his time at AEP, he led five different teams, managed a joint practice with Fortress, and proposed the business model that led to the creation of a new organization under Fortress called the Asset Defender Network, which is a security supply chain risk assessment data exchange.
(3:13 - 3:27)
So, after semi-retiring from AEP in 2023, Jeffrey launched his second career, providing cybersecurity technology risk consulting to critical infrastructure companies. And that's what brings him to the show today. Jeffrey, welcome to the podcast.
(3:28 - 3:33)
Thank you, Lee. Yeah, that's one heck of a bio. It's a great background.
(3:33 - 3:40)
And you are the person we want to talk to today, for sure. Thank you. I can live up to the expectations.
(3:41 - 4:08)
You know, if we could all live up to the expectations of our bio, it'd be a good day, right? So, yeah, so, you know, we talked a little bit about all this, you know, beforehand, obviously. And, you know, one of the first things I thought was sort of an interesting piece that you brought up right away is sort of that term ambiguity. So a lot of people use the terms third-party risk management and supply chain risk management interchangeably.
(4:09 - 4:42)
And in some organizations, they live under the same umbrella, right? So, from your perspective, what is the real distinction between the two? And I think that the second part of that is, does that distinction really matter when you're building a program? Absolutely. So to make it very simple, third-party risk management is more about the product and the person selling you that product, whether it be software, hardware, services, whatever the case might be. Supply chain risk management goes broader.
(4:42 - 5:14)
It goes to who is supplying that supplier with the product, who's transporting it, who's building it, what, you know, what is the process that it's getting to that vendor and then ultimately to you. And the reason why it's important and different is because as more hands touch things, there's more potential for risk. So say, for example, you've got a vendor that's supplying you a software product, but they don't develop that software product by themselves.
(5:14 - 5:44)
They might use components from other developers. And so these components could be developed by a adversary, and there may be code included in that component that you may not necessarily want in your environment. So being able to go beyond just the vendor that's selling you the product and going back through the entire supply chain and having assurance that the people that are handling that product, the people that are coding or involved in the development of the product are not putting you at additional risk.
(5:46 - 6:11)
Right. And, you know, it's one of my, I would say one of our top threats right now that I just don't think we're as an industry doing enough about is software supply chain risk. That is a, yeah, there is no, there is realistically no organization out there that's not using some piece of open source technology or open source software that has its code somewhere on the Internet.
(6:11 - 6:39)
And who knows where it came from? Right. You know, most organizations have some kind of vendor risk process in place, you know, even if it's just a spreadsheet or a questionnaire, you know, there is every framework out there, right, requires you to do some kind of third party risk management, some kind of vendor risk management. But there's a, there's a big difference between having, you know, a process and policies and documents and having an actual program.
(6:40 - 7:17)
What are some of the, I guess you could say telltale signs that an organization is stuck in that sort of that checkbox mode and hasn't really operationalized that approach? Sure. And you kind of mentioned one of them as you were describing the process and that's they have a questionnaire and they have a spreadsheet that they keep the answers to those questions in and that's as far as they go. A solid third party risk or supply chain risk management program requires not just getting the answers to questions, but validating those answers and then following up on them to make sure that the vendor that's supplying the products and services hasn't changed their process.
(7:18 - 7:30)
So you can't just ask the questions one time. Vendors change, their interactions with others change, and you need to understand that. Additionally, you have to monitor potential breaches of those vendors.
(7:31 - 8:08)
The program that I developed, we actually had 24 hour monitoring of our vendors and anytime there was a breach or an incident involving those vendors, we were notified of that particular incident. And then the other thing is, is making sure that you're coordinating with intelligence sources using the ISACs and other intelligence sources that can give you information to let you know that there is something that might be out there that might be a threat to you. For example, a new vulnerability, CISA publishes vulnerabilities all the time and of course you have the National Vulnerability Database that produces those as well.
(8:09 - 8:43)
You have to know these things as part of a program and then even beyond that, a program also interacts with other parts of your organization. I mentioned vulnerabilities. If you're doing a vendor assessment or doing a product assessment for your third party risk or supply chain risk management programs and you find something that may be a risk to the organization, you need to tell others about that, especially if it's a vulnerability or something of that nature, or even you've got intelligence that says that there's been an attack against a particular component or a piece of what you're doing.
(8:43 - 9:02)
Make sure your incident response teams know that or your security operations teams are very aware of it. So it's broader than just a questionnaire. Also another thing that you want to do is make sure you have accountability to the vendors for doing the things that are right.
(9:02 - 9:24)
And that requires having some sort of security language or a security supplement in your contracts with the vendors so that they have accountability. They are required by signing that contract, they do certain things, whether it be notifying you of vulnerabilities or monitoring or controlling their suppliers. So there's a lot of things to a program that just a questionnaire and a spreadsheet don't cover.
(9:25 - 10:07)
Yeah, and you know, the big piece there that you touched on that I think is so important too is information silos, right? And I think we see that a lot in compliance and between compliance and security. And we're going to talk a little bit in a little while about procurement, how procurement gets involved in all of this. You know, when you do find out that a, you know, a vendor breach has happened, you know, are you finding out about it as the person running the TPRM program or did your legal department find out about it? And did they reach out to you, right? Like what, there's lots of ways to get to that and breaking down those information silos is obviously, it's very, very important.
(10:08 - 10:45)
We see that everywhere, right? In every process, in security, right? But, you know, you mentioned in your bio that, I mean, you work for one of the largest utilities in the country. That is a rather complex organization, right? And I know you've built these programs, these TPRM programs from the ground up and in large organizations just like that. And you know, once you have that policy and the executive buy-in, what does it actually take to turn that, that, you know, that package of this is our TPRM program.
(10:45 - 11:07)
What does it take to turn that into something operational, to go from the paper to practice? There's quite a few things, actually. First of all, you need to make sure you have the right type of staff and the right number of staff, whether it be internally or if you have to contract with someone to provide that staff. It's not a one-man job.
(11:07 - 11:36)
Trust me. I tried to do it as a one-man job when I first started the program and found very quickly that even just trying to do, trying to negotiate security supplements with a vendor is more than one person can handle. Again, I mentioned a while ago about intelligence sources, making sure that you have that intelligence feed coming into you, whether it be monitoring, continuous monitoring of your vendors or CISA or the ISACs, there's a ton of sources of information.
(11:37 - 12:05)
Vulnerability, National Vulnerability Database, knowing what's going on with the products that you have in your environment. And I've mentioned multiple times now, security contract language, you have to have good solid security contract. I developed a number of versions of security contract language and I made sure that my legal department actually went through it and they actually asked us to go ahead and manage it once we had it developed, but they did give us feedback on how to, how to make it more legally correct.
(12:07 - 12:22)
And then when you are evaluating suppliers, and I kind of mentioned this earlier as well, you can't just do it one time. You have to have a means. If you're having a continuing relationship with those vendors, you have to keep re-evaluating them.
(12:22 - 12:50)
And what we did with the program that I developed, we actually had, based on the security risks that we assessed, we had a recurring review of those vendors. So the ones that were the most critical, we would review them no less than annually. Those that were a little less critical, we'd go semi-annually and then the others we would go based on a change of conditions, whether it was a new contract or a change in the products or services they were supplying or something of that nature.
(12:50 - 13:16)
You have to develop a plan to do that continuous evaluation and make sure that you're up to date with what's going on with them. Another thing is being consistent. You have, if you've decided this is what you're going to do, you need to do it consistently and not hedge back and forth between what you're going to do one day versus the next day or with one vendor with a certain risk level versus another vendor with that same risk level.
(13:17 - 13:31)
Another thing is being flexible. You have to know what's going on in your environment and be ready to change your program or update your program as new risks surface. Ten years ago, we didn't think about AI.
(13:32 - 13:44)
Today, AI is a significant factor in your security program. So you have to be flexible. You have to know what's going on and be able to modify the program or update it.
(13:45 - 14:14)
And then with a program, you need to review the program itself annually as well. What has the risk appetite of your organization changed? Have your vendors significantly changed? Have the factors that are influencing your environment, you expanded your organization and now you have a bigger touch on the internet or have bigger volume of external vendors. And then another big thing is making sure that you're measuring your results.
(14:15 - 14:43)
Know what your successes are, know where your failures are and make the modifications as necessary where you're failing and continue to make sure that you're doing the right things to make sure you have success. I once had a mentor that told me that, you know, show me how you measure me and I'll show you how I perform. And so if you're not measuring yourself, you're not doing the things to know what your performance is, you're going to continue to perform and it might be a bad performance.
(14:44 - 14:58)
So make sure you're measuring. And then of course, making sure you report the leadership because you did get the buy-in from the leadership to begin with. So now you've got to make sure they're aware that what they told you you could do is successful in actually providing value to the organization.
(15:00 - 15:12)
Right. And, you know, you've mentioned being flexible and, you know, it's sort of, I think in your description, it's very much being adaptive, right? Adaptive to changes in the environment, internal, external environment and so on. Right.
(15:14 - 15:51)
One of the things, and I'll hit my question here in a second, I have had the, the, we'll say the privilege of being on several phone calls with vendors where they're very concerned about answering questionnaires because they feel like if they say, no, we don't do something, then that means we don't write a check. And, and I'm wondering if, and you talked, you touched a little bit on risk thresholds, and I'd like to hear a little bit more about that. I'm wondering if there was, where, where that flexibility extends to vendors.
(15:51 - 16:02)
Right. How do we, how do you, how do you manage that? Yeah, it's funny because you've heard the too big to fail. And sometimes there's vendors that are too big to assess.
(16:04 - 16:25)
The Microsofts of the world, the Oracles, the IBMs, you know, they're, they're huge. And some of these organizations that are going to try to do this are very small and have a very small footprint with those vendors and the vendors aren't going to want to go out of their way to do things that they don't normally do to be responsive. So you have to figure out how to best mitigate that risk.
(16:26 - 16:51)
If, if you can't get those answers by either siloing the product or controlling the product in a, you know, behind a firewall or whatever the case might be, there's things that you can do. You just have to decide what that risk is to your organization and what the appetite of that, the organization is for that risk. It's, you know, you really have to think about the vendors as a whole.
(16:51 - 17:00)
You have a variety of different levels of vendors. You have some that are supplying you pens and pencils. You have some that are mowing your lawns.
(17:00 - 17:29)
You have some that are accessing your facilities and you have some that are going into your server rooms and data centers and installing software and hardware, each one of those poses a different level of risk. So what we did is we had what was called a risk determination. And we just evaluated a certain set of questions where we said, okay, this vendor doesn't, doesn't give or doesn't indicate a sufficient enough risk to do any further evaluation, that vendor will keep an eye on it.
(17:29 - 17:42)
We'll continuously monitor them. But because of what they provide us, pens and pencils or lawn mowing services, they're really not a significant risk to our IT environment. And then we had others that were kind of in the middle of the road.
(17:43 - 18:11)
They might come into our environment. They might be servicing our vending machines, but even servicing a vending machine can introduce risk because now a lot of the vending machines actually access a network and, you know, depending on what network they're accessing, it could provide risk to you, or the physical person is now inside your facility behind your security perimeter. And, you know, they might present a risk by varying, going off someplace they're not supposed to.
(18:12 - 18:43)
And then of course, the ones that are going into your data centers and your server rooms and stuff of that nature, those are probably your biggest risk because they're actually able to put something in your system, in your network that could be a huge risk to your environment. So you have to, you have to determine what level of risk there is to decide whether you need to evaluate those vendors further or the supply chain even further, and then you have to rank that risk. How much risk do they present to you? How much do we care? Yeah.
(18:44 - 19:17)
Right. And because, you know, even though they may present some risk, again, knowing your organization's risk appetite, you can eliminate some of those or do a lesser evaluation of some of those because they don't present a significant enough risk to be able to go into this full in-depth assessment of the, of the vendor. And then of course, then you get into the, you know, the full assessment, the questionnaires, the validation of evidence, making sure they have the proper audits and certifications, that type of thing.
(19:17 - 19:36)
Those are all things that go into those larger, more risky vendors that you want to know. And then of course the continuous monitoring and all the other things we mentioned before. So it's a multi-tiered process and you just have to, you know, when I was doing the program, we had over 24,000 vendors that we had to evaluate.
(19:36 - 19:55)
There was no way we could evaluate all 24,000 vendors with a questionnaire and continuous monitoring and everything that we were doing. So we had to be able to eliminate some of those that were less risky and only focus on the ones that gave us the, you know, introduced the largest amount of risk to us. Yeah.
(19:55 - 20:12)
You know, I think that's the, that's the reality and that's the big problem. It's, we have the same conversation about, you know, the traditional notion of vulnerabilities. If I've got 50,000 vulnerabilities and I've got one person to fix them, that I don't have 50,000 vulnerabilities that I can fix, right? That's just not happening.
(20:13 - 20:24)
Organizations aren't managing 10 vendors, 12 vendors. It's a, it's a scale problem for sure. And you know, I thought it was really interesting too, because you'd mentioned and we see this all the time.
(20:24 - 20:49)
So I, at Fortress, I operate our security operations, our security compliance program, and our IT enterprise IT program here. And, you know, I, so we have to deal with this firsthand and it really is funny. I think it's, it is not a failing, people should know that it's not a failing on your TPRM program if Microsoft doesn't respond to your requests, because Microsoft doesn't respond to anyone's requests.
(20:51 - 20:55)
Yeah. So even if you pay for it sometimes. Yeah.
(20:55 - 21:05)
So I think it's, it's just really interesting. And, you know, that we do that same idea too, of risk ranking. So we have certain vendors that we'd consider critical vendors, and we do that through a risk intake form.
(21:07 - 21:38)
And, you know, this all gets baked into, into kind of, into definitely a much larger process. Because inevitably TPRM, SCRM, it will touch pretty much the whole organization, but it's really going to hit, you know, procurement, legal, IT, security, and, and, you know, the, the business operators themselves in their, in their line of business. And, you know, everyone at every one of those levels has different, different priorities in that process.
(21:38 - 22:13)
So, you know, how do you, how do you get all of those stakeholders aligned? How do you get them aligned? Number one. And then how do you get them, you know, working together without turning it into what I can only describe as just a political mess, right? Yeah, that's a very interesting question because that is not an easy task many times because nobody likes being told that they're not doing things well. And so you have to find a way of not telling them or telling them that they're doing things great, however, there's an area where you can gain additional information.
(22:13 - 22:43)
And, and so, you know, you talked about, you know, working with your your procurement group. One of the things that we did is we created a dashboard of the vendors that we did, had supplied from, and we put in there the foreign ownership control and involvement risk. Well, that was key for the procurement group because now they could look at that and say, well, you know, China's involved in this particular piece of critical software or critical hardware.
(22:43 - 22:53)
We might not want to do business with them. Let's look for an alternative. Sometimes there's not an alternative, but at least they know that there's something there that brings risk to the organization.
(22:53 - 23:13)
So, so you show your value to those organizations, show them that you have information that may be valuable to them. And then work with them, coordinate with them and collaborate with them to find out what they want or need from your program. Don't, don't think that you know everything and you're going to force them to take the information you have.
(23:13 - 23:34)
Find out what they want and need. And then see if you can provide that information to them. And again, I'm going to go back to measuring and reporting your results, showing them that by doing this, by giving them this information, we've potentially staved off a, an attack or a breach or, or a vulnerability attack or something of that nature.
(23:34 - 23:54)
Make sure you're measuring, make sure you're reporting to those people. This is what successes we've had. These are areas that we can, and oh, by the way, do you have anything that you would like as we make this improvement? Is there something that we can provide you as part of that improvement to help you? And then, you know, keep them involved all throughout the program.
(23:55 - 24:28)
We, we very closely work with our vulnerability management program from the third party risk management program and make sure that they were aware of products that we had in our environment. They may not see, they had scanning technology and everything, but it couldn't scan the entire network. But we knew because we were assessing the vendors, we knew what products were in the environment that may be inside a firewall that they couldn't scan through so we could provide that information, would give them an inventory of all that we knew about it and all the vendors that we knew about so that they could monitor for potential vulnerabilities in those products.
(24:29 - 24:42)
And then of course your security operations group. Anytime you have products, you have risk. And so working with your security operations group, making sure that they're aware of the products and services you have in your environment.
(24:43 - 25:19)
And then one thing that, that more secure or more mature programs may have is software bills of material and hardware bills of material, which tell the components, the vulnerability management program is not going to see the individual components. They will only see the finished product. So by knowing the components and say you have a product that might have some, some code in it that has been found vulnerable, but it doesn't show up in a vulnerability scan because it's a sub part of another product, you can show them and tell them that these products are exist out there and that they can monitor for those vulnerabilities.
(25:19 - 25:35)
So it's, it's, it's providing them value, showing them how you can give them information that they can use, but also find out what they want or need to help them be more successful as well. Yeah. And you know, it's, it's, it's interesting because you touched on that a little bit.
(25:35 - 26:15)
What I was going to say a little bit on that too, is one of the things we do at Fortress specifically is we are pretty well integrated between our security compliance, which is where our TPRM, SCRM programs fall under our legal and our finance procurement. And one of the things that we do is and this is going to, for anyone listening that works at Fortress, this is how we know when a new when number one, you have to file a risk rank, you have to do the vendor intake before finance will pay your bills. So if you, if you're going to pay someone, they're going to let us know that, Hey, this is happening.
(26:15 - 26:38)
And that's how we ended up finding out sometimes we've gotten a lot better over the years, but sometimes it's how we end up finding out. And, you know, I mean, to your point, there's, there's a lot of this, these, these tools, these applications that just don't seem like they would be a big deal on the surface. And, you know, and when you look at, and you, and you look at that and say, well, I've been using this application at home and I've never had a problem.
(26:39 - 26:59)
Right. But when you start looking at your organization, your compliance mandates, your real, very real security mandates, and you start looking at things like foreign control and ownership, they become, those things start becoming, you know, really important. I have had the, and I am not unique in this.
(26:59 - 27:20)
I've had the pleasure of making lots of people very angry by holding up their procurements and their whole process. And I guess, you know, for everyone, for anyone listening, that's that you are not alone in that, that is, that is kind of part of the security job in general. But, you know, to Jeffrey's point, it's very much a communication process.
(27:21 - 27:23)
You got to explain the why. Right. Yeah.
(27:23 - 27:36)
And then, you know, I talked a lot about the security side and the procurement side, but also the business side, you know, the business side doesn't want those delays that you mentioned. They want, they want to buy it now. They want to implement it now.
(27:36 - 27:56)
And you have to tell, you know, you have to show them why it's important to have this information and do these evaluations. And, you know, you're still going to get some resistance, but you just work with them and show them why it's important that they do this. And, you know, we, we overcame some significant hurdles when we first started our program.
(27:57 - 28:14)
Some of the lines of business didn't even want to talk to us. And over time we showed the value, showed why by showing them the intelligence that we were receiving about the products that they were purchasing and stuff of that nature. And then they started saying, Hey, you know what? I don't want my system to go down because of a vulnerability.
(28:14 - 28:23)
So yes, I think it's important that you do this evaluation. And we got, you know, we also gained efficiencies over the program. As the program matured, we gained efficiency.
(28:23 - 28:41)
So we weren't slowing the process down. We got involved earlier in the process of procurement. We were involved even at the RFP process, making sure that we have proper questions in the RFPs that gave some indication as to the risk and inform the line of business that, Hey, this vendor is, it looks pretty good.
(28:41 - 28:57)
We haven't done a full evaluation, but at least on paper in the initial look, it looks good. Or, eh, I really don't recommend this vendor because they really just, they indicate that they just don't have the controls in place to be able to make sure that they're providing. Yeah.
(28:57 - 29:27)
And, you know, I've, I've been, I've been on both sides of that, right. When, uh, when I try to buy a new, a new security tool or a new it tool, I, my, my team will stop me too. So, um, but you know, it is really interesting, even those tools that we think we trust that we, you know, from the vendors we've used forever, when you start looking into, into their background, sometimes you find out that they're not following even some of the basic security controls, or they tell you, no, we're not going to answer those questions.
(29:27 - 29:36)
Saying you're not going to answer the questions is probably worse than answering no on some of those questions. Right. Um, that, that indicates you are not willing to work with me at all.
(29:36 - 29:55)
Um, but yeah, I think it's, it's really, really interesting to, to, when you start going through that process and you start looking at some of these vendors that use you've used for a long time and you assumed that they were doing things a certain way and they really weren't. Yeah. That's, that's, that was, that's a big eyeopener for me.
(29:55 - 29:59)
And that's happened to me more times than I would like to more.