Earlier this week Claire hosted a webinar with Alla Valente and Vijay Krishnan as they shared their insights on supply chain security versus third party risk. In part 1 Vijay covers APRA's CPS234 and the need for effective security controls, not just compliant ones. We also cover the role of legal and procurement in the third party assurance process. There's a tonne of great insights to be gleaned from both Alla and Vijay in this ever present risk.

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. In season 10 we've once again partnered with LastPass to bring you a live webinar this time we spoke about supply chain risk. As is often the case the live recording was too big for one episode, so for the next two weeks, we'll be sharing with you the webinar recording. This season I was joined by Alla Valente and Vijay Krishnan. Alla is a Senior Analyst at Forrester serving security and risk professionals. She covers GRC, third party risk, supply chain risk and contract lifecycle management, strategy, best practice and technology. Alla has a BA in English from Hofstra University, and has completed the Business Analytics Programme at Harvard with distinction. I was also joined by Vijay Krishnan, who's a good friend of the podcast and he leads UniSuper's information security function, including a multi year security programme to reduce UniSuper's risk and protecting UniSuper members. Previously, Vijay was leading information security at Transurban, accountable for IT and OT, including accountability for PCI DSS. In today's first half of the webinar, Vijay and Alla share their insights on supply chain security versus third party risk. Vijay covers APRA's CPS234 and the need for effective security controls, not just compliant ones. We also cover the role of legal and procurement in the third party assurance process. There's a tonne of great insights to be gleaned from both Alla and Vijay in this ever present risk. Please enjoy part one of our supply chain security webinar recording.

CP: So third party risk, third party security, supply chain security, whatever you want to call it is a hot topic at the moment and certainly has been for last couple of years. And I don't think it's going anywhere in a hurry. So I thought we might kick off today by asking you Alla what is the difference? Third party security, supply chain security, are they the same? People use this term interchangeably. What are your thoughts from an industry analyst perspective on the terms that people are using to describe this type of risk?

AV: There is two things to unpack I think with that question. The first is the variation of nomenclature. And you're absolutely correct, some organisations refer to it as third party, some call it supply chain. What we find here is that in the US especially, because of the regulatory requirements, the OCC regulations, financial services, banks, insurance companies, they tend to refer to third parties. However, healthcare organisation, we'll call these third parties and will refer to them as business associates just to comply with and be more aligned with HIPAA regulations. Then you have manufacturing organisations and those with physical supply chains that like to refer to them as suppliers. But wait, there's still more because then there's this whole group of organisations that refer to vendors. And those vendors are primarily service providers, software technology vendors, and for a large period of time because of compliance regulations, organisations needed to assess their IT vendors, their security providers, and for many organisations, their third party risk programmes are still very much focused very narrowly on that vendor piece. But the second piece I want to talk about is this security. So we know about information security, but that's not the only security area that organisations need to evaluate. There's also physical security, which is becoming much more relevant, especially as we see the convergence of IT and OT. But then there's also supply chain, that's part of the software supply chain. So we all remember the devastation after Log4J and Solar Winds. Now we're getting into a software supply chain. And all of these things are unique and distinct and different.

CP: And I certainly think that some of that confusion doesn't make life easy for either side, whether or not you're the person who's asking for your supplier to give a questionnaire about information security controls, or you're on the other side trying to work out what on earth you should be asking your third party suppliers. Vijay, you have been through this recently, well, I guess since 2019, when APRA came forward and said CPS 234, we're going to put some new regulations in place. And third party supply security became I guess part of the vernacular then for information security professionals. Was this on people's radar before CPS 234, I guess particularly for the financial services industry?

VK: I believe so Claire, even before APRA's CPS 234 came into effect more than a few high profile breaches we witnessed put the security industry on notice and made everyone realise the importance of third party security and why it is important to ensure that they need to operate with the same level of security hygiene as the parent organisation. So for example, in 2017, well before the APRA regulations came into effect, we had the Uber breach where personal information of 47 million customers was breached. It was reported that it happened through GitHub, a third party to them at the time. Also in 2018 we had that Marriott breach if you recollect, where the personal information of 500 million guests were exposed. It is reported in that event, that it happened to that Starwood Hotels acquisition, which goes to show the importance of security due diligence during acquisitions and mergers. Also in 2019, Facebook was breached exposing 540 million Facebook users information. It is widely reported a third party was involved. Also the industry based regulations like GDPR well before APRA's time. HIPAA as Alla mentioned, the Health Insurance Portability and Accountability Act. Sarbanes Oxley Act and also PCI DSS have long before specified the requirements for organisations on what they need to do to manage the third party security. In Australia, so when APRA implemented the third party requirements in 2020, it was not a surprise for the security industry. But it helped us to ensure proper investment in cybersecurity, and also help to elevate cybersecurity conversation to the board and senior stakeholders in the organisation. So my view it was in people's radar, especially the security community, and we always knew there was a risk with third parties and engaging them to deal with our critical information.

