Jul 12 2023

Shared Responsibilities: The Core Tenet Of Third-Party Risk Management

Category: Vendor Assessmentdisc7 @ 11:04 am
https://www.forbes.com/sites/forbestechcouncil/2023/07/12/shared-responsibilities-the-core-tenet-of-third-party-risk-management/?

Third parties (vendors of products or services) are responsible for a significant portion of cybersecurity incidents or data breaches at customer organizations.

Amid all the focus on third parties, what is often not discussed is that customers themselves might be in a position to possibly detect or contain the damage from certain security incidents on their own, regardless of the third party’s association with the cause of the incident.

The concept or principle of shared responsibilities between customers and their third parties was originally conceived and popularized in the context of public cloud service providers and their customers.

I don’t think the shared responsibilities principle should be limited to public cloud services. It could apply just as well as a core tenet to the security of any product or service that customers source from their third parties. This discipline of information security—of customers managing security risks in the product or services sourced from third parties—is commonly referred to as third-party risk management (TPRM). Terms such as “vendor risk management” or “supply chain risk management” are also used synonymously.

The shared responsibilities tenet of TPRM is illustrated well in the MOVEit breach that has been in the news over the past month.

It is clear from the vendor’s own account that the breach resulted from security vulnerabilities in the vendor’s product, MOVEit Transfer. What might be missed on the vendor’s page, however, is that the vendor did not detect the vulnerability on their own.

It appears they might have learned about the vulnerability from the calls they received from their customers indicating suspicious activity on May 28, 2023. This was likely within a day of when the adversary started exploiting the vulnerability, as reported by Mandiant.

The customers who detected the adversary’s activity had likely done a diligent job of implementing the vendor-suggested security best practices, especially the practice related to reviewing audit logs for anomalous behavior.

By having such effective detection mechanisms in place, as well as implementing the other security best practices suggested by the vendor, it wouldn’t be far-fetched to say that these customers might have been in a position to act in a timely manner and prevent significant impact from the adversary’s actions.

On the other hand, there are likely many other customers who may not have undertaken the due diligence to implement the vendor-suggested best practices and operate those practices effectively. Such customers may not have discovered the exploit in time, which could have resulted in sensitive data being stolen by the adversary.

In my view and experience, the shared responsibilities tenet often does not get due recognition or necessary focus at customer organizations. TPRM programs at the organizations are usually focused on assessing risks posed by vendors (i.e., the vendor portion of the shared responsibilities). They may not “close the loop” by evaluating how well their own organizations have implemented their part of the shared responsibilities.

I believe the ecosystem of customers and third parties could implement and operationalize shared responsibilities in their TPRM programs through several means, including but not limited to:

• Contracts: Emphasize each party’s portion of the shared responsibilities in contract documents.

• Transparency And Communication: Vendors should provide necessary and actionable details regarding customers’ part of the shared responsibilities in their self-assessment reports, as well as communicate the responsibilities to customers in a proactive manner, especially when new features require updates to shared responsibilities.

• Program Charters: Customer TPRM programs should update their program charters and governance to emphasize that the program’s objective is not limited to assessing risks posed by the vendor, but that it should also assess and mitigate risks associated with how their own organizations use the goods or services provided by the vendors.

• Governance And Ownership: Customer TPRM programs should clarify the roles and responsibilities of internal sponsors and other stakeholder teams that use vendor services.

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

Cybersecurity Risk Management

CISSP training course

InfoSec tools | InfoSec services | InfoSec books

Tags: Third Party Risks, TPRM


Jun 26 2023

What is TPRM?

Category: Vendor AssessmentDISC @ 10:45 am

https://www.datagrail.io/blog/data-privacy/what-is-tprm/?

Tags: TPRM


Aug 28 2022

Why You Need a Third-Party Risk Management (TPRM) Program

Category: Vendor AssessmentDISC @ 9:56 am

What entity, or sector doesn’t engage with a third party in some way, shape or form? Not many. The reality is that outsourcing, contracting and subcontracting happen all the time and is the norm as businesses continue to embrace the core/context mindset and division of labor. The more you outsource, the more you need to have a robust third-party risk management process (TPRM), also known as vendor risk management, plan in place.

Risk management is not new, but the current iteration of TPRM logic typically focuses on three parts:

  • Risk assessment and analysis
  • Risk evaluation and
  • Risk treatment.

