Issue #04 • Week of Jan 19, 2026

Sponsored message
Security Tip of the Week
🔐 Monitor Your Security Tools Like Production Systems
Treat SIEMs, IAM platforms, firewalls, and other security infrastructure as high-value attack targets by enforcing independent monitoring, strict segmentation, and external visibility into their behavior. If a security control can see credentials, logs, or enforcement logic, it deserves the same detection, auditing, and threat modeling as any Tier 0 workload.

The trust boundaries we’ve spent years building, and the ones we’ve spent years assuming, are both under pressure this week, but for different reasons. The boundaries we built are being exploited faster than we can patch them. The ones we assumed were there? They were never validated in the first place.

 

We’ve treated security tooling, identity systems, and vendor relationships as if trust could be inherited through placement, policy, or contract language. Put the SIEM on the internal network, therefore it’s protected. Deploy zero trust controls, therefore privilege is contained. Sign a vendor agreement, therefore their subcontractors are our problem only if something goes wrong. These assumptions worked when perimeters held, when change happened slowly, and when “trusted” actually meant something consistent. They don’t work anymore, and this week’s stories make that gap between assumption and reality harder to ignore.

 

What’s particularly uncomfortable is that fixing this isn’t a sprint project or a budget ask; it’s operational redesign under live fire. Discovery work that should’ve been done before zero trust rollouts. Machine identity governance that should scale with automation, not after it. Vendor risk programs that map fourth-party dependencies before regulators ask why they weren’t already documented. These aren’t new problems, but the window to address them retroactively is closing faster than most roadmaps account for. The question isn’t whether your architecture has gaps—it’s whether you know where they are before someone else does.

Top Story

Fortinet FortiSIEM Command Injection Under Active Exploitation

https://www.bleepingcomputer.com/news/security/hackers-now-exploiting-critical-fortinet-fortisiem-vulnerability-in-attacks/https://www.securityweek.com/google-patches-gemini-enterprise-vulnerability-exposing-corporate-data/https://www.securityweek.com/us-organizations-warned-of-chinese-malware-used-for-long-term-persistence/`

TLDR

FortiSIEM versions 6.7 through 7.5 contain an unauthenticated remote code execution vulnerability (CVE-2025-64155) that grants root access through exposed command handlers on the phMonitor service. Public exploit code has been available since Tuesday’s patch release, and threat actors are now actively exploiting it in the wild according to honeypot telemetry. This is Fortinet’s third actively exploited zero-day in four months.

Why it matters to enterprises

FortiSIEM sits at a trust boundary most enterprises haven’t explicitly validated: the SIEM itself is assumed to be a security control, not an attack vector. An unauthenticated RCE to root on your log aggregation platform means an attacker gains visibility into detection logic, incident response playbooks, and the complete security posture, often before defenders see the initial compromise. Worse, FortiSIEM typically holds credentials for every system it monitors, making it a privileged pathway to lateral movement across the entire environment.

 

The architectural problem is that SIEMs are treated as passive observers when they’re actually privileged data brokers with deep access to identity systems, network telemetry, and endpoint state. The fact that dozens of unauthenticated command handlers were exposed on a listening service suggests this product was designed with an implicit trust model—internal network, security tool, therefore safe, that doesn’t hold in modern enterprise networks where segmentation is inconsistent and attackers routinely reach “trusted” zones.

 

This is also the third Fortinet product exploited as a zero-day since November. That pattern suggests systematic issues with secure development lifecycle controls, internal testing rigor, or both. Enterprises running multiple Fortinet products should reassess whether vendor concentration is creating correlated risk.

What to do this week

Inventory and isolate FortiSIEM exposure immediately. Confirm whether phMonitor (port 7900) is reachable from untrusted networks or poorly segmented zones. If patching will take more than 48 hours, implement the workaround by restricting port 7900 access to known management IPs only. Do not assume “internal” placement is sufficient protection.

Hunt for compromise using the published IOCs. Check /opt/phoenix/log/phoenix.logs for PHL_ERROR entries containing payload URLs. This is evidence of attempted or successful exploitation. Assume any evidence of exploitation means full credential compromise for every system FortiSIEM monitors—rotate service accounts, API keys, and SIEM integration credentials across the board.

