Next Generation Third Party Cyber Risk Management (TPCRM)

Most organizations do a fair job of tracking their security posture from code to cloud. They generally track the following portions of their threat surface:

• Application Code and Infrastructure as Code (IaC)
• Container (Kubernetes, Docker, Micro services)
• Cloud (Workload protection, CSPM)
• Corporate Infrastructure (Data Centers, Offices, Firewalls, Network devices, etc.)

Given the comprehensive focus above, one would expect a similar rigor in tracking Third Parties. Unfortunately the same rigor simply does not apply to Third Parties of the organization. You may ask why? Let us see in more detail below.

How do organizations assess the security posture of their Third Parties?

It is a mix of the following:

• Outside view of the Third Party (limited to external websites/applications, public IPs/Servers, DNS records, etc.) - While this is an important aspect, it overlooks (and undermines) other frequently used methods by attackers like social engineering attacks, phishing attacks, malware, ransomware etc. which are delivered via an out of band channel. Once the attacker/hacker gets a foot inside, then they need to leverage privilege elevation and RCE type of vulnerabilities to move around in the network. Hacker want to get a persistent foothold and exfiltrate sensitive data. But the outside assessment does not provide a view of the security posture of internal systems, which the attacker navigates to reach systems housing sensitive information.
• Point in time security assessment reports (shared as “dated” evidence) - Vendor may provide a vulnerability assessment report from the last couple of quarters or year as reference for record. Given that the security landscape is ever changing and evolving, such a VA report serves no practical value.
• Questionnaires (details about prioritization, remediation/patching cycles etc.) - Note most of these are simply on paper, as it is difficult to provide evidence around this.

Ideal security view of Third Party

Given that organizations share confidential information about themselves and their customers with their Third Parties, it is vital to have a comprehensive view of the security posture of their Third Parties (like they do for themselves). Let us consider an example to illustrate this fact as follows: An organization shares customer invoice data with their Analytics Partner (Third Party) for further processing. This Analytics Partner may have a data pipeline to crunch the customer invoice data in their cloud subscription. They may be running multiple VMs in the cloud which some standard analytics software (like Spark or Hadoop) which has custom code deployed to gather specific analytics. In such a scenario, the organization needs a view of the security posture of the Third Party’s Cloud VM, CSPM (aka misconfigurations), Analytics Software (Spark/Hadoop/etc.) and the custom code for any vulnerabilities.?

In a nutshell, an organization needs to have an "inside-out" comprehensive view of the security posture of their Third Parties from code to cloud (akin to the view that they have for themselves).

The future of TPCRM

Regulation from the White House (Executive Order 14028 dated May 2021 from The White House) has resulted in developments which facilitate a unique inside-out view of the security posture of your Third Parties using SBOMs. Software Bill Of Materials (aka SBOM) is an artifact which enumerates a list of ingredients which make up software components. The SBOM essentially can be used to get a clear picture of the security posture based on the details present in the SBOM artifact.

There are two main standards of SBOM which have gained adoption over the years: SPDX and CycloneDX. SBOMs facilitate an inside-out view of the security posture of your Third Parties. This provides the organization with a true picture of things and will also help in terms of collaboration and prioritization.

ThreatWorx platform offers comprehensive support for SBOMs. The platform supports both SPDX and CycloneDX standards. Also it caters to all scenarios from SBOM ingestion to maintaining, tracking multiple SBOM versions and automation. ThreatWorx has support for its own proprietary SBOM, which can be used to convey related security aspects like CSPM / Misconfiguration issues, Code security issues, Secrets detected in source code, and more. ThreatWorx platform also allows one to export SBOM standard artifacts.

Using SBOMs the ThreatWorx platform allows an organization to track an inside-out view of the security posture of their Third Parties from code to cloud. Don’t be blind sided anymore but get a real view of the security posture of your Third Parties.