CP: So do you feel like people therefore shouldn't have been coming from a low base? Where do you start when the regulator comes and says, actually, we think you should have mechanisms in place to know who everybody who you're doing business with. And for some particular vendors or suppliers, we think you should know a little bit more about their security controls and their security approach. Do you think most organisations were coming from a low base? Or where did you start, I suppose is the question.

VK: It's good question, Claire. I know we always you know, we know the inherent risk for engaging third parties. We always you know, when you join a new organisation, always back of your mind, always think about how do we deal with third parties. I have a few simple steps, because I started UniSuper on a similar journey, and I have a few simple things I followed which I can share. The first thing is a robust third party assurance programme allows an organisation to ensure that the data and systems in trusted third party are maintained in a secure and compliant manner. So the key steps here are firstly what we need to do is conduct a thorough audit of the business to identify all third parties that provide services to the organisation. Play special focus on third parties dealing with company sensitive information, including personal information. That should be our prime focus, right, because those third parties deal with your crown jewels. Also design and develop some sort of a third party agreement, either as a policy or a standard to ensure consistency while dealing with third parties. Also ensure appropriate alignment with the procurement and legal teams, as usually, the third party engagement starts with them. It's not the security, security's later. So I would recommend preparing a security assessment questionnaire by clearly specifying your must and should requirements that the third party needs to comply with. The question must be based on the organisation's contract. For example, UniSuper is a financial services organisation. We have financial information, we have personal information. So our context should be based on that and also to meet our regulatory and compliance requirement. The fourth point, I would encourage you to ensure you have appropriately skilled team who can review the third party assessment response. No point in just handing over a questionnaire and the response we don't know how to deal with those responses. Don't know how to assess the responses based on your risks. So we need to have appropriately skilled and trained people to assess those responses back. Also, I would encourage to invest in a tool or technology that will independently assess the security posture of a third party and provide a real time view on the security posture. As you know, security is a dynamic environment. It's not that you do an annual exercise, and you assume that everything is safe and secure. We need to have a real time view on your third party. So a lot of tools available in the market these days to give you a dashboard on where the security posture of a third party sits at the moment. Finally, ensure a periodic review of the third party, you know it depends on the security exposure and the risks they manage for us. Ensure you do an annual audit or off yearly audit based on the criticality and sensitivity of the information that they manage. So I think these are the key steps with every organisations they need to follow to start this journey.

CP: Just picking up on a couple of things that you spoke about, you talked really about this is sort of being a living, breathing, you know, ongoing assessment. But often we have this conversation around making sure our legal documentation and our contracts are giving us coverage. And Alla I'm keen to hear from you about is there a point to having information security clauses in contracts? Do they only protect us when an incident happens? When you put these in place can you rely on the clauses in the contract, I guess, in in any case, particularly when you just want maybe a right to audit as well. You know, to Vijay's point, if we want to be talking to these organisations about their controls, do we need to have that in the contract? What's been your experience of some of the clients that you've worked with?

AV: I think it depends. There are organisations that will use a legal contract as a risk management vehicle. And that's extraordinary. It can help you significantly. However, something that we see a lot of in the US and even in some parts of Europe as well, where organisations are doing their due diligence after the execution of the contract. And you know, that's a little bit backwards, because there really is no leverage that the organisation has to hold the vendor or a third party accountable for those security requirements. The other thing is that without doing that type of due diligence, prior to even vendor selection, you don't know what those key clauses that could be added to the contract are. So do you need to add more requests for maybe it's an annual audit, or some sort of third party assurance or validation maybe you want to have the third party get a certain level of cyber insurance. Perhaps now, maybe the level of risk or their security posture means that whatever the contracted amount is, is no longer a good deal for you. And you need to change that pricing, because that's what risk management is, right? We don't manage risk so we can remove risk. We need it to grow, we need to innovate, like all of that is taking risk. We manage risk so that we know what are the risks that are worth taking? And what is the proper cost that we're willing to pay for that level of risk. You don't want big risks, low rewards. So when organisations are using that legal vehicle, doing their due diligence, putting in those clauses that not only protect the relationship throughout but also give them legal standing to terminate the relationship in the event of some sort of, maybe it's a breach or maybe it's indication that perhaps the vendor wasn't really performing the level of due diligence they agreed to, then yes, absolutely. The contract can become a vehicle, an extraordinary vehicle for third party risk management. But for everyone who's using due diligence after the contract, you know, what is that term? The horse has left the barn, the horse has bolted, it's a bit too late to really do anything meaningful about it.

