Joseph Davis

I’ve been thinking about exposure management less as a tooling problem and more as a systems problem. When discovery grows faster than mobilization capacity, exposure doesn’t just increase — it compounds. That accumulation is exposure debt.

16

2 Comments

I spend a lot of time with manufacturers and product teams who aren’t questioning whether they must comply with the Cyber Resilience Act (CRA) they’re stuck on the how. The CRA is clear on the obligations, but in practice the hard part is interpretation: software distributed online, products that depend on cloud back-ends, continuous updates, open-source components, product families, legacy models… This is exactly what the European Commission is trying to address now. The Commission is preparing a Communication (a guidance document) to explain how the CRA should be applied in real situations and to support a consistent approach across the EU. It’s not a new Regulation and it’s not “binding law” in itself but it matters because it clarifies how key provisions are expected to be understood and implemented in practice. https://lnkd.in/etm43Utx What I like in this draft is that it turns the CRA into practical “rules of the road”, especially on: • Software scope & “placing on the market” (including iterative releases) • What counts as the “product” when hardware depends on apps/drivers/software delivered separately • Open-source (FOSS): when it’s out of scope vs when it becomes a commercial activity, and the steward concept • Updates vs “substantial modifications”: focus on risk/attack surface/intended purpose, not release size • Support period: 5 years is a minimum, and how this works with versioned software/upgrade paths • Cloud / remote processing: what’s part of the product vs general IT infrastructure • Risk assessment & due diligence: manufacturers keep responsibility, including for third-party components The draft is open for feedback for a limited period, and comments are expected in a structured template (so they can consolidate input). If you build products that will fall under CRA, this is a very good moment to stress-test your assumptions and flag the parts that are unclear, unrealistic, or could lead to unintended consequences. I’m sharing the draft guidance here because, from what I see, the companies that will move fastest are the ones that turn these interpretations into concrete internal rules: scope mapping, update governance, support period policy, OSS governance, and evidence-ready documentation.

32

Thanks to Ray Panta sharing below, National Institute of Standards and Technology (NIST) Special Publication is always a good reference for Cybersecurity practitioner in CyberSecurity related area. NIST SP as a whole is free, public accessible and by created by expert for everyone. What more else one can ask for such a good deal ? 😅 💻 Cyber risk means the chance of something going wrong in digital systems 🌐 – like hackers stealing data 🕵️‍♂️, systems going offline 🚫, or software getting hacked 🐞 🔐 It includes risks to privacy 🧾, finances 💸, business operations 🏢, and even national security 🛡️ 📘 NIST SP 800-30 is a guide 📖 from the US National Institute of Standards and Technology (NIST) 🇺🇸 that helps organisations figure out and manage their cyber risks ⚠️ 🧮 It teaches how to do risk assessments 🧠 – like identifying threats 👀, figuring out how likely they are 🎯, and what damage they could cause 💥 🧩 It's a key part of the NIST Cybersecurity Framework, used worldwide 🌍 to build safer digital systems 🏛️ NIST Special Publications are official guides 📚 that offer best practices, standards, and strategies for improving cybersecurity 👋 Robin Yong #MemeLord #LobinKor 🏆 #Favikon #CyberSecurity & #LinkedIn #Malaysia 💻 #5G, #ArtificialIntelligence, #IT, #CyberSecurity, #ForeignAffairs & #Geopolitics 🤝 https://v.gd/Robin ✨ #AI-augmented content, do fact check if in doubt ℹ️ #MemeLord not liable for the info shared.

19

1 Comment

In my new article published by ICIT, Executing the RMF as an Engineering Discipline, not a Paperwork Exercise, I discuss how the Risk Management Framework must function as part of engineering, not as a compliance process. RMF was created to align design, implementation, and operations so that control performance is demonstrated through verified system behavior rather than documentation. The article explains how integrating RMF into development pipelines, architecture decisions, and operational telemetry allows authorization decisions to reflect real conditions in production. When security is designed, tested, and monitored as part of engineering, the framework delivers what it was meant to provide. Systems maintain authorization by demonstrating continued security in operation. Read the full article on ICIT: https://lnkd.in/eup93tvi #cybersecurity #technology

