Driver’s License Data and Third Party Risk Management

It gets real tomorrow, with the enforcement date (sort of) for REAL ID at federal installations and airports. But what about the privacy of the data behind REAL IDs?

Bela Kumar of Jumio Corporation was recently interviewed by CNBC for an article about REAL ID and the data sharing behind it.

As can be expected, some people are very concerned about what this means.

“[C]oncerns persist among privacy professionals that the next step will be a federal database of driver’s license information, which is bad from a privacy and cybersecurity standpoint, said Jay Stanley, a senior policy analyst with the American Civil Liberties Union.

“‘The more information the government has, the more the government might use that information,’ said Jodi Daniels, founder and chief executive of Red Clover Advisors, a privacy consulting company. ‘But that’s not what’s happening now,’ she added.”

Kumar addressed what IS happening now, and whether our personally identifiable information (PII) is protected.

“States have been issuing driver’s licenses for many years, and personal information is already being stored. The expectation is that the same controls apply to Real ID, said Bala Kumar, chief product and technology officer at Jumio, an online mobile payment and identity verification company. ‘States have already been managing this for many years,’ Kumar said.”

If you continue to read the article, you’ll also see a statement from the American Association of Motor Vehicle Administrators that echoes what Jumio said.

But as a former IDEMIA employee, my curiosity was piqued.

Has anyone ever gained unauthorized access to a state driver’s license database?

So I checked, and could not find an example of unauthorized access to a state driver’s license database.

But I DID find an example of unauthorized access to driver’s license DATA that was processed by a third party. The State of Louisiana issued a notice that included the following:

“On May 31, 2023, Progress Software Corporation, which developed and supports the MOVEIt managed file transfer platform, notified all customers across the globe, including [Louisiana Office of Motor Vehicles], of a zero-day vulnerability that an unauthorized party leveraged to access and acquire data without authorization. Upon learning of the incident, immediate measures were taken to secure the MOVEIt environment utilized to transfer files. A thorough investigation was conducted, and it was determined that there was unauthorized acquisition of and access to OMV files in the MOVEIt environment….

“The information varied by individual but included name and one or more of the following: address, date of birth, Social Security number, driver’s license, learner’s permit, or identification card number, height, eye color, vehicle registration information, and handicap placard information.”

Well, at least the hacked data didn’t include weight. Or claimed weight.

Cybersecurity professionals know that you cannot completely prevent these hacks. Which explains the “risk” in third party risk management. Progress Software has been around for a long time; I worked with Progress Software BEFORE I began my biometric career. But these hacks (in this case, CVE-2023-34362 as documented by CISA) can happen to anyone.

Be cautious, and remember that others with good intentions might not be cautious enough.

Now I’m Just Playing with Google Gemini

I asked Imagen 3 to help me illustrate nth party risk management.

Where you are connected with everyone to whom your connections are connected.

But I wanted to illustrate third-party risk management in a clean way. Back when AIDS became a sad feature of our lives in the 1980s, the description of how it spread from person to person could get a little graphic.

The Military, Cyberattacks, and Maturity

Everyone knows that cyberattacks don’t just target private organizations. They also target governments, particularly aiming for agencies that either deal with a lot of money (unemployment agencies) or contribute to defending a country (military, homeland security).

The Chief Information Officer of the U.S. Department of Defense has a vested interest in preventing cyberattacks, not only against DoD, but against its third-party suppliers, which are the subject of today’s acronym, DIB (defense industrial base).

And if you’ve followed along in the Bredemarket blog lately, you know that a key component of preventing cyberattacks is raising your organization’s process maturity in the cybersecurity realm.

And yes, there’s a maturity model and a certification for that, the Cybersecurity Maturity Model Certification, or CMMC.

Cybersecurity is a top priority for the Department of Defense (DoD). The defense industrial base (DIB) faces increasingly frequent, and complex cyberattacks. To strengthen DIB cybersecurity and better safeguard DoD information, the DoD developed the Cybersecurity Maturity Model Certification (CMMC) Program to assess existing DoD cybersecurity requirements.

It’s no surprise that the CMMC incorporates multiple levels, in this case three of them.

  • Level 1: Basic Safeguarding of FCI (Federal Contract Information)
  • Level 2: Broad Protection of CUI (Controlled Unclassified Information)
  • Level 3: Higher-Level Protection of CUI Against Advanced Persistent Threats

And not only is there a maturity model certification for the defense industrial base, but there’s a conference to help everyone out. After all the geeks celebrate May the Fourth Be With You day, some of the geeks will continue to celebrate on May 5, the date of the fifth annual CMMC Day. Party on.

Also see Biometric Update’s article, as well as NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.

And if you need product marketing assistance with your cybersecurity product, Bredemarket has an opening for a cybersecurity client and can help with compelling content creation, winning proposal development, and actionable analysis. Book a call: https://bredemarket.com/cpa/ 

(Military wildebeest image from Imagen 3)

A Mature Approach to Artificial Intelligence-Powered TPRM Automation

