In part 2 of the webinar Claire hosted with Alla Valente and Vijay Krishnan they cover software supply chain, how to navigate fourth party risk and talked about offshore supply chain risks such as privacy and data sovereignty. They also covered some great audience questions.

Alla Valente is a senior analyst at Forrester serving security and risk professionals. She covers GRC, third-party risk (TPRM), supply chain risk (SCRM), and contract lifecycle management (CLM) strategy, best practices, and technology. Her research includes coverage of key regulatory compliance issues; risk management, ethics, and trust in digital transformation; and operational resilience. In this role, she helps Forrester clients build and mature a comprehensive programs that maximises business opportunity and performance while minimising risk and protecting the organisation’s brand.

Vijay Krishnan is the CISO at UniSuper leading Security Operations, Security Governance, Risk & Compliance, Security Strategy, Architecture & Design, Identity & Access Management, and Enterprise Observability.  In his role, he leads a multi-year security program to reduce UniSuper security risk thus protecting UniSuper members.  Vijay has extensive experience in negotiating clear and concise security and technology outcomes in regulatory, policy and outsourcing agreements delivering value creation opportunities.  He has large, diverse national and international experience with extensive executive and Board level exposure.

Links:

Alla LinkedIn

Vijay LinkedIn

Episode #48 The value of great boss with Vijay Krishnan+

Questions for Alla's upcoming recording with Claire

The Security Collective podcast is brought to you in partnership with LastPass, the leading password manager.

Transcript

CP: Hello, I'm Claire Pales, and welcome to The Security Collective podcast. This season, we have once again partnered with LastPass to bring you a live webinar. We were talking about supply chain risk during season 10. As is often the case, the live recording was too big for one episode, so this week we're bringing you part two of my live chat with Alla Valente and Vijay Krishnan. In part two, we cover software supply chain, how to navigate fourth party risk and we talked about offshore supply chain risks such as privacy and data sovereignty. We covered some audience questions, which were great, too, thanks to almost 400 people who registered for the webinar. And I hope you all enjoy the live version of this podcast playback. Here's part two with Alla and Vijay.

CP: If we think about supply chain security in terms of welcoming another organisation in who might be developing an application for us, or developing code, and they say, hand on heart, we have secure coding practices, . You know, so this future proofing of having a third party who's going to develop something for you to then put your crown jewels into. What evidence are you looking for from a third party who is claiming secure coding practices, but you've got kind of nothing to audit yet? What do you ask them for? How do they prove to you that you can trust them?

VK: Good question Claire, let me try to answer that. There may be a lot of benefits from outsourcing software development, right. As you know, getting highly skilled developers is hard. If an organisation such as us, purely focused on financial services, you don't have to have, you know, massive development teams to develop code for us. So it's best to also software development. But we should also know there are some inherent risks by doing so. To mitigate against the risk and ensure they deliver secure code consistently. It is prudent on us to ensure they follow safe practices. Some of the examples I would look for is we need to ensure they incorporate security into every phase of the software development cycle, right, we need to ensure that. They need to bake security during inception of the code and not as an afterthought, you got to ask questions on that,. We need to make sure that they provide some sort of a application security testing, static testing or dynamic testing to look for software vulnerabilities as they develop the code, not after the end of the cycle. We also need to ensure they document the code for us so they can trace back if there are any issues. Also, I will look for, you know whether they follow any established software development frameworks, like the NIST Secure Software Development Framework, or even follow the old apps principles, most of the web application vendors follow the old apps principles. It's very, very good in terms of setting the foundations for security, when we develop codes We also have to ensure they store the code in a secure restricted access repositories. As you know, some of the recent breaches are because the code has been exfiltrated. And they found vulnerabilities in the code and inject the code back into the organisation to create vulnerabilities. So you need to ensure that the code is secure and restricted. It's also good idea that we have to enforce them to see whether they encrypt our code at rest. Or deploy some sort of orchestration techniques, so that they can you know, it is not in plain text so people to read the code. I would also recommend they sign the code by using trusted authority certificates, not self signing. So these are the basic, you know, the foundation elements that any software vendor need to follow. I think these days, they do follow, but we need to ensure that the document that and ensure we check them, and they do that on a periodic basis. It's very, very important. Otherwise, you can introduce software vulnerabilities in the code, and without even knowing you get breached.

CP: Alla, you're nodding along in agreement. Did you want to add anything to Vijay's response?