Validate what FortiSIEM can actually see and do. Document every system it has credentials for, every API it calls, and every trust relationship it holds. Most enterprises don’t have this mapped. If your SIEM was compromised, what could an attacker reach? The answer should inform segmentation and privilege boundaries going forward.

Pressure-test your SIEM-as-a-target threat model. Review whether your detection strategy would identify a compromised SIEM being used against you. Can you detect log suppression, rule modification, or credential misuse originating from the SIEM itself? If not, you’re trusting a single point of failure with no oversight.

Reassess vendor concentration risk with Fortinet specifically. If you’re running FortiSIEM, FortiWeb, FortiOS, or multiple Fortinet products, evaluate whether you have sufficient visibility and control independence. Three exploited zero-days in four months is not a statistical anomaly—it’s a pattern. Consider where you need architectural redundancy or alternative visibility that doesn’t depend on a single vendor’s security posture.

Establish a 72-hour patch SLA for security infrastructure. SIEM, firewalls, VPN gateways, and identity platforms should not follow the same patch cadence as endpoints. When public exploits drop on Tuesday and active exploitation is confirmed by Thursday, your window is measured in hours, not sprints. If your change control process can’t accommodate that, the process is now the vulnerability

Big Stories

NSA Releases First Zero Trust Implementation Guidelines Focused on Discovery

Source: https://www.helpnetsecurity.com/2026/01/15/nsa-zero-trust-implementation-guidelines/

What happened

The NSA published the first two documents in its Zero Trust Implementation Guidelines series: a Primer and a Discovery Phase guide. The Primer explains how the guidance is structured and how organizations can apply it incrementally based on current maturity levels. The Discovery Phase document focuses on establishing visibility into data, applications, assets, services, and access patterns across enterprise environments. This phase directs teams to map where sensitive data resides, document system dependencies, and observe how authentication and authorization actually work in production. The guidance is designed to be modular and aligned with the Department of Defense CIO Zero Trust Framework, with Phase 1 and Phase 2 documents expected to follow.

Why it matters

Most enterprises treat zero trust as an architecture problem when it’s actually an inventory and visibility problem they’ve been deferring for years. The NSA’s focus on discovery as the foundational phase validates what security teams already know but executives often resist funding: you cannot enforce least privilege, validate trust boundaries, or implement micro-segmentation if you don’t know what assets exist, where data actually flows, or which services hold standing access to what. The problem is that discovery work exposes how little control enterprises actually have, undocumented shadow IT, service accounts with unconstrained access, data sprawl across SaaS platforms, and authentication patterns that contradict stated policy.

 

What makes this guidance operationally relevant is that it frames discovery as a continuous discipline, not a one-time audit. Zero trust architectures fail when they’re built on outdated asset inventories or access models that no longer reflect reality. Attackers don’t need to break trust boundaries if those boundaries were never validated in the first place. Enterprises that skip or rush discovery end up implementing zero trust controls around incomplete or inaccurate assumptions, which means the controls protect the wrong things while leaving actual privilege pathways unmonitored.

 

The modular approach also signals something important: there is no “done” state for zero trust, and organizations at different maturity levels shouldn’t be paralyzed waiting for perfect conditions. But the risk is that modularity becomes an excuse to cherry-pick easy wins while avoiding the hard governance work, like establishing authoritative data classification, documenting service-to-service trust, or enforcing identity boundaries in legacy environments where “zero trust” means “slightly more logging than before.”

.

CISOs Report Blind Spots in Fourth-Party Risk and AI Vendor Oversight

Source: https://www.helpnetsecurity.com/2026/01/15/panorays-cisos-ai-vendor-risk/

What happened

A Panorays survey of U.S. CISOs shows that third-party cyber incidents continued to rise over the past year, with many breaches traced to fourth-party relationships and deeper supply chain connections. Only a small portion of organizations report visibility beyond direct vendors, while most operate with partial insight limited to first-tier relationships. The survey found that the majority of organizations are not prepared to meet upcoming regulatory requirements for third-party oversight without significant changes to their programs. Additionally, most enterprises still onboard AI vendors through general third-party processes rather than dedicated policies, despite CISOs ranking AI vendors as carrying a distinct risk profile due to data handling practices and model opacity.

Why it matters

