LinuxGuard Blog

What Does CMMC Require of Linux Audit Logs? CMMC — the Cybersecurity Maturity Model Certification — is the US Department of Defense's programme for verifying that contractors protect the controlled unclassified information (CUI) they handle. Its Level 2 aligns with the security requirements of NIST SP 800-171 and is verified by a third-party assessor, a C3PAO. Nowhere does it name an operating system, but the systems that store and process CUI are overwhelmingly Linux, so its audit-logging requ

What Do PCI DSS Requirements 7 and 10 Require on Linux? PCI DSS — currently version 4.0.1 — governs any system in the cardholder data environment (CDE): the systems that store, process, or transmit payment card data, and the systems connected to them. Like other frameworks it does not name an operating system, but the CDE is overwhelmingly built on Linux, so its access and logging requirements land on your Linux hosts. Two requirements matter most for Linux identity and audit: Requirement 7, wh

Does the NCSC CAF Apply to Linux? The NCSC Cyber Assessment Framework — the CAF — is the UK's outcome-based framework for judging whether an organisation is managing cyber risk to its essential functions well enough. It is used by operators of essential services and other bodies assessed under the UK's network and information systems regime, and increasingly as a general resilience benchmark. Like most compliance frameworks it never names an operating system, and a search for how it applies to

What Does SOX Require of Linux Systems? The Sarbanes-Oxley Act never mentions Linux, yet SOX shapes how every Linux server under a financial-reporting system must be controlled. Section 404 requires a company's management, and its external auditor, to assess the effectiveness of internal control over financial reporting (ICFR). When the general ledger, the ERP, the revenue system, or the database behind them runs on Linux, the controls on those hosts become part of what is assessed. The reason

What Is a Non-Human Identity on Linux? A non-human identity on Linux is any account, key, or credential that authenticates to a system without a person behind it — a service account that runs a daemon, an SSH key that lets one host reach another, an API token a script uses to call a controller. It is the machine equivalent of a user, and on a modern Linux estate there are far more of them than there are people. The scale is easy to underestimate. Palo Alto Networks' 2026 Identity Security Land

When OpenAI shared details of the agent swarm behind the Hugging Face breach, the thing that stood out to us wasn't the sophistication of the attack. It was how familiar every step actually was. An over-permissioned service account, a kernel privilege escalation, credentials shared across a compromised system — none of that is new. What's new is that the actor chaining those steps together was a coordinated group of autonomous agents, moving without a human deciding what to do next, apart from

The Wrong Question Is Costing You  When a security team goes looking for a "Linux PAM solution," they are usually asking the wrong question.  The right question is not which PAM tool should we deploy? The right question is: does our team actually know what every user can do on every Linux server right now?  If the answer is no — and across most enterprise environments it is — then no amount of session recording, credential vaulting, or just-in-time access provisioning will close that gap. You

What Is SSH Key Sprawl? SSH key sprawl is the uncontrolled accumulation of SSH keys across a Linux estate: authorised keys added ad hoc, never rotated, and rarely inventoried. Over time, orphaned keys — belonging to departed staff, decommissioned services, or forgotten automation — pile up as unmanaged credentials that quietly grant standing access no one is tracking. SSH keys are now one of the largest ungoverned identity surfaces in most Linux estates — and by far the least visible. In 2026,

The auditor doesn't care that you're busy. The regulation doesn't care that Linux is hard. And the attacker who finds that sudo rule you forgot about in 2019 definitely doesn't care.

The audit email lands on a Tuesday morning. Your auditor wants evidence of privileged access controls across your Linux estate — who had root, when, what changed, and how you know. You open your SIEM dashboard. You check your IGA platform. Neither has what you need. This is the Linux compliance gap, and it is costing security teams across finance, utilities, and manufacturing weeks of frantic manual work every audit cycle.  This guide exists because three major EU regulatory regimes now converg