I had the pleasure of chatting with David Medrano, director of third-party risk management at Morgan Franklin, who shared his insight on the importance of TPRM and vendor oversight. Medrano explained that many enterprise entities may have over 1,000 separate third-party engagements and, therefore, must have a methodology to measure the risk each of those presents.

Medrano said that while many entities know their contractors, they may lack visibility into the contractor’s contractor; thus, a daisy chain of outsourced work may be taking place which places data at an unknown level of risk as the third party shares it with a fourth party and so on. The most important thing an organization can do, in this case, is to categorize vendors in the planning/strategy phase. Suggested risk buckets may include critical vendors, physical vendors and technology vendors.

“Bucket them according to how and what they do and how their third-party actions present a risk to you,” Medrano said. The risk from the coffee vendor, for instance, is not the same as the risk provided by an MSSP. He advised caution with regard to allowing more risk to be accepted than the vendor’s worth or value to the enterprise.

Medrano also advised keeping the methodology used uniform, as that can help manage risk while also showing customers, regulators and compliance entities that the company has a methodology in place to measure and address risk and explains the company’s thought processes with regard to its actions.

TPRM Tools

Ironically, there are a plethora of vendors (yes, third parties) who are prepared to provide you with tools to create your TPRM program, there are also standardized methodologies available from the U.S. government. For example, the National Institute of Standards and Technology (NIST) has created a TPRM framework to help companies create a consistent and uniform TPRM plan which is adaptable to their unique needs. The NIST framework can help you:

  • Prepare – Essential activities to prepare the organization to manage security and privacy risks
  • Categorize – Categorize the system and information processed, stored and transmitted based on an impact analysis
  • Select – Select the set of NIST SP 800-53 controls to protect the system based on risk assessment(s)
  • Implement – Implement the controls and document how controls are deployed
  • Assess – Determine if the controls are in place, operating as intended and producing the desired results
  • Authorize – Senior official makes a risk-based decision to authorize the system (to operate)
  • Monitor – Continuously monitor control implementation and risks to the system

In sum, every business unit should be using a TPRM system, regardless of if their engagement with third-party vendors is centralized or decentralized. Additionally, uniformity in the assessment is of paramount importance, Medrano said.

Third-Party Risk Management: Driving Enterprise Value

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

IT Vendor RISK Management Toolkit

Tags: Third Party Risk, Third Party Threat Hunting, Third-party risk management, TPRM, Vendor Security Assessment


Feb 25 2021

Third-party risk management programs still largely a checkbox exercise

Category: Vendor AssessmentDISC @ 9:19 am

Recent data indicates that they are inconsistent (at best) when it comes to digging deep enough for clues of security issues lurking in the enterprise’s vendor and partner ecosystem. Even more troubling? Very few TPRM security assessments result in remediation action.

So TPRM programs are nominally jumping through hoops to ask vendors about or observe their security controls. But few of them are actually doing much to work with their vendors to bolster the security of these third-party IT environments.

This was one of the key findings of a recent report compiled by Cyentia Institute on behalf of RiskRecon. Conducted among 154 TPRM professionals operating in a range of industries, the study showed that a whopping 81% of respondents admit they rarely require remediation from third parties after an assessment.

And that’s not because everything is fine and dandy with these vendors’ security controls. The survey showed that a slim 14% of these professionals are highly confident that their vendors are performing security requirements. That’s not from an utter lack of investment. At this point some 79% of organizations have a formal TPRM program, with a median of at least two full-time employees. Some of these programs are just getting underway, but many have been established for some time and the average age of these programs is now five to six years.

Obviously, these investments in TPRM programs are not being fully realized through effective risk reduction, so what gives? The survey results indicate that this may be classic checkbox compliance scenario. According to respondents, regulatory compliance is the runaway top driver for development of their company’s TPRM program. Some 62% cited compliance as their number one motive for running a program, in contrast to just 22% who named executive mandates and 16% who cited customer requirements.

This likely explains why so many organizations today still rely so heavily on security questionnaires, as that’s the bare minimum required by most compliance regimes. The survey showed that twice as many organizations regularly utilize questionnaires – 84% – as compared to those (42%) who utilize a more verifiable assessment method like cybersecurity ratings. This is in spite of the fact that only about one in three TPRM professionals actually believe questionnaire responses.

Clearly there’s more work to be done. The good news is that the forces at play within the TPRM world are following a maturity playbook that most cybersecurity and risk professionals know well.

Tags: Third-party risk management, TPRM