CP: And how can we rely on the procurement team, for example, to help with that process? What role should the procurement team be playing because some organisations procurement is just sort of a pass through and it's just really quite administrative. But when we're talking about security and wanting to have the right contracts in place, and as you said performance of that contract as well. And I'm keen to hear your view on this as well Vijay, what is the role of procurement when we're talking about third party assurance?

AV: So procurement isn't responsible for third party assurance, they're not accountable. However, they are a point of entry for that relationship that can't be overlooked. So we see procurement really adding a lot of value to the third party risk process. If they are using the RFP to also ask some key security questions, a best practice that I've definitely seen is organisations that will ask anywhere from 5-10 questions on in the RFP about certain security protocols. That's a great way to exercise and identify some red flags that you just want to maybe not consider for that particular third party. Another is to be able to once again, work with the information security, the risk and compliance teams to be able to score the RFP results but score them through the context of risks. So perhaps this is a great vendor supplier for us to use, the price is right, what they can deliver works for us. However, there could be some red flags that will make us need to re-evaluate whether or not the risks of doing business with them are worth it. In that case, procurement then can add to that risk management perspective, because it really shouldn't be on the risk team exclusively. However in collaboration with sourcing, with information security, and also with vendor management, right, because you're working with a vendor or supplier, the contract is up, it might be up for renewal, it might go back to procurement to renegotiate. Understanding how they perform from that security perspective, from a risk perspective, will help the procurement teams be able to work with third parties that are, you know, advantageous without taking on an undue level of risk.

CP: What are your thoughts Vijay about procurement? And I guess in your experience, leveraging them for the benefit of risk?

VK: Yes, sure. So before I respond to that question, I would also like to clarify regarding the legal process we just talked about before. We have to be careful that the legal process will cover us in terms of a financial perspective, but it doesn't cover us from a reputational damage or brand damage. So, you got to be very whatever legal costs to put in for the organisation, if there is a breach, your reputation is damaged. So you got to ensure that you know, you can't assume that the legal clause will cover us in that event, just to take note. And also to answer this question Claire, so traditionally as you know, supplier assurance is a major component of any procurement team. Where they will assess against as Alla mentioned, financial risk insurance, standards, their suppliers, the fourth parties, and also continue to delivery. Cybersecurity is often overlooked, as you will know, when I started UniSuper, it was not that stringent as where it is now. However, the recent high profile incidents and breaches and regulators like APRA in 2020 have ensured that cybersecurity assessment for the third party is an integral part of the supplier assurance programme. You know, the audits that are done on APRA's CPS 234, the key areas they explore is how is our third party security managed? They check our, you know, documents records and also our assurance programme. So how the procurement team can help us in this changing landscape? So they can help us to ensure cybersecurity requirements are captured, as Alla mentioned, documented, and the third party is assessed to ensure they meet our organisation's regulatory requirements, including safety of systems and data. So they also need to ensure it's not just an one off assessment, because we always rely on our procurement teams to inform us and notify us when is the contract up for renewal. So we need to have clear indication, clear line of sight in when contracts expire. And also we don't want to be subject to just a one off assessment. As you know, the risk is a daily list. It happens all the time. So we need to have a periodic assessment. Assessment should be comprehensive based on the impact criteria. So every third party shouldn't be treated the same, it should be treated based on the risk. Do the third party handle the critical information? Do the third party handle a privacy information? Do they need access to our network? So do they need access to our API's if there are cloud based systems? And what harm would it cause the risk of breach and data loss? So based on the impact criteria, they should determine whether the third party supplier is a high impact supplier or a low impact supplier, so we have to treat them differently. So once the criticality is determined, the procurement team should devise assurance mandates, assessment methodology for the third party working closely with the security teams. This will also include artefacts we require from them to confirm the security posture and the frequency of repeat assessments. So these are the few things where the procurement team, the legal team and the security team can work together to ensure the third parties the organisation engages remains safe at all times.

AV: I really like what Vijay said about every vendor needs a contextual assessment. What I will say though, is very often and quite honestly, this is internationally it has been a standard where criticality has been determined based on spend. If we spend enough money with this vendor supplier, they're considered critical to our business. I think that's a misconception that can get us into a lot of trouble. There are some relationships that have a high spend, but they may not have access to the type of data that can be detrimentally sensitive. While you have other vendors that are much smaller, perhaps even a shorter engagement. Just as a best practice what I usually speak to Forrester clients about is if they have somehow have access into your network or infrastructure, they're high risk and they need a thorough risk assessment. If for any reason they have access to any financial information, any customer information, any employee information or any intellectual property, they are high risk. Regardless of how big they are, regardless of what their cybersecurity posture looks like. They can be that conduit that leads to some sort of security incident or breach, and shouldn't be overlooked.