The last months have been about building something we've needed for a long time: a security platform that actually follows your infrastructure, instead of forcing your infrastructure to conform to the platform. I want to walk you through what we shipped and why it matters—not in the abstract, but in the concrete terms of what you can now do that you couldn't do before. Container-Native Monitoring Every container now tells its story. When an event fires—a privilege escalation, an authenticati

There is an open question for legal teams. They probably just don't know it yet. The wrong room has been running this conversation For the last decade, the debate about identity security, Zero Trust, and access governance has lived entirely inside IT. CISOs present to boards. CSOs brief the CFO. Security vendors sell to procurement committees. The language is technical — MFA, ZTNA, PAM, IGA, NHI — and the outcomes are measured in frameworks certified, audits passed, and controls deployed. Me

What Is CVE-2026-31431 (Copy Fail)? CVE-2026-31431 — publicly known as Copy Fail — is a local privilege escalation flaw in the Linux kernel's algif_aead crypto module, affecting kernels built from 2017 up to the patch. It lets a local attacker write controlled bytes into the page cache of setuid binaries. NVD assigns it a CVSS base score of 7.8 (High). In 1985 I was at school. That year, a logic flaw was introduced into what would later become the Linux kernel's crypto subsystem. In April 2026

Early in my career, I broke a client’s production system in the worst possible way. It was a last‑minute fix before a big presentation. I had access to the Linux server, I was under pressure, and I made a single recursive permissions change from root. It felt harmless in the moment — a quick way to “just make it work” before the meeting. Twenty minutes later, sitting in the middle of the client presentation, I watched their website die in slow motion as cache TTLs expired and processes started

When I started out in IT, Identity & Access Management wasn't really a discipline — it was just common sense. You controlled who could get in, you made sure they could only do what they needed to do, and you documented it well enough that you could explain it to someone if things went wrong. It was practical, technical, and grounded in how systems actually worked. Over time, a whole industry grew up around that common sense. IAM became its own domain, with frameworks, tools, vendors, certificat

Nine critical AppArmor flaws have exposed 12M+ Linux systems since 2017. Learn why default security assumptions fail and how to verify your Linux privilege landscape.

Here is a question that should be simple: "Who can do what on our Linux servers right now?"  Not who should have access. Not who had access last quarter. Right now. 

If I see one more security leader proudly present a 200-slide deck from a very reputable firm with an impressive logo that cost more than their entire security team's annual salaries, I might actually lose it.  You know the presentation I'm talking about. The one with the maturity models. The capability heat maps. The three-year roadmap with swimlanes that look like they were designed by someone who's never actually logged into a Linux server. The one that makes the board nod approvingly while

January 2026: 29 breached organizations, 5.5M exposed records—all preventable. Learn how Linux identity visibility stops credential attacks, insider threats & zero-days. 

In enterprise security, the conversation around privileged access often ends too early. We talk about vaulting passwords, rotating secrets, enforcing MFA — and then declare victory.

For years, enterprises have poured millions into identity platforms, SIEM systems, and compliance tools — all with the same goal: visibility. And yet, when it comes to Linux, most organizations still can’t answer one of the simplest and most critical questions in security

Every security breach starts with a single decision that seemed harmless at the time.

In many Linux environments, sudo access often ends up treated like a permanent hall pass: once someone gets it, they usually keep it. There’s rarely an automatic expiry, consistent auditing, or a central inventory showing who has elevated privileges and what they can do across the estate.

Every few years, the identity industry gets a new acronym. Some fade quickly. Others reshape the way we think. The newest entry is IVIP — Identity Visibility & Intelligence Platforms. Since Gartner added IVIP to their Hype Cycle, the debate has been lively. Analysts like Martin Kuppinger and Matthias Reinwarth have rightly asked: * Is IVIP truly new, or just a repackaging of existing ideas? * Is it a platform in its own right, or simply a capability? * Does it overlap with ITDR (Identity