Deloitte conducts regular surveys on third-party risk management (TPRM), and just concluded a survey on (English warning) “the rise of AI in TPRM to maximise opportunities while managing the risks.”

One of the key findings:

“Despite low maturity levels, leadership teams are ambitious about embracing intelligent automation, while managing both the risks of AI in their organisations and those arising from third-party AI usage.”

I’ve talked about maturity levels before and their importance in cybersecurity. While ad hoc approaches to TPRM just won’t cut it in terms of protection, a managed or defined level or better will yield a positive return on investment.

(Imagen 3)

And one more thing…

The formal announcement is embargoed until Monday, but Bredemarket has TWO openings to act as your on-demand marketing muscle for facial recognition or cybersecurity:

  • compelling content creation
  • winning proposal development
  • actionable analysis

Book a call: https://bredemarket.com/cpa/ 

Frame, Assess, Respond, and Monitor (FARM) in Third-Party Risk Management

I just listened to a third-party risk management (TPRM) Mitratech webinar about NIST cybersecurity frameworks, hosted by OCEG, which talked about a farm.

No, they’re not planting corn at NIST’s Gaithersburg headquarters.

(At least I don’t think so. I haven’t been there since early 2009, back when Motorola and Safran people couldn’t talk about the possible acquisition. We did anyway. But I digress.)

Back to TPRM. In Mitratech’s case, FARM stands for “frame, assess, respond, and monitor.”

Here’s how Mitratech introduced the topic in a 2022 post:

NIST SP 800-53 is considered the foundation upon which all other cybersecurity controls are built. With SP 800-161 Rev. 1, NIST outlines a complementary framework to frame, assess, respond to, and monitor cybersecurity supply chain risks. Together, SP 800-53 and supplemental SP 800-161 control guidance present a comprehensive framework for assessing and mitigating supplier risks.

If you visit the latest (as of 2024) update to SP 800-161, you can find NIST’s explanation of the FARM in Appendix G. The three referenced levels in the quote below are the enterprise, mission, and operations levels.

The first approach is known as FARM and consists of four steps: Frame, Assess, Respond, and Monitor. FARM is primarily used at Level 1 and Level 2 to establish the enterprise’s risk context and inherent exposure to risk. Then, the risk context from Level 1 and Level 2 iteratively informs the activities performed as part of the second approach described in The Risk Management Framework (RMF). The RMF predominantly operates at Level 3 [SP80037], – the operational level – and consists of seven process steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor.

Briefly:

  • Frame establishes the context.
  • Assess is the risk assessment itself.
  • Respond is where the assessors communicate the results of the assessment and propose mitigations and controls.
  • Monitor is compliance verification and continuous monitoring.

Section G.2 of the document includes much, much more detailed definitions of the FARM elements, should you be interested. I’d provide those details myself, but then I fear I’d have to say to you, “Sorry if I’ve stayed too long.”

NPRM

Back in January I wrote a post entitled “TPRM,” and I want to expand upon that post.

But first I want to talk about [REDACTED].

Because people who have been around for a while have heard the phrase that if you’ve ever had [REDACTED] with someone, you’ve had [REDACTED] with everyone they’ve ever had [REDACTED] with. At least in terms of [REDACTED] transmitted diseases. Lloyds Pharmacy Online even developed a “[REDACTED] degrees of separation” calculator to quantify that exposure.

Beyond third-party risk

But enough about [REDACTED]. Your company’s data and information are subject to similar threats.

I mean, it’s all well and great for you to adopt a third-party risk management system to make sure that your vendors and suppliers aren’t letting bad things happen to your data and information.

But guess what? All those third parties have third parties of their own.

Risk and Compliance Magazine explains:

A fourth party is an independent entity that provides services to you on behalf of your third-party service provider – also known as your third party’s third party. A fourth party is also known as a subcontractor or sub-outsourcer. Fourth parties have not signed an agreement with your organisation, so they do not have a legally binding obligation to your business. Your third party itself may subcontract all or some obligations of their agreement to you to another service provider.

An example

Let me delve into an example that I touched upon in my January post.

  • Let’s say that you did business with Bank of America.
  • You checked out Bank of America’s systems as part of your due diligence.
  • Perhaps you determined that everything was right and fine with the bank.
  • But it was NOT right and fine with one of Bank of America’s software providers, which is a FOURTH party to you.
  • So there’s this other system that you never contracted with.
  • But perhaps you’re one of the unlucky 414-plus Bank of America customers whose data was exposed because of this fourth party.

And the fourth parties have fifth parties, the fifth parties have sixth parties, and so fourth. I mean forth.

Making an impact

Luckily there are companies that provide aids not only to address third-party risk, but also nth-party risk when data is transmitted all over the place.

Hence my acronym NPRM, Nth-party risk management.

Which really stands for “notice of proposed rulemaking,” but what the hey.

Anyway, these companies and many other technology companies are making an impact.

But does anyone know what these companies are doing?