Issue #04 • Week of Jan 19, 2026 Sponsored message Security Tip of the Week 🔐 Treat Hypervisors as Tier 0 Force all vCenter and ESXi administration through hardened privileged access workstations with phishing resistant MFA, and keep hypervisor management interfaces on isolated networks that are never reachable from user subnets or the internet. The trust boundaries we’ve spent years building—and the ones we’ve spent years assuming—are both under pressure this week, but for different reasons. The boundaries we built are being exploited faster than we can patch them. The ones we assumed were there? They were never validated in the first place. We’ve treated security tooling, identity systems, and vendor relationships as if trust could be inherited through placement, policy, or contract language. Put the SIEM on the internal network, therefore it’s protected. Deploy zero trust controls, therefore privilege is contained. Sign a vendor agreement, therefore their subcontractors are our problem only if something goes wrong. These assumptions worked when perimeters held, when change happened slowly, and when “trusted” actually meant something consistent. They don’t work anymore, and this week’s stories make that gap between assumption and reality harder to ignore. What’s particularly uncomfortable is that fixing this isn’t a sprint project or a budget ask—it’s operational redesign under live fire. Discovery work that should’ve been done before zero trust rollouts. Machine identity governance that should scale with automation, not after it. Vendor risk programs that map fourth-party dependencies before regulators ask why they weren’t already documented. These aren’t new problems, but the window to address them retroactively is closing faster than most roadmaps account for. The question isn’t whether your architecture has gaps—it’s whether you know where they are before someone else does. Top Story Fortinet FortiSIEM Command Injection Under Active Exploitation TLDR FortiSIEM versions 6.7 through 7.5 contain an unauthenticated remote code execution vulnerability (CVE-2025-64155) that grants root access through exposed command handlers on the phMonitor service. Public exploit code has been available since Tuesday’s patch release, and threat actors are now actively exploiting it in the wild according to honeypot telemetry. This is Fortinet’s third actively exploited zero-day in four months. What it matters to enterprises FortiSIEM sits at a trust boundary most enterprises haven’t explicitly validated: the SIEM itself is assumed to be a security control, not an attack vector. An unauthenticated RCE to root on your log aggregation platform means an attacker gains visibility into detection logic, incident response playbooks, and the complete security posture—often before defenders see the initial compromise. Worse, FortiSIEM typically holds credentials for every system it monitors, making it a privileged pathway to lateral movement across the entire environment. The architectural problem is that SIEMs are treated as passive observers when they’re actually privileged data brokers with deep access to identity systems, network telemetry, and endpoint state. The fact that dozens of unauthenticated command handlers were exposed on a listening service suggests this product was designed with an implicit trust model—internal network, security tool, therefore safe—that doesn’t hold in modern enterprise networks where segmentation is inconsistent and attackers routinely reach “trusted” zones. This is also the third Fortinet product exploited as a zero-day since November. That pattern suggests systematic issues with secure development lifecycle controls, internal testing rigor, or both. Enterprises running multiple Fortinet products should reassess whether vendor concentration is creating correlated risk. What to do this week Inventory and isolate FortiSIEM exposure immediately. Confirm whether phMonitor (port 7900) is reachable from untrusted networks or poorly segmented zones. If patching will take more than 48 hours, implement the workaround by restricting port 7900 access to known management IPs only. Do not assume “internal” placement is sufficient protection. Hunt for compromise using the published IOCs. Check /opt/phoenix/log/phoenix.logs for PHL_ERROR entries containing payload URLs. This is evidence of attempted or successful exploitation. Assume any evidence of exploitation means full credential compromise for every system FortiSIEM monitors—rotate service accounts, API keys, and SIEM integration credentials across the board. Validate what FortiSIEM can actually see and do. Document every system it has credentials for, every API it calls, and every trust relationship it holds. Most enterprises don’t have this mapped. If your SIEM was compromised, what could an attacker reach? The answer should inform segmentation and privilege boundaries going forward. Pressure-test your SIEM-as-a-target threat model. Review whether your detection strategy would identify a compromised SIEM being used against you. Can you detect log suppression, rule modification, or credential misuse originating from the SIEM itself? If not, you’re trusting a single point of failure with no oversight. Reassess vendor concentration risk with Fortinet specifically. If you’re running FortiSIEM, FortiWeb, FortiOS, or multiple Fortinet products, evaluate whether you have sufficient visibility and control independence. Three exploited zero-days in four months is not a statistical anomaly—it’s a pattern. Consider where you need architectural redundancy or alternative visibility that doesn’t depend on a single vendor’s security posture. Establish a 72-hour patch SLA for security infrastructure. SIEM, firewalls, VPN gateways, and identity platforms should not follow the same patch cadence as endpoints. When public exploits drop on Tuesday and active exploitation is confirmed by Thursday, your window is measured in hours, not sprints. If your change control process can’t accommodate that, the process is now the vulnerability. Big Stories NSA Releases First Zero Trust Implementation Guidelines Focused on Discovery Source: https://www.helpnetsecurity.com/2026/01/15/nsa-zero-trust-implementation-guidelines/ What happened The NSA published the first two documents in its Zero Trust Implementation Guidelines series: a Primer and a Discovery Phase guide. The Primer explains how the guidance is structured and how organizations can apply it incrementally based on current maturity levels. The Discovery Phase document focuses on establishing visibility into data, applications, assets, services, and access patterns across enterprise environments. This phase directs teams to map where sensitive data resides, document system dependencies, and observe how authentication and authorization actually work in production. The guidance is designed to be modular and aligned with the Department of Defense CIO Zero Trust Framework, with Phase 1 and Phase 2 documents expected to follow. Why it matters Most enterprises treat zero trust as an architecture problem when it’s actually an inventory and visibility problem they’ve been deferring for years. The NSA’s focus on discovery as the foundational phase validates what security teams already know but executives often resist funding: you cannot enforce least privilege, validate trust boundaries, or implement micro-segmentation if you don’t know what assets exist, where data actually flows, or which services hold standing access to what. The problem is that discovery work exposes how little control enterprises actually have—undocumented shadow IT, service accounts with unconstrained access, data sprawl across SaaS platforms, and authentication patterns that contradict stated policy. What makes this guidance operationally relevant is that it frames discovery as a continuous discipline, not a one-time audit. Zero trust architectures fail when they’re built on outdated asset inventories or access models that no longer reflect reality. Attackers don’t need to break trust boundaries if those boundaries were never validated in the first place. Enterprises that skip or rush discovery end up implementing zero trust controls around incomplete or inaccurate assumptions, which means the controls protect the wrong things while leaving actual privilege pathways unmonitored. The modular approach also signals something important: there is no “done” state for zero trust, and organizations at different maturity levels shouldn’t be paralyzed waiting for perfect conditions. But the risk is that modularity becomes an excuse to cherry-pick easy wins while avoiding the hard governance work—like establishing authoritative data classification, documenting service-to-service trust, or enforcing identity boundaries in legacy environments where “zero trust” means “slightly more logging than before.” CISOs Report Blind Spots in Fourth-Party Risk and AI Vendor Oversight Source: https://www.helpnetsecurity.com/2026/01/15/panorays-cisos-ai-vendor-risk/ What happened A Panorays survey of U.S. CISOs shows that third-party cyber incidents continued to rise over the past year, with many breaches traced to fourth-party relationships and deeper supply chain connections. Only a small portion of organizations report visibility beyond direct vendors, while most operate with partial insight limited to first-tier relationships. The survey found that the majority of organizations are not prepared to meet upcoming regulatory requirements for third-party oversight without significant changes to their programs. Additionally, most enterprises still onboard AI vendors through general third-party processes rather than dedicated policies, despite CISOs ranking AI vendors as carrying a distinct risk profile due to data handling practices and model opacity. Why it matters The gap between where breaches originate and where oversight actually exists is widening. Enterprises have built third-party risk programs around direct vendor relationships while attacks increasingly exploit fourth-party and nth-party connections, subcontractors, affiliates, and service providers that your vendors depend on but you may not even know exist. This isn’t a maturity problem; it’s a structural mismatch. Traditional vendor risk management assumes you can inventory, assess, and control the entities you contract with directly, but that model breaks when your actual exposure extends through layers of dependencies you have no contractual relationship with and no visibility into.   AI vendors compound this problem because they sit at the intersection of data access, decision authority, and operational opacity. Most AI services require access to business context, user data, and workflow integration to function, which means they hold privileged positions in your architecture by design. But enterprises are onboarding these vendors using the same static questionnaires and annual review cycles built for SaaS tools or cloud providers, despite the fact that AI vendors introduce risks traditional assessments were never designed to measure—model behavior drift, training data provenance, prompt injection pathways, and context leakage across tenant boundaries.   The regulatory pressure is also shifting faster than programs can adapt. Frameworks increasingly expect documented oversight across extended supply chains, not just direct vendors, and they expect evidence of continuous monitoring, not point-in-time assessments. The problem is that most third-party risk programs were built to satisfy compliance checkboxes, not to operate as real-time risk intelligence functions. When a breach surfaces three vendor layers away, security teams are left reconstructing relationships, data flows, and access patterns retroactively, often while regulators are asking why those relationships weren’t already mapped.   What makes this harder to ignore is that most organizations don’t have tested response plans for third-party breaches. This means when a vendor incident occurs, teams are improvising containment and notification under pressure, often without clear authority over the affected systems or data. Larger enterprises report better preparedness, but even there, response planning is uneven. The operational reality is that enterprises have accepted vendor dependencies as unavoidable while systematically underinvesting in the visibility and governance required to manage the risk those dependencies create.