19

The state of Rhode Island publicly released the results of a third-party analysis of the 2024 RIBridges cyberattack and data breach at a press conference with Rhode Island Governor Dan McKee and Chief Digital Officer Brian Tardiff. Cybersecurity company CrowdStrike conducted the analysis, which revealed the five-month timeline of the breach and a more accurate number of impacted individuals -- approximately 644,401 people. RIBridges is a system run by Deloitte that the state of Rhode Island uses to administer important social services benefits like health insurance, food stamps and the Child Care Assistance Program. As previously reported, Deloitte informed the state of a potential security threat to RIBridges on Dec. 5, 2024, stating that there was a high probability that a cyberthreat actor had obtained files containing sensitive information. The Brain Cipher cyberthreat group later took responsibility for the hack. The state took RIBridges temporarily offline and later sent notification letters to nearly 650,000 individuals. The newly released third-party analysis provided clarity on how the cyberthreat actor gained access to the RIBridges environment and how it performed data access, staging and exfiltration activities on 28 RIBridges systems. Reviewing post-incident analyses of healthcare data breaches can help defenders bolster security efforts. https://lnkd.in/gBJR5kBh

7

Excellent new contribution to Claroty Nexus from Providence CISO Mike Ratliff on the #healthcare system's teardown of traditional #GRC. Providence's approach: GRAC — Governance, Risk, Attack Surface Management, and Compliance — is a risk-centric, threat-aligned function built for outcomes, not reporting, Ratliff writes. https://hubs.li/Q03yc3pB0

2

Last April, CISA issued an 11-month extension for its CVE program with MITRE, rescuing the program from an almost certain death. Since then, CISA and MITRE have negotiated a new deal that puts the CVE program on firmer footing. In a statement, Nick Andersen, acting director of CISA, told CSO, “Under CISA’s leadership and sponsorship, the CVE program is fully funded and has continually evolved and modernized to support the global vulnerability ecosystem.” My exclusive for CSO. (link in the comments)

11

Navigating NIST 800-171 Compliance: A Guide for SMBs As cyber risks increase, it's crucial for Small and Medium-sized Businesses (SMBs) in the Defense Industrial Base (DIB) to protect sensitive information. Safeguarding Controlled Unclassified Information (CUI) is essential for their survival. Understanding NIST 800-171 and CMMC Compliance: NIST Special Publication 800-171 provides the framework for protecting this information, while the Cybersecurity Maturity Model Certification (CMMC) 2.0 builds upon it. For SMBs in the DIB, compliance isn't just a regulatory requirement—it's a strategic necessity for accessing Department of Defense (DoD) contracts and ensuring long-term business viability. Adhering to NIST SP 800-171 is a contractual obligation for organizations that handle CUI. https://lnkd.in/eshRftvJ

12

2 Comments

Remember my post on vibe-coding is a trap! Fyi: watch-out “value sharing” / outcome-based deals: OpenAI has signaled that for high-impact, IP-creating use cases (e.g., drug discovery, materials, finance/trading), they may push for bespoke contracts that include profit-share or upside participation, not just usage fees.

3

1 Comment

“PCI SSC has seen comments…” 👀 -Assessor Newsletter, June 2025 A few weeks ago, I raised a flag about FAQ 1597 and the related infographic, where the language suggested that acceptance of lower-risk vulnerabilities wasn’t on the table. That post gained great traction and sparked important conversations in the community. Well, the PCI Security Standards Council has now responded. In their June 2025 Assessor Newsletter, they stated: ✅ Clarification (main bullet points summarized): - “Addressed” ≠ “Resolved.” - Examples of "addressed" where not an exhaustive list. - Low-risk vulnerabilities can be accepted—if justified by a Targeted Risk Analysis (TRA). - Addressing a vulnerability may mean fixing it, compensating for it, disabling it, or accepting the risk. - The TRA must be reviewed annually to ensure it still reflects the environment and risk tolerance. This clarification is welcome—but also tacit acknowledgment that feedback from assessors and the broader community (yes, some of those comments they saw were from you all) helped make it happen. 📌 Next step for the Council: Update FAQ 1597 and the DSS itself at some point to reflect this broader interpretation. The ambiguity in the official text still risks confusion and audit inconsistencies. As of this posting date, the only place this clarification exists is within the assessor newsletter. 🤨 One nitpick I will call out though— the Council called out that their original definition of “addressed” wasn’t all inclusive. However, words matter. For a reminder, this was the definition: Addressed - the entity determines whether to resolve the vulnerability or to mitigate the risk by addressing the vulnerability in another way (e.g., with a compensating control or by disabling a vulnerable service) So to be clear, their definition says resolve OR mitigate. How were we to infer that acceptance is acceptable!?! 🤷‍♂️ If you’re a QSA or manage PCI in your organization, this is a significant development. It gives you back the flexibility to treat low-risk issues rationally, as long as your TRA process is strong. Thank you to Viviana W. for letting me know about the publication within the newsletter! #PCIDSS #CyberSecurity #QSA #VulnerabilityManagement #GRC #PCICompliance #InfoSec #AssessorLife