Perhaps Bredemarket can help your company make an impact with my content, proposal, and analysis services. If so, let me know.

(The image was created by Imagen 3.)

TPRM

(Imagen 3)

A little (just a little) behind the scenes of why I write what I write.

What does TPRM mean?

I was prompted to write my WYSASOA post when I encountered a bunch of pages on a website that referred to TPRM, with no explanation.

Now if I had gone to the home page of that website, I would have seen text that said “Third Party Risk Management (TPRM).”

But I didn’t go to the home page. I entered the website via another page and therefore never saw the home page explanation of what the company meant by the acronym.

They meant Third Party Risk Management.

Unless you absolutely know that everybody in the world agrees on your acronym definition, always spell out the first instance of an acronym on a piece of content. So if you mention that acronym on 10 web pages, spell it out on all 10 of them.

That’s all I wanted to say…

How is NIST related to TPRM?

…I lied.

Because now I assume you want to know what Third Party Risk Management (TPRM) actually is.

Let’s go to my esteemed friends at the National Institute of Standards & Technology, or NIST.

What is TPRM?

But TPRM is implied in a NIST document entitled (PDF) Best Practices in Cyber Supply Chain Risk Management. Because there are a lot of “third parties” in the supply chain.

When companies began extensively outsourcing and globalizing the supply chain in the 1980’s and 1990’s, they did so without understanding the risks suppliers posed. Lack of supplier attention to quality management could compromise the brand. Lack of physical or cybersecurity at supplier sites could result in a breach of corporate data systems or product corruption. Over time, companies have begun implementing vendor management systems – ranging from basic, paper-based approaches to highly sophisticated software solutions and physical audits – to assess and mitigate vendor risks to the supply chain.

Because if MegaCorp is sharing data with WidgetCorp, and WidgetCorp is breached, MegaCorp is screwed. So MegaCorp has to reduce the risk that it’s dealing with breachable firms.

The TPRM problem

And it’s not just my fictional MegaCorp. Cybersecurity risks are obviously a problem. I only had to go back to January 26 to find a recent example.

Bank of America has confirmed a data breach involving a third-party software provider that led to the exposure of sensitive customer data.

What Happened: According to a filing earlier this month, an unidentified third-party software provider discovered unauthorized access to its systems in October. The breach did not directly impact Bank of America’s systems, but the data of at least 414 customers is now at risk.

The breach pertains to mortgage loans and the compromised data includes customers’ names, social security numbers, addresses, phone numbers, passport numbers, and loan numbers.

Note that the problem didn’t occur at Bank of America’s systems, but at the systems of some other company.

Manage your TPRM…now that you know what I mean by the acronym.

Nine types of risks to list in your proposal

When you are writing in response to a Request for Proposal (RFP), you are often asked to address the risk of the program and/or of your solution.

Example of risk assessment: A NASA model showing areas at high risk from impact for the International Space Station. By National Aeronautics and Space Administration (NASA):NASA Johnson Space CenterOrbital Debris Program Office – Orbital Debris Education Package, Public Domain, https://commons.wikimedia.org/w/index.php?curid=2760870

And even if you’re NOT asked to address risk, it’s a good idea to do so. Claiming that your solution implementation has NO risk shows that you don’t know what you’re talking about.

But what types of risks do you find in a project?

In this case, the government IS here to help.

In a presentation to the APMP Chesapeake Chapter today, Dwayne Baptist of Lohfeld Consulting Group pointed the attendees to a particular portion of the Federal Acquisition Regulation (FAR) that discusses risk.

FAR 39.102 addresses “Management of risk” for federal projects, and helpfully includes a list of nine types of risk:

 (b) Types of risk may include schedule risk, risk of technical obsolescence, cost risk, risk implicit in a particular contract type, technical feasibility, dependencies between a new project and other projects or systems, the number of simultaneous high risk projects to be monitored, funding availability, and program management risk.

From 39.102 Management of risk. | Acquisition.GOV

If it’s easier to read this way, here is a numbered list of the nine types of risk cataloged in FAR 39.102(b).

  1. schedule risk
  2. risk of technical obsolescence
  3. cost risk
  4. risk implicit in a particular contract type
  5. technical feasibility
  6. dependencies between a new project and other projects or systems
  7. the number of simultaneous high risk projects to be monitored
  8. funding availability
  9. program management risk

So if you’re uncertain of the types of risks that your project may encounter, you can use the list in FAR 39.102(b) as a starting point.

You can use this list even if you’re not responding to a federal procurement…or even if you’re not responding to any procurement at all and just want to identify the types of risks in your project.

Of course, identifying the risks is only the beginning. You have to mitigate the risks, and you have to communicate how you are mitigating the risks. Baptist addressed those topics also.

You should have been there.

But even if you weren’t there, Baptist has written an article entitled “How to Win with Risk” that you may find helpful.

(And if you attended the meeting, you will see that Baptist repurposed parts of his article in today’s presentation. Repurposing is good.)