Tag Archives: cybersecurity

If the United States Won’t Pay For the CVE Program…Who Will?

From The Register:

“The [CVE] program is sponsored, and largely funded by the Cybersecurity and Infrastructure Security Agency, aka CISA, under the umbrella of the US Department of Homeland Security. It appears MITRE has been paid roughly $30 million since 2023 to run CVE and associated programs.”

$30 million is peanuts. 

If the U.S. government won’t fund it (and it still may), and if private firms won’t fund it, perhaps the EU will take it over. Or Canada. Or China. 

The only complication is whether MITRE can run it if someone other than the feds is paying.

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.”

If Your Identity System Only Manages People, It Is Flawed

This is painful, but it has to be done.

I’ve spent 30 years working with the identities of PEOPLE and ensuring that all PEOPLE accessing a system are properly identified.

In other words, leaving a huge GAPING security hole.

Look at what Okta is doing;

“[N]ew Okta Platform capabilities…help businesses secure AI agents and other non-human identities with the same level of visibility, control, governance, and automation as human ones. The Okta Platform will now bring a unified, end-to-end identity security fabric to organizations for managing and securing all types of identities across their ecosystem, from AI agents to API keys to employees.”

I think that “unified” will take the place of “trust” as the identity buzzword. Thankfully.

If you’re only selling biometrics, or maybe biometrics and ID cards, where will your customers go to get the rest of their systems? Or will you just be a commodity supplier to the companies that provide the REAL systems?

(Unified security AI picture from Imagen 3)

When Can Cybersecurity Professionals “Wing It”?

In my career, I’ve experienced all levels of process maturity, ranging from “process for process’ sake” to “winging it.”

  • Many, many years before Marie Kondo popularized the term “spark joy,” one of my former employers shut down the entire office for the afternoon so that we could spend that time cleaning up. Thankfully this was not instituted (institutionalized?) as a weekly occurrence.
  • On the other extreme, some organizations resist process and just wing it. To the point that I literally hide when I use a process.

Now the ability to “wing it” can be used in some circumstances but not in others. Obviously improvisational comedians “wing it” by definition. But Ike (pre-matrix) couldn’t have used the “wing it” approach on D-Day.

What about cybersecurity? Can you “wing it” when you’re attacked?

Jack Freund says no:

The evolving threat landscape demands robust governance architectures and well-defined board duties to ensure resilience against cyberthreats. Effective cybergovernance not only protects an organization’s digital assets but also reinforces trust among stakeholders. 

Governance is a critical component of cybersecurity, if for no other reason than to prove that your organization actually HAS cybersecurity. Ideally an organization will govern its cybersecurity by some type of “maturity model.”

And that’s more than refraining from calling someone a poopy head.

(AI image from Imagen 3)

Why Do CPAs (the real ones) Manage SOC 2 Audits?

I’ve been around a ton of compliance frameworks during and after the years I worked at Motorola. 

  • The Capability Maturity Model (CMM), from the days before CMMI came into being.
  • The entire ISO 9000 family.
  • The General Data Protection Regulation (GDPR).
  • The California Consumer Privacy Act (CCPA) and the related California Privacy Rights Act (CPRA).
  • The Health Insurance Portability and Accountability Act (HIPAA).
  • The NIST Cybersecurity Framework (CSF).
  • I’d personally throw the FBI CJIS Security Requirements onto this list.

SOC it to me

There is one compliance framework that is a little different from CMM, ISO, GDPR, and all the others: the System and Organization Controls (SOC) suite of Services. 

The most widely known member of the suite is SOC 2® – SOC for Service Organizations: Trust Services Criteria. But you also have SOC 1, SOC 3, SOC for Cybersecurity, SOC for Supply Chain, SOC for Steak…whoops, I made that one up because I’m hungry as I write this. But the others are real.

Who runs the SOC suite

But the difference about the SOC suite is that it’s not governed by engineers or scientists or academics.

It’s governed by CPAs.

And for once I’m not talking about content-proposal-analysis experts.

I’m talking about the AICPA, or the Association of International Certified Professional Accountants.

Which begs the question: why are a bunch of bean counters defining compliance frameworks for cybersecurity?

Why CPAs run the SOC suite

Ask Schneider Downs. As an accounting firm, they may have an obvious bias regarding this question. But their answers are convincing.

  • “CPAs are subject matter experts in risk management.” You see, my reference above to “bean counters” was derogatory and simplistic. Accounts need to understand financial data and the underlying risks, including vulnerabilities in cash flow, debt, and revenue. For example, if you’ve ever talked to a CxO, you know that revenue is never guaranteed.
  • “It was a natural progression to go from auditing against financial risk to auditing against cybersecurity risk.” Now this may seem odd on the surface, because you wouldn’t think mad Excel skills will help you detect deepfakes. But ignore the tools for a moment and look at a higher levels. Because of their risk management expertise, they can apply that knowledge to other types of risk, including non-financial ones. As Schneider Downs goes on to say…
  • “CPAs understand internal control concepts and the appropriate evidence required to support the operating effectiveness of controls.” You need financial controls at your company. You aren’t going to let the summer intern sign multi-million dollar checks. In the same way you need to identify and evaluate the internal controls related to the Trust Services Criteria (TSC) associated with SOC 2: security, availability, processing integrity, confidentiality, and privacy.

So that’s why the accountants are running your SOC 2 audit.

And don’t try to cheat when you pay them for the audit.

And one more thing

A few of you may have detected that the phrase “SOC it to me” is derived from a popular catchphrase from the old TV show Rowan & Martin’s Laugh-In.

A phrase that EVERYBODY said.

(Wildebeest accountants from Imagen 3)

Another Take on NPEs and Security

I learned about the following story via the Identity Jedi, which leads me to my early and self-serving call to action:

If you’re interested in identity, The Identity Jedi Newsletter is a must-read. It’s packed with educational and insightful content. And if you would like to subscribe to the newsletter, please use my referral link: https://www.theidentityjedi.com/subscribe?ref=YoUVK0Uos1&_bhlid=7fecfad9eb7fd8bcdb529e945e11346b5897acdc I’m in the running to get an Identity Jedi mug. Thanks.

Enough self-serving content. Let’s get to what I learned about in the newsletter: namely, this article from CSO Online, “The urgent reality of machine identity security in 2025.”

As you know, I’ve been spending more and more time concentrating on identity issues when a person is not present. This is what the attribute-based access control folks refer to as “non-person entities” (NPEs).

In the article, CyberArk’s Scott Carter makes the following points:

  • Today there are many more machine identities than human ones.
  • They may have a short shelf life. Unlike humans, who usually access your systems for months or years if not decades, machine identities may be “created and discarded dynamically in minutes.” (Incidentally, I just wrote a LinkedIn article that delves into this in more detail.)
  • These identities are being breached. “Half of the surveyed organizations experienced security breaches tied to compromised machine identities within the past year.”

What does this mean?

Well, for CyberArk, it means that it endorses technologies such as automating certificate lifecycle management. And by the strangest coincidence, CyberArk offers a solution…

But for us, it means that we don’t only need automation, but we also need governing processes to ensure that ALL the people and NPEs that are accessing our systems are properly managed, quickly commissioned, and quickly decommissioned.

(Image from Imagen 3. Yes, I’m falling into the habit of reusing images for multiple use cases. It’s easier that way.)