AV: Yeah, just a couple of things. So one, earlier we talked about the different types of third party relationships, whether they be vendors, suppliers. There's also another category that I refer to as non-traditional third parties. These are entities, they're not your employees. They're not your executives. They are some other organisation that you're doing business with, and it doesn't always have to be a paid relationship. For example, a non-traditional third party could be perhaps an audit firm that is on retainer or an outsourced legal firm. If they have some sort of data breach, certainly your data is exposed, and that's third party risk. But one of the other categories that we seem to be talking a lot about these days is open source. So open source, you didn't develop it, you're not maintaining it, you can, because it's everyone can, but because everyone can, nobody does. And even commercially acquired software tends to have at least 50%, if not more open source code inside of their commercially developed product. So what I would say is, as a best practice, also ask for a software bill of materials. Find out what are the different software components that make up what they are developing, So that if there is a vulnerability in some way, you can, instead of trying to figure out where it is, you can look up and try and mitigate that and patch that right away. And the other thing I'll say is when you're working with these third parties, ask them whether they have a dedicated team that's dedicated to incident response, and also an incident response plan. Because these things happen, and two types of companies those have been breached, those that don't know they've been breached. But having working with an organisation that has a team that's dedicated to this can kick the plan into action, can communicate to you, can let you know whether they're going to be patching your patching, and what the next steps are. I mean, that type of communication can save, you know, not only millions of dollars, but really just to be priceless in terms of minimising damage and protecting your brand.

CP: Somebody's asked the question around the security considerations for fourth parties, particularly around MSPs, do either of you have an opinion on sort of managing the risk around fourth party compliance.

VK: So fourth party is always a tricky one, because we go into agreement with a third party first. And then we have all the legal contracts in with a third party. But I think it's prudent on us to ensure that in the legal contract, you have some statements for their supply chain as well for fourth parties to ensure if there is a breach who is accountable in the event of a breach. That's why it's very important when you enter into a third party relationship. We have clearly defined RACI roles and responsibilities in terms of you know, there is an issue who is accountable for what. We need to get that agreement in place before we sign the contract. Which may include in our having a good view on the fourth party, if it's a fourth party breach, who's accountable for it? Is it the third party or is it the primary organisation, so it's very, very important. And also, as I said to you before, all these legal clauses are good from a financial perspective, and also for terminating contract if you're not happy with the service. But from a reputational brand impact perspective, doesn't matter if a third party or fourth party, the primary organisation will be impacted.

CP: Alla, what are your thoughts around fourth parties?

AV: The challenge with fourth parties is that majority of organisations don't know 100% of their own third parties. Because there's so many relationships inside of the organisation. Some of them have been through procurement, some maybe have shadow procurement, so maybe not even on the radar to be able to do that type of risk assessment. Then there are these fourth party relationships. Now, if you have procurement, remember, I mentioned embedding some security questions into the RFP. One of those questions should be to list all the key fourth parties that are required for your third party to be able to deliver whatever this product service good is. So now at least you have a list of who those key fourth party say relationships are. Also you should be asking them whether or not they are assessing, and may be doing a scan, cybersecurity scan, or even asking for an updated business continuity plan of their key fourth parties. But even if that fails, we're seeing the rise of several types of tools. One is supply chain mapping, where you can visually map the different relationships to identify those fourth party dependencies. And also see, hey, do I have three, four or five third parties that are all using the same fourth party, because that can let you know about some concentration risk as it exists. But there are also a category of tools called supply chain elimination. Where you might not know who your fourth parties are, but they deploy bots that can look at things like different relationships, even payments that go between organisations to make connections and discover these fourth party entities that perhaps you didn't know you had. So there are some ways to fill in those gaps.

VK: It's always difficult when you deal with third parties, the reason being organisation as large as, you know, in excess of 300 or 400 third parties, you know, having an assessment for them, having a record of them and ensuring that you know we do a proper due diligence, gives us little time to understand their fourth parties. It's just a complex piece and time consuming. But having said that, like so, these days, we have some tools and technologies that are available, it gives a complete view on your third party or fourth party security posture based on the organisation context. How it works is by your third party may be engaged by another organisation, so they would have done a security review. So they document that and then they, you know, have some sort of a data gathering exercise which is available for others to use. So just like a collective information sharing platforms available these days, that gives you a good view on a third party. I think I would encourage organisations to having have larger third parties to look at those technology, and then do your own self assessment. Just an add on to ensure that you know, you have a full coverage on your third party as well as your fourth parties.

CP: It's mind blowing, how, you know, everybody's just getting their head around third parties, and now we're having to think about fourth parties. Alla, I'm interested to, and especially because I guess you're international for us. But what about people who want to engage with third parties who are overseas, because we're certainly seeing more and more of that, and data centres that might be offshore or service providers who might be in another country. And it might be exactly who you want to do business with. But it's just not in your ability to have your data remains sovereign or whatever the case is. What are some of the risks there for third parties? Because it might be that it might be your only choice, if that's how you want to make money and you know, risk is going to be involved. What should people be thinking about before doing business with a third party that's offshore?