CP: And I think that Vijay made a good point earlier too, about fourth parties and how, you know, just because the third party you're engaging with might not be a high spend, or might only have access to a small amount of data, we don't necessarily always know who they're sharing it with, and how they're treating it, which I suppose comes back to the regular assessment. I'm really interested to talk a little bit too about the compliance nature of third party assurance. And that, you know, we see regulators like APRA, and in other countries as well, instilling this requirement of compliance. So if you assess a third party, and you have a checklist, and everybody's happy on both sides that there are controls in place, there's not always sort of the next stage around whether or not those controls are effective. And we're seeing a lot of organisations now go out and get, you know, SOC2 compliance or ISO compliance in order to appease these, this barrage of third party assurance questionnaires that are coming in. I'm interested in both of your opinions on this kind of compliance versus effective security controls. And are we getting a bit caught up in this? I don't know, Vijay did you want to go first.

VK: So compliance is not equal to security, right, we should all make that very clear. Compliance is a set of required requirements that every organisation needs to follow. It doesn't mean that if you follow all the compliance requirements, the organisation will be secure. I would start by, you know, thinking about security based on the crown jewels of the organisation. So if you know what your crown jewels are, if you know where the crown jewels sit in the organisation, if you know who has got access to the crown jewels, including a third party, that's where you need to ensure to apply the security controls. I mean, compliance, you know, it's required, but I would start with security first. So they are not the same. So once you know where the crown jewels are, in terms of your access controls, who has access to the data, where it is stored, how it is stored, including the third parties if you do, to ensure that we have proper controls in place, and satisfying to your organisational contacts and the security policies and standards, I think that would be the first start, and then compliance comes later.

CP: Do you feel that if an organisation came to you if you were the third party and they said, we want you to prove that these controls are effective, and they're in place. What's the level of comfort around that level of audit, I suppose, or vice versa, if you went to another company and said, we want to see that your controls are effective? Do you feel like some people are uncomfortable about putting that proof or giving that evidence or showing that?

VK: Yeah, absolutely. I mean, like major vendors like Microsoft or Salesforce, they will not share when you can do a penetration testing on the organisation, you can't ask many questions. All they share with you is their SOC2 report and also share with you the list of customers they have. So you have to gain confidence and trust saying that, you know, they are a major third party vendor and they're secured and the systems are secure. In most cases, that's the case. I mean, they are now major organisations like Microsoft, Salesforce, and AWS who are inherently secure in how they operate the business. But I think it's more than relying on them, we have to ensure what controls we have. We need to see whether we can you know, do some sort of a user activity monitoring, the access based monitoring, do some session recording, to make sure your organisation is protected. In terms of security controls, you can rely more on what they say and what they have. But our aim is to protect our data, organisations data, we need to ensure that what sort of controls and confidence we need to have to ensure that our data is protected. So you have to start from there.

CP: Alla, what are your thoughts about you know, are we down a rabbit hole with compliance? Or are people really, as Vijay said, putting security first?

AV: I will echo everything that Vijay said. For me, compliance is your floor, it's not your ceiling. It's not what you should be striving for. This is your basic minimum viable security programme. I'll take a slightly different approach and talk about compliance from a regulatory change perspective. So we often find that compliance requirements will ask for the bare minimum, just understanding how much of a heavy lift it is for companies to get to that level of compliance. But when we talk about the burden of compliance, the cost of compliance, it's not initial compliance, it's change management. Because when something changes, you need to then identify where's the change? What applications, what processes does it impact? What do I need to do to get to that next level of compliance? So if you are managing to best practices, and I'll call them more broadly risk management best practices, right? What are the standards that could put your organisation at risk? And you're managing to that best practice level, then if there is a regulatory change, chances are you're already buffered and shielded from it because as you're already going above and beyond what that minimum level of compliance is. I had a former colleague who did an amazing presentation about compliance. And he had this one slide and an image with the gentleman on a motorcycle and a helmet on, and not much else. But technically, he was compliant because he had that helmet. And that's how we need to think about compliance for third parties, right? Just because they've answered a questionnaire and maybe we ran an initial scan and did maybe a cybersecurity ratings check. It doesn't mean that they're actually compliant or that as their business changes and their security posture changes, that they'll still be within our thresholds. Compliance, or rather, the need to check for compliance is ongoing. Having minimum controls doesn't mean you're safe, and it still puts your organisation at risk.

CP: Thank you so much for joining me this week for part one of the webinar with Alla, Vijay and LastPass. Definitely tune in next week when we cover what secure coding evidence you might need to ask for when using third party developers. We also talk about how to navigate fourth party risk and we spoke about offshore supply chain risk. Thanks again, and I'll see you next week.

CP: If you enjoy the perspectives from today's guests, we have more of their insights to share. For more from Vijay, head to our back catalogue and listen to episode 48. For Alla I'm thrilled to be heading over to meet her next week in person to interview her 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 to your questions in our upcoming episode 104.