214

19 Comments

Quote of the Week: "AI amplifies the dangers of data consolidation and shoddy security practices" (Bruce Schneier, Written Expert Testimony to the House Committee on Oversight and Government Reform, June 4, 2025).  https://lnkd.in/e2mr4UGq Schneier rightly points out that your AI initiatives are only as secure as your worst data practice. When AI systems access consolidated data lakes, a single breach doesn't just expose records—it weaponizes them at machine speed. AI turns your sloppy data governance from an operational headache into an existential threat.

4

NYDFS Acting Superintendent Kaitlin Asrow just named the priorities every security leader should track: AI-accelerated threats, cryptocurrency, cybersecurity, and third-party risk. The updated 23 NYCRR Part 500 rules are fully in effect. But regulation alone won’t close the gap between governance documentation and runtime reality. WHY THIS MATTERS NOW The threat evidence has moved past theoretical. Anthropic documented GTG-1002, a Chinese state-sponsored actor whose agentic AI autonomously executed 80-90% of an espionage campaign while humans only intervened at strategic decision points. Google GTIG tracked state actors from China, Iran, North Korea, and Russia, integrating AI across the full attack lifecycle to identify malware families like PROMPTFLUX that call LLMs during execution to dynamically generate and obfuscate code. The criminal AI tooling marketplace has matured. Threat actors operate across the full autonomy spectrum. Defenders must govern accordingly. HOW TO CLOSE THE GAP Every AI agent needs a defined autonomy tier: fully autonomous, human-on-the-loop with intervention triggers, or human-in-the-loop with explicit approval gates. Business risk determines the tier. Agent Cards should serve as governance artifacts defining scope, permissions, data boundaries, and behavioral constraints before deployment. Assign human owners with explicit accountability. Enforce least privilege rigorously. If an agent doesn’t need access, it doesn’t get access. CTEM provides the feedback loop connecting governance to runtime. When threat actors exploit vulnerabilities at machine speed, annual assessments are insufficient. CTEM continuously validates controls against current attack patterns, not last quarter’s assumptions. Zero Trust must extend to AI itself. Never implicitly trust agent output. Verify scope continuously. Monitor behavioral drift. Enforce segmentation between AI workloads and sensitive data. WHAT NEEDS TO CHANGE Third-party risk must evolve beyond questionnaires. Asrow emphasized this. JPMorgan CISO Pat Opet’s open letter reinforced it. The conversation must extend to fourth-party dependencies and software supply chain integrity: model provenance, training data lineage, API dependencies, and runtime behavior monitoring all require continuous assurance. The frameworks exist: NIST AI RMF, CSF 2.0, ISO 42001, MITRE ATLAS, OWASP AI Security, CSA AI guardrails. The gap isn’t availability. It’s operationalization and the discipline to treat AI governance as continuous rather than a compliance milestone. Build governance that scales as autonomy increases. Define the tripwires. Prove that the humans showed up when required. The regulatory pace is accelerating. The threat actor pace is faster. #Cybersecurity #AIGovernance #CTEM #ZeroTrust #ThirdPartyRisk​​​​​​​​​​​​​​​​ https://lnkd.in/eU83nN8i

6

1 Comment