AV: That's actually a great question. The simple answer is doing business with an offshore third party is very similar to doing business with an onshore third party. I mean, there's luck. Their cybersecurity information security posture is definitely one category of risk, but there's so many others, right. Things like financial viability, their sustainability, what does their business continuity look like? Whether or not they have any type of operational risks that could impact you. What is unique for those that are offshore are things like trade policies as they change, different supply chain events that can disrupt that value chain. Also the changing nature of global sanctions. You work with an international organisation, maybe you don't realise what their beneficial ownership structure looks like, and all of a sudden, now you find that they are on a sanction list. So what I would say about doing business with those organisations offshore is that obviously, the data privacy laws must be adhered to. But I find that even the mid to large, not so much the smaller ones, but at least the mid sized companies will have multiple options for where they host their data. Just be very specific about the questions that you ask them, and also make sure that it's in the contract. So it has to be a surface service level agreement to say my data cannot go here and cannot be processed this way to be able to cover yourself from that perspective. The other thing is, you have to have some sort of ongoing monitoring, screening of things like anti money laundering and sanctions list. You need to understand whether or not there are any type of trade restrictions that might be imposed. But what something that we've seen come out of this pandemic, and just the disruption of all third party ecosystems and supply chains, is that the size of the third party ecosystem is growing exponentially. In fact, organisations are working with double the amount of third parties. And it's not because they're looking to, let's say, buffer from these global geopolitical risks. It's for their own resilience, right, because if one entity gets caught up or is unable to deliver, they're looking to expand their supply chain into this 'just in case', to make sure that they're promoting resilience and buffering for any type of operational challenges that come up. That means they're going to have more third parties to work with. That means there's going to be a number of them that are international. Just following best practices to a point earlier rather than minimum compliance, go for this best practice. And, you know, if there's some sort of challenge with one supplier, hopefully you will have two or maybe more that provide the same service or the same category that you can lean into.

CP: Vijay, what are your thoughts on offshore suppliers?

VK: It depends on the data security requirements of the organisation. There are clearly specified requirements for us at UniSuper. There are certain countries that we can't host data at, that's number one requirement. So you need to ensure that you have strong contracts in place and also do a proper due diligence from the third party organisation to ensure that our data resides somewhere in the locations which is approved. Not only that, so, you know, we may host it out in the in the locations we prefer, but the organisation's resources may be offshore, they will access the data from offshore. So, what are the legal implications for doing that? And what are the applicable laws if something goes wrong? It's some of the things that, you know, the legal teams and the procurement teams have to be heavily involved. More than the security requirements in terms of you know, ensuring that we meet the organisation's requirements and rules, it gets important. Also, in what we see, from time to time, when we engage with third parties, most of the third parties who can service your business may be offshore these days, right. It's not that you can procure all the services in Australia, even you know, so we have to rely on offshoring parties. So the best simple method we follow is to engage with a larger size third party, for example, like Microsoft or Salesforce, and then to gain confidence to ensure that we assume and we take for granted that their security settings are good, and then they follow our requirements. And also, as Alla mentioned, we have to do constant monitoring to ensure that you know, that they meet our requirements, periodic audits, sharing security questionnaire. And also a full capture on their activity in your system. This gets very important having a proper RACI models and ensuring that they deliver to our SLA is also important. Also managing the third party, not just once engagement, we should have a quarterly or periodic business review with a third party to ensure that they follow our processes, and then to also ensure our systems and data are safe.

CP: I've got a couple of questions from the audience. And one of them relates back to what you were just talking about Vijay around bigger vendors and selecting bigger vendors. Is there any insights from either of you around the challenges that you get presented with by dealing with those big vendors, because you can't negotiate the contracts. You can't just pen test Salesforce. How do we navigate around that when we're sort of at the whim of these bigger organisations?

AV: In fact, I just wrapped up some research on this specific topic. Talking more broadly about concentration risk, right. So now you have these much larger vendors who either own the market or maybe it's a very sort of duopolistic market. Even large vendors have vulnerabilities, have data breaches, have downtime. So how do you manage around that? Understanding how much of your business is dedicated and devoted to that third party. Also understanding single points of failure, not only where they lie, but which products, which revenue lines, what areas of your business that particular incident or downtime might cause. Building some sort of risk assessment and having a contingency plan. I mean, that's pretty much all you can do. You know, in some cases, we don't get to choose exactly who we work with. But we do get to choose the quality of our risk management programme and process.

CP: Vijay, any tips or insights on dealing with the bigger players?