Quick Hits

Nation-State Crypto Crime Reached $154 Billion in 2025

State actors are no longer just sponsors of cyber operations—they’re now operating their own large-scale cryptocurrency infrastructure for sanctions evasion, money laundering, and cross-border financial flows. North Korea alone stole $2 billion in crypto last year, while Russia and Iran moved billions through sanctioned wallets, creating a parallel financial system enterprises can no longer treat as peripheral risk.

https://www.helpnetsecurity.com/2026/01/12/nation-state-crypto-crime-activity/

AI Systems Fail Predictably Along Cultural and Geographic Lines

AI models trained on dominant languages and industrialized environments produce measurably worse results in under-resourced languages, non-Western contexts, and regions with different infrastructure assumptions. For enterprises deploying AI globally, this isn’t a fairness issue—it’s a systemic vulnerability that creates exploitable failure modes in security monitoring, detection, and decision-support systems operating across diverse user populations.

https://www.helpnetsecurity.com/2026/01/05/ai-security-governance-risks-research/

Hospitality Sector Targeted With Fake BSoD Pages Delivering DCRat

Attackers are using phishing emails impersonating Booking.com to redirect hotel staff to fake blue screen of death pages with “recovery instructions” that deploy DCRat malware. The campaign abuses MSBuild.exe and aggressively disables Windows Defender, demonstrating how social engineering layered with living-off-the-land techniques can bypass endpoint protections in sectors where staff routinely handle external booking communications.

