What can security professionals do differently to better manage supply chain risk?

I look back in my career and when I was a finance person in '93 in Intel's IT organization, I nationalized computing. And I built a supply-chain for hardware, software. Why? Because I was a finance guy. Inventory management is the only way to control cost. Well, when I circled back into security, luckily all of that was still there because everything funneled through the purchasing processes I had built eight years earlier. It wasn't perfect but I had 95% inventory management from the day I landed and it saved my ass. And then I pivoted from there, being a former finance and procurement guy and thinking about trust in supply-chain stuff even years ago, well before the whole third-party risk management stuff went out I started embedding third-party risk type stuff into the purchasing and financial controls. We had the whole notion that trust would become the attack surface and the thing you trusted the most was the thing that would make you most vulnerable, which then framed how we strategically really worried about things. Hell, when everybody was adamant about encryption, I was so flipping paranoid about the use of encryption. If we mismanage the key or somebody gets those keys, we're screwed. I was worried about ransomware in 2005/2006. Just with deployment of hard disk encryption and all that other stuff, because I'm like, "You get a rogue admin, somebody owns the box, you own this..." You could literally have created the ransomware events then, without even doing malware, if you just had the right aspects to the infrastructure and shut off certain things. I don't know where it's at, at Intel these days, but as I grew in that everybody always wanted to take away from me and I'm like, "No, I want to be the inventory manager because it will then give me the base of things." I still have debates with peers on that because they think of it as unglamorous but I go, "It's such a critical dependency to the role and if it's not being done right, take it over so that it can be done right. So, that you can then execute your role." I think that the whole third-party risk management approach is like doing a SOC 2, and it isn't sufficient. You go, "Okay, I've got some basic controls and I can answer some policy questions, but doesn't tell me that they know the risk issues and that they're managing them well." Which was why, when I was at Intel, when I was at Cylance, hell even at Cymatic, I go have a conversation with my peers at my critical vendors that could cause me substantial harm and then potentially my customers. The lawyers and compliance team might want all those questions and stuff like that, but I want to know my peer and go, “Can I trust you?” And you're going to answer my direct questions. And if there's any wishy-washiness, then I worry. This approach also allows you to take more risks. The riskiest technology in early adopters of technology should be the security team. Why? Because we're the risk manager so we should be the ones taking the risks ahead of everybody else so that we can figure out how to manage them before everybody else gets there. And instead, we create all these encumberments to innovation that then causes people to go around us, which means we're actually generating risk by slowing people down. And we should be the first mover. Run to the riskiest things first. Once you're there you can sort it before other people get there. It's completely counterintuitive to our DNA, which is to be risk-averse. We should be the biggest risk takers on technology because then we actually manage risk to our organization better.

Anonymous Author
I look back in my career and when I was a finance person in '93 in Intel's IT organization, I nationalized computing. And I built a supply-chain for hardware, software. Why? Because I was a finance guy. Inventory management is the only way to control cost. Well, when I circled back into security, luckily all of that was still there because everything funneled through the purchasing processes I had built eight years earlier. It wasn't perfect but I had 95% inventory management from the day I landed and it saved my ass. And then I pivoted from there, being a former finance and procurement guy and thinking about trust in supply-chain stuff even years ago, well before the whole third-party risk management stuff went out I started embedding third-party risk type stuff into the purchasing and financial controls. We had the whole notion that trust would become the attack surface and the thing you trusted the most was the thing that would make you most vulnerable, which then framed how we strategically really worried about things. Hell, when everybody was adamant about encryption, I was so flipping paranoid about the use of encryption. If we mismanage the key or somebody gets those keys, we're screwed. I was worried about ransomware in 2005/2006. Just with deployment of hard disk encryption and all that other stuff, because I'm like, "You get a rogue admin, somebody owns the box, you own this..." You could literally have created the ransomware events then, without even doing malware, if you just had the right aspects to the infrastructure and shut off certain things. I don't know where it's at, at Intel these days, but as I grew in that everybody always wanted to take away from me and I'm like, "No, I want to be the inventory manager because it will then give me the base of things." I still have debates with peers on that because they think of it as unglamorous but I go, "It's such a critical dependency to the role and if it's not being done right, take it over so that it can be done right. So, that you can then execute your role." I think that the whole third-party risk management approach is like doing a SOC 2, and it isn't sufficient. You go, "Okay, I've got some basic controls and I can answer some policy questions, but doesn't tell me that they know the risk issues and that they're managing them well." Which was why, when I was at Intel, when I was at Cylance, hell even at Cymatic, I go have a conversation with my peers at my critical vendors that could cause me substantial harm and then potentially my customers. The lawyers and compliance team might want all those questions and stuff like that, but I want to know my peer and go, “Can I trust you?” And you're going to answer my direct questions. And if there's any wishy-washiness, then I worry. This approach also allows you to take more risks. The riskiest technology in early adopters of technology should be the security team. Why? Because we're the risk manager so we should be the ones taking the risks ahead of everybody else so that we can figure out how to manage them before everybody else gets there. And instead, we create all these encumberments to innovation that then causes people to go around us, which means we're actually generating risk by slowing people down. And we should be the first mover. Run to the riskiest things first. Once you're there you can sort it before other people get there. It's completely counterintuitive to our DNA, which is to be risk-averse. We should be the biggest risk takers on technology because then we actually manage risk to our organization better.
0 upvotes
Anonymous Author
Develop a third-party risk program, ensure that your contracts hold your vendors accountable to specific controls or frameworks
0 upvotes