VK: You know, as you mentioned, it's very hard to probe into their security posture, they don't share much information. But then what we can do from a from an organisation perspective, to ensure it all depends on how we engage with a third party. What sort of configuration we follow, to ensure our data is safe. So they provide limitless options to third parties like Salesforce, or even Microsoft, to ensure our data is safe, they provide good visibility. So it depends on the skills and the capability of the parent organisation to ensure that we configure them correctly, to monitor them correctly, we get the logs back to appear on systems, and we you know, exception alerting all that is possible. So that's the steps I would like to follow. I like to you know, take care of what I can do, I can manage. You know, in terms of configuration monitoring, and then the visibility and options the third parties provided, I would like to go further and use them to ensure that our security systems are safe. That's the only way we could do it, because, you know, they will not share much information.

CP: The next question from the audience is around liability. And my thinking is you're probably both going to talk about putting something in the contract. But if you have a breach with a third party, the question from the audience who is liable, isn't the primary party or the third party supplier to compensate a customer in the case of a third party breach? You know, is it in your case Vijay is it UniSuper or is it in one of your third parties? Who would you say is liable?

VK: I think it's tricky question to answer is depends on the on the contract and the the legal process we have with a third party and what we can hold them to be liable for. I think it's very important that we have a proper RACI model and understand the obligations of each other before we engage the third party. So we can exactly know who is accountable for the breach. Undoubtably the place I would start would be to have a clear RACI, and proper documented SLA. And have the RACI clearly specifies who's accountable for what component of the breach. Also, I would encourage bigger third parties to have some sort of a incident response plan. As you know, as Alla mentioned. We need to practice the incident response plan to the third party to ensure we limit the damage. Not often, when there's a third party breached, it means that all your data is exfiltrated, there'll be some symptoms. And then, you know, having a proper incident response plan will limit the damage for the third party or the parent organisation. But having said that the regulators like APRA it's clearly specified that if your member information is breached, it's the parent organisation who's accountable. So we can, you know, just because we outsource, we can outsource the accountability. So we are still accountable. Maybe from a financial perspective, we can recover costs for third party, but in terms of reputational damage, we can never do that. So you got to be really careful in your legal process, make sure you, you know, understand your risks, and get the senior stakeholders engaged. And then this element of acceptance of risks as well here.

CP: Alla, did you have anything to add about liability, whether or not it's the first party or the third party?

AV: In terms of liability, a trend that we're seeing is that more large customers are asking specific third parties, especially if they're critical to their operations, or to their firm, to get specific cyber insurance policies then name them as the sole beneficiary. So we have these first party cyber insurance policies. And now we're also seeing third party cyber insurance policies. Now we know this market has more supply or rather more demand than we have supply, so those are going to be easy to get. But asking for a policy such as that can at least shield some of the financial costs. I completely agree with Vijay, reputationally, it's going to be more about what you did once you identified it, how you're able to respond, whether you communicate clearly with those impacted. All of that will influence the significance of the reputational hit that you're going to take. So you might win the financial battle, but lose the reputational reward. And that's not something any organisation wants.

CP: No, and that's probably the most challenging thing as well is the ability to continue to do business with a third party after they've had a breach, you know, it's your reputation is potentially on the front page of the paper. This could be a material third party that you can't run your operation without them. And yet, trust has potentially been dissolved through a third party breach. And to Vijay's point, if you understand how in the face of a breach, the incident would be managed, there's a very good chance that you'll be able to come out the other side, because everybody's on the same page about what happens in the face of a crisis. And there's trust, and there's communication. If you haven't had those conversations, and they are really key part of your supply chain, and things go south and there's an incident. I think that's where if trust dissolves, you could be in all sorts of bother. It's not just about financial, it's about that trusted reputation and those relationships.

AV: The good news, though, is that as consumers we've had, we've all been a victim of a breach, in fact, probably multiple breaches. Even as professionals, our businesses have worked with their parties that have experienced a breach. So there is some tolerance, you know, it's not like, oh, my goodness, this company got breached. I mean, certainly not the way it was, you know, five years ago, 10 years ago. That said, if you take a very laissez-faire approach, if you're not communicating, if you don't take steps immediately to rectify, that will hurt your reputation. But if you do the right things, there is a level of leeway and forgiveness and look, you know, there's so many breaches. The good news is that we'll be on the next breach that's on the news, which, you know, everyone has short memories right!

CP: Vijay, thanks for your time and Alla thank you for staying up late for us all the way from New York City. Thanks, everybody, cheers.

CP: Well, that's a wrap from our live webinar recording part two. If you enjoy the perspectives of today's guests, we have more of their insights to share. For Vijay, head to our back catalogue to Episode 48. And for Alla I'm thrilled to be heading over to meet her next week to interview her in person for the podcast. If you have questions you're keen for me to ask her about third party risk or GRC, please head to thesecuritycollective.com and contact us. You will be able to hear ours responses in our upcoming episode 104. Thank you and I'll see you next time.