https://thehackernews.com/2026/01/fake-booking-emails-redirect-hotel.html

What Now?

The stories this week share a common thread: the controls we’ve deployed assume a level of visibility and governance we don’t actually have. Zero trust architectures built on incomplete asset inventories. Vendor risk programs that stop at the first contractual boundary. Identity systems that count machine accounts but don’t govern them. SIEMs trusted to see everything while no one watches the SIEM itself. These aren’t edge cases. They’re structural gaps that get exposed when something fails loudly enough to demand attention.

 

What makes this uncomfortable is that the gap isn’t usually about missing tools or budget. It’s about deferring the operational work that makes controls effective, discovery, dependency mapping, privilege validation, continuous monitoring of the things we assume are secure. Enterprises treat these as foundational tasks but fund them like nice-to-haves, which means they get done partially, retroactively, or not at all. The result is architecture that looks mature on paper but operates on assumptions no one has pressure-tested since the last audit. When those assumptions break, the blast radius is wider than anyone expected because the trust boundaries were inherited, not validated.

 

The shift isn’t about doing more security, it’s about doing different security. Stop optimizing coverage metrics and start mapping actual privilege pathways. Stop treating discovery as a project phase and start treating it as continuous intelligence. Stop assuming trust can be delegated to placement, policy, or contract language and start requiring evidence that boundaries hold under real conditions. The organizations that make this shift won’t eliminate gaps, but they’ll know where the gaps are before someone else exploits them. That’s not perfect security—it’s just security that scales with reality instead of breaking against it.