CSOonline

Gorodenkoff | shutterstock.com Sicherheitsentscheider sind mit einer sich kontinuierlich verändernden Bedrohungslandschaft, einem zunehmend strengeren, regulatorischen Umfeld und immer komplexeren IT-Infrastrukturen konfrontiert. Auch deshalb wird die Qualität ihrer Sicherheits-Toolsets immer wichtiger. Das Problem ist nur, dass die Bandbreite der heute verfügbaren Cybersecurity-Lösungen überwältigend ist. Für zusätzliche Verwirrung sorgen dabei nicht nur diverse Buzzwords, sondern auch diverse Überschneidungsbereiche der unterschiedlichen Tool-Kategorien. Im Folgenden lesen Sie, welche Art von Security-Lösungen für Unternehmen obligatorisch sind – und warum. 13 essenzielle Security-Tools für Unternehmen 1. Extended Detection and Response (XDR) KI-gestützte XDR-Lösungen entwickeln sich zu einer tragenden Säule der „Next Generation“-Security. Allerdings ist diese Tool-Kategorie sowohl schwer abzugrenzen als auch zu definieren. Extended-Detection-and-Response-Lösungen arbeiten am Top-Funnel und identifizieren Bedrohungen in Netzwerken, Endpunkten oder der Cloud, indem sie die Sicherheits-Tools, die im Unternehmen zum Einsatz kommen automatisieren oder integrieren. Laut Forrester Research können Bedrohungen so besser identifiziert und analysiert werden. Zudem verbessert sich dank Echtzeit-Features auch die Fähigkeit, auf Threats zu reagieren. Werden die XDR-Funktionen ausgelagert, spricht man von Managed Detection and Response – MDR. XDR auf KI-Basis ist ein effektives Threat-Intelligence- und Vulnerability-Management-Tool und kann dazu beitragen, Attacken auf Unternehmensnetzwerke abzuwehren. In der Regel kommen XDR-Tools in Kombination mit Firewalls zum Einsatz. Das soll gewährleisten, Bedrohungen zu identifizieren und priorisieren, sobald sie im Netzwerk sind. Die Zielsetzung besteht allgemein darin, den Großteil der Threats in (nahezu) Echtzeit und ohne manuelle Verifizierung zu blockieren. 2. Multifaktor-Authentifizierung (MFA) Nicht nur für den Schutz von Endpunkten sind MFA-Lösungen längst unverzichtbar geworden. Auch viele Cyberversicherer setzen MFA inzwischen für den Zugang zu ihren Policen voraus. Das verlangt den Benutzern ab, sich zusätzlich zu authentifizieren, sobald sie auf ein Konto oder eine Applikation zugreifen möchten. Dazu kommen beispielsweise externe Security-Keys, mobile Authentifizierungs-Apps oder SMS-Codes zum Einsatz. Eine adaptive MFA-Lösung erfordert hingegen nur dann eine zusätzliche Authentifizierung, wenn Benutzerinteraktionen als risikobehaftet eingestuft werden. Im Vergleich zur einfachen Benutzerauthentifizierung mit Benutzername und Passwort ist die Multifaktor-Authentifizierung die sicherere und effizientere Methode. 3. Network Access Control (NAC) NAC befähigt Unternehmen dazu, Sicherheitsrichtlinien durchzusetzen, sobald Devices oder Benutzer versuchen, auf ihr Netzwerk zugreifen. Das sorgt für einen klaren Blick darauf, wer sich von wo aus anmeldet und gewährleistet, dass die verbundenen Devices über die nötigen Sicherheits-Updates und Kontrollmaßnahmen verfügen, bevor rollenbasierter Zugriff auf Unternehmensressourcen gewährt wird. Angesichts immer komplexerer IT-Infrastrukturen und neuen Regulierungen ist der Blick auf alle mit dem Unternehmensnetzwerk verbundenen Geräte sowie einheitliche Zugriffskontrollen unabdingbar. Das Gros der NAC-Anbieter hat seine Produkte dabei auf die wachsende Zahl von Mobile- und IoT-Devices ausgelegt. 4. Data Loss Prevention (DLP) DLP-Tools sorgen dafür, dass sensible Unternehmensdaten (unabsichtlich oder absichtlich) nicht nach außen dringen. Dazu überwachen diese Werkzeuge den Netzwerk-Traffic auf bestimmte Datenelemente oder Muster (beispielsweise Kreditkarteninformationen) und alarmieren Administratoren, wenn das Risiko eines Datenabflusses besteht. Diverse Produkte im Bereich Data Loss Prevention sind außerdem darauf konzipiert, auch vor Cloud-basierten Datenlecks zu schützen. Entsprechend ist eine DLP-Lösung ein essenzielles Werkzeug, um cyberkriminelle Aktivitäten im Netzwerk zu erkennen. Darüber hinaus ist diese Kategorie jedoch auch von entscheidender Bedeutung, um Insider-Bedrohungen zu identifizieren. Angesichts der Bußgelder, die bei einem Datenschutzverstoß drohen, ist eine effiziente Data Loss Prevention Software auch in monetärer Hinsicht eine lohnende Investition. 5. Firewall Eine Firewall filtert auf der Grundlage definierter Regeln (die von Administratoren festgelegt werden) den Netzwerkverkehr. Das erhöht den Schutz vor Malware, nicht autorisierten Anmeldeversuchen und anderen Bedrohungen. Über eine Firewall-Lösung erhalten Unternehmen die Möglichkeit, ihren Traffic anhand diverser verschiedener Kriterien zu filtern – beispielsweise IP-Ranges, URLs oder Ports. Moderne Firewall-Produkte gehen längst über die reine Perimeter-Schutzfunktion hinaus und bieten erweiterten, Client-seitigen Schutz. Dabei nutzen State-of-the-Art-Lösungen auch Machine Learning (ML) und künstliche Intelligenz (KI), um Muster oder Anomalien in Echtzeit zu erkennen und automatisiert darauf zu reagieren. Das kann dazu beitragen, potenzielle Schäden erheblich zu minimieren oder vollständig abzuwenden. 6. Intrusion Prevention Systems (IPS) Bei Intrusion-Prevention-Systemen handelt es sich um eine „Inline“-Technologie, die in der Regel „hinter“ der Firewall eingesetzt wird, um schadhafte Datenpakete im Traffic automatisch zu löschen. Dazu kommen weitere, proaktive Maßnahmen, um Bedrohungen weiter einzudämmen, etwa Netzwerk-Scans und Reporting-Funktionen zu potenziellen Bedrohungen. Ein IPS ergänzt und erweitert also Firewalls und andere Netzwerk-Verteidigungssysteme. Dabei kann diese Kategorie von Lösung die Reaktionszeit auf Sicherheitsvorfälle potenziell erheblich verkürzen und damit Schaden vom Unternehmen abwenden. 7. Identity and Access Management (IAM) Um den Benutzerzugriff auf Systeme und Daten zu kontrollieren, kommen Unternehmen an IAM nicht vorbei. Diese Lösungen stellen sicher, dass ausschließlich autorisierte Personen auf die Ressourcen zugreifen können, die sie benötigen. Das funktioniert im Regelfall über rollenbasierte Zugriffsrechte. Weil immer mehr Applikationen und Daten in die Cloud migriert werden, entwickelt sich die Benutzeridentität zum neuen Perimeter. Entsprechend wichtig ist es, eine IAM-Lösung einzusetzen. Diese wird inzwischen auch im Rahmen diverser Cyberversicherungspolicen vorausgesetzt. 8. Cloud Access Security Broker (CASB) CASBs ermöglichen es Unternehmen, Sicherheitsrichtlinien für Benutzer durchzusetzen, die auf Cloud-basierte Services zugreifen. Diese Lösungen können On-Premises oder in der Cloud eingesetzt werden und „sitzen“ zwischen Cloud-Dienstanbieter und Benutzer. Das ermöglicht eine ganze Reihe von Sicherheitsverfahren mit Blick auf Authentifizierung, Autorisierung und Malware-Abwehr. Hinzu kommen zahlreiche neue, KI-basierte Features, die Unternehmen dabei unterstützen, SaaS-Anwendungen und -Daten abzusichern und Compliance-Vorgaben zu erfüllen. Darüber hinaus sind CASB-Lösungen auch hilfreich, um Identitäten und Authentifizierungs-Prozesse über mehrere Cloud-Anwendungen hinweg zu managen. 9. Anti-Malware-Tools Anti-Malware-Software wird oft mit Antivirus-Lösungen gleichgesetzt, allerdings unterscheiden sich diese Kategorien funktional. Denn Anti-Malware-Produkte schützen nicht nur vor Viren und Würmern, sondern auch vor anderen Threats wie Spyware, Ransomware, und Trojanern. Inzwischen haben Anti-Malware-Tools der Enterprise-Klasse eigenständige Antivirus-Angebote weitgehend ersetzt. Das macht auch Sinn, denn klassische Computerviren sind längst nicht mehr die größte Bedrohung für Unternehmen, auch wenn sie lästig sein können. Cryptomining und insbesondere Ransomware machen inzwischen den Großteil der Angriffe aus, die auf Client-Ebene durch Malware initiiert werden. 10. Mobile Threat Defense Um mobile Devices vor Cyberangriffen und Datenverlust zu schützen, sollten im Enterprise-Umfeld Tools aus der Kategorie Mobile Threat Defense eingesetzt werden. Laut den Analysten von Gartner definiert sich diese Produktkategorie dadurch, dass sie mobile Geräte auf Anwendungs-, Netzwerk- und Device-Ebene schützen kann. Für so gut wie alle Unternehmen stellt es eine Herausforderung dar, Mobilgeräte zu managen – egal, ob es dabei um Unternehmens- oder Privatgeräte geht. Lösungen aus dem Bereich Enterprise Mobility Management (EMM) oder Mobile Device Management (MDM)-Angebot verfügen oft nicht über die nötigen Detection- und Prevention-Funktionen, um Mobile-Bedrohungen den Wind aus den Segeln zu nehmen. 11. Backup und Disaster Recovery Lösungen im Bereich Backup und Disaster Recovery sind im Unternehmensumfeld bekanntermaßen Pflicht. Sie stehen in zahlreichen Ausformungen zur Verfügung, beispielsweise auf lokaler Ebene, über die Cloud oder als Air-Gapped-Lösungen. Unerlässlich ist diese Tool-Kategorie beispielsweise, um Daten nach einem Ransomware-Angriff sicher wiederherstellen zu können. Sogenannte Bare-Metal-Restores (BMRs) aus der Cloud sind dabei unter Umständen für manche Unternehmen noch Neuland. Diese Lösungen sind dem Umstand geschuldet, dass Geschwindigkeit ein wichtiger Faktor ist, wenn es um die Recovery geht. Diesbezüglich haben sich Cloud-basierte BMRs in den vergangenen Jahren erheblich weiterentwickelt. Auch sichere, verschlüsselte Backups sind inzwischen ein Faktor, um eine Cyberversicherungspolice in Anspruch nehmen zu können. 12. Incident Response Incident-Response-Systeme sind von entscheidender Bedeutung, um Data Breaches zu erkennen und zu gewährleisten, dass bei der Reaktion auf Sicherheitsvorfälle vorab definierte Prozesse in Kraft treten, um Daten zu schützen, Informationen für die IT-Forensik zu bewahren und alle relevanten Stakeholder informiert zu halten. Und zwar in der richtigen Reihenfolge. Systeme dieser Art können – je nach Branche – erforderlich sein, um Compliance-Regelungen zu erfüllen. Auch mit Blick auf Cyberversicherungen werden Incident-Response-Lösungen oft vorausgesetzt. 13. AI-SPM Getrieben vom weiterhin um sich greifenden KI-Hype wollen diverse Unternehmen die Technologie möglichst schnell implementieren – und verzichten dafür darauf, ihre Initiativen mit einer sicherheitstechnisch stabilen Grundlage auszustatten. Das setzt das Unternehmen und seine Daten neuen Schwachstellen und Bedrohungen aus. Diese adressiert die Tool-Kategorie AI Security Posture Management – kurz AI-SPM. AI Security Posture Management konzentriert sich darauf, die Integrität und Sicherheit von KI- und ML-Systemen zu gewährleisten. Dabei umfasst AI-SPM Strategien, Tools und Techniken, um Daten, Pipelines, Applikationen und Services mit Blick auf ihre Sicherheitslage zu überwachen, zu bewerten und zu optimieren. Das kann beispielsweise verhindern, dass sensible Daten in KI-Modelle einfließen oder gewährleisten, Governance-Richtlinien für Business-Anwender durchzusetzen. (fm) View the full article

An automated scanning system has cut the time it takes to fix cybersecurity vulnerabilities across public sector IT systems, reducing median remediation time for general cyber vulnerabilities from 53 days to 32, and slashing DNS-specific average fix times from 50 days to eight. The results come from the UK government’s newly launched vulnerability monitoring service (VMS), which continuously scans more than 6,000 public bodies from doctors’ offices and ambulance trusts to hospitals and the Legal Aid Agency, tracking every identified weakness until it is resolved. The service detects around 1,000 types of vulnerabilities and processes approximately 400 confirmed findings a month, the government said. “Cyber-attacks aren’t abstract threats, they delay National Health Service appointments, disrupt essential services, and put people’s most sensitive data at risk,” said UK Minister for Digital Government Ian Murray in a statement announcing the results at the annual Government Cyber Security and Digital Resilience conference. “When public services struggle it’s families, patients and frontline workers that feel it.” Murray also unveiled a £210 million ($266 million) Cyber Action Plan and the launch of a first-ever government Cyber Profession, a program to recruit, train, and retain security talent across public services. Favorable comparison Paul McKay, VP principal analyst at Forrester, said the numbers compare favorably against private sector benchmarks. “These median fix times are generally better than the figures vulnerability management vendors publish in benchmark studies, which log average fix time ranging from a few weeks to several months depending on vulnerability criticality and whether it is known to be exploited in other organizations,” McKay said. The bigger problem in most organizations is not detection speed but communication, McKay said. Security teams that can’t explain why a specific finding matters tend to see vulnerabilities pile up unresolved. “Lots of security teams struggle to do this, overwhelming technology teams with lists of thousands of vulnerabilities with unrealistic SLA timeframes to fix them,” he said. The gap between average and best-in-class performance, he added, comes down to one thing: “The ability to cleanly articulate why vulnerabilities matter in terms of the business impact and show real rather than theoretical risk exposure.” That clarity of communication, McKay said, matters more than the tools an organization deploys. Tools good, talk better The UK government’s VMS uses a combination of commercial and proprietary scanning tools to detect vulnerabilities in internet-facing assets. But McKay cautions against drawing the wrong conclusion from the results. “Process, accountability and taking ownership for explaining why this matters to the resilience of the business is far more important than the technical tooling,” he said. “Building a robust prioritization approach and a strong trusted relationship with peer stakeholders responsible for doing the work of patching and applying fixes, matters far more than the specific tooling chosen.” The UK’s VMS alerts responsible organizations with “specific, actionable guidance” on each finding, rather than generating raw vulnerability feeds, and tracks progress until the issue is closed. The government cited DNS vulnerabilities as a specific example. Before the VMS, a weakness in a government DNS record could sit undetected for nearly two months. The service has closed that window to eight days. The statement also added that the service will expand to cover additional vulnerability categories, with fix times expected to fall further as it matures. The UK’s National Audit Office (NAO), however, flagged a challenge the VMS alone cannot fix. The workforce challenge Word of the success of VMS comes a month after the NAO reported that the cyber threat to government is “severe and advancing quickly,” concluding that resilience levels were lower than previously estimated, and determined the government would not meet its own 2025 cyber resilience targets. It identified skills gaps as the single biggest risk to building lasting cyber resilience. The government said the new Cyber Profession is a direct response to those findings. Co-branded with the National Cyber Security Centre (NCSC) and the Department for Science, Innovation and Technology (DSIT), it will “establish a dedicated Cyber Resourcing Hub, a government Cyber Academy, an apprenticeship scheme, and structured career pathways” aligned with UK Cyber Security Council standards. Manchester will serve as the primary hub, the statement added. “The launch of the government Cyber Profession will help attract and retain the most talented professionals with the top-tier skills needed to keep the UK safe online,” NCSC CEO Richard Horne said in the statement. DSIT did not respond to requests for additional technical detail on the VMS by the time of publication. View the full article

The brief for security leaders has changed. It used to be enough to reduce risk and keep the lights on. Now you are expected to enable AI adoption, connect more “things” to the network, modernize cloud at pace and still demonstrably reduce exposure, often without the comfort of ever-expanding budgets. In that environment, innovation is not a nice-to-have. It is a control. When it is governed well, it reduces risk, improves resilience, protects your people and accelerates business outcomes. When it is unmanaged, it becomes shadow IT, tool sprawl, and fragile architectures that increase the blast radius of the next incident. The solution is not to simply add more tools, more processes or more meetings. The solution is to bring discipline to innovation, so that experimentation becomes safe, repeatable and outcome-driven. As Marco Túlio Moraes recently noted in a CSO op-ed, while “discipline is the new power move in cybersecurity leadership,” the power move is often subtracting clutter and focusing on what actually reduces risk, rather than just adding more controls. What follows is a practical framework to harness innovation without exposure, grounded in four outcomes CISOs are already accountable for: operational capacity, security advantage, risk containment and business velocity. Use innovation to reduce burnout, not to create side quests Burnout is not a wellbeing footnote. It is an operational risk. The burnt-out analyst misses context. The disengaged engineer stops iterating. The overworked incident responder becomes reactive and brittle. Over time, that degrades detection quality, increases mean time to remediate, and drives attrition. You are not just losing staff, you are losing organizational memory and consistency. The 2025 ISC2 Cybersecurity Workforce Study found that almost half (48%) of respondents felt exhausted from trying to stay current on the latest threats and emerging technologies, and 47% often felt overwhelmed by the workload they were expected to bear. Innovation is one of the most effective tools a CISO has to counter this, but only if it is aimed at eliminating toil. Start with one blunt question: Where is judgment being wasted? If your team spends significant time copying evidence into tickets, chasing asset owners, manually enriching alerts, repeating the same triage steps or building reports by hand, you have found your first innovation backlog. Automate the routine, standardize the repeatable and reserve human attention for tasks that require reasoning. Then make innovation a capability accelerator, not a distraction. Give people ownership of meaningful improvements that sit within their domain and have an operational endpoint. Examples include: A detection engineer owning “detection as code” patterns and test harnesses A threat hunter owning telemetry quality improvements and query optimization An incident responder owning tabletop iterations and runbook hardening A cloud security lead owning guardrailed landing zone enhancements The critical constraint is this: every experiment needs an exit plan. Either it becomes a supported capability, or it is retired cleanly. Nothing drains teams faster than abandoned pilots that turn into “innovation debt” and hidden support burden. In the age of AI, not innovating is now a greater risk than innovating carefully AI has shifted the economics of offense. Adversaries can scale reconnaissance, tailor social engineering, generate variants and accelerate capability development with far less effort than before. The defensive posture that worked when change was slower will not hold. Public reporting has already highlighted this shift, including Europol’s ChatGPT – The impact of Large Language Models on Law Enforcement, which outlines how LLMs can accelerate fraud, impersonation and social engineering at scale. The right answer is not “AI everywhere,” it’s “AI where it changes the risk equation without creating a new blind spot.” Used well, AI-enabled innovation can compress time-to-judgement and increase defensive iteration speed: Triaging faster by summarising context, correlating signals, and proposing next investigative steps Accelerating detection engineering by generating queries, parsing log formats, and drafting test cases Strengthening readiness by generating realistic adversary emulation variants for purple teaming Improving resilience by helping teams produce clearer incident comms and decision logs under pressure The obvious warning is also real. AI can be wrong. It can be manipulated. It can leak sensitive context if data boundaries are weak. AI should be treated like any other high-impact component: scoped, tested and governed. The secure-by-design principle here is simple: Minimize the data you provide to models, by default Apply context-aware, proportionate controls to the data you provide to models, rather than blanket restrictions that push users to unmonitored alternatives (a dynamic now playing out with shadow AI) Keep humans in the loop for high-impact actions until you have proven safety and repeatability Make outputs auditable, including prompts, inputs and rationale for decisions Treat adversarial AI risks as first-class threats, including prompt injection and data leakage pathways (as captured in the OWASP LLM Top 10) Use a shared taxonomy (for example, MITRE ATLAS) to map likely adversarial AI techniques to your controls and tests Demand supplier transparency on model provenance, retention and controls if you use third-party platforms If you need a starting point, NIST’s AI Risk Management Framework (AI RMF 1.0), and its companion Generative AI Profile, provide a practical structure to govern, map, measure and manage AI risk. In other words, the risk is not “using AI.” The risk is using AI without design discipline. Innovation without exposure is exactly that discipline applied to modern tooling. Build a safe runway for experimentation, and make it secure-by-design for AI, IoT and cloud Most organizations fail at innovation in one of two ways. They block it, so the business routes around security. Or they allow it to sprawl, creating exposure through uncontrolled pilots and vendor proliferation. There is a third path: Enable by design, with controls invisible enough to preserve velocity but intelligent enough to prevent data walking out the door. The alternative is a safe runway: A repeatable operating model that makes experimentation easy while making new exposure hard. This is where secure-by-design becomes practical, not philosophical. It means defining guardrails that are standard, pre-approved and baked into how teams build. For AI, your runway is governance and boundaries. What data classes are permitted for which AI use cases What must be redacted or summarized before use What is logged and retained, and where How models are evaluated, including security testing and red-team scenarios Where AI can advise versus where it can act Visibility into the AI tools your people actually use, not just the ones you have sanctioned, because blocking a handful of apps does not prevent the long tail of shadow AI usage For IoT, your runway is lifecycle control and segmentation. A useful baseline to anchor “secure by design” requirements for device capability is NISTIR 8259A (IoT Device Cybersecurity Capability Core Baseline). Device identity and authentication as a baseline, not an enhancement Secure update mechanisms, firmware integrity and the ability to revoke trust Network segmentation that assumes compromise is inevitable Asset inventory that stays current and feeds monitoring A plan for end-of-life, because unmanaged devices become permanent liabilities For cloud, your runway is guardrailed architecture. A practical reference point for mapping those guardrails to recognized controls is the Cloud Security Alliance Cloud Controls Matrix (CCM) v4.1. Standard landing zones that enforce identity, logging and network boundaries Policy-as-code gates that prevent drift and misconfiguration at speed Secure CI/CD pathways that stop secrets, keys and risky configurations from shipping “Golden path” templates that teams can copy, rather than inventing new patterns in isolation When these guardrails exist, governance can move at the speed the business needs. You are no longer negotiating the basics on every project. You are asking, “Is this use case in scope for our runway, and do we have the controls that make it safe to scale?” That is what embedding cyber leadership at the innovation stage looks like in practice. It is not attending every meeting. It is owning the design patterns and decision frameworks that the organization uses before risk is locked in. Innovate to reduce friction, because friction is what creates shadow IT and long-term exposure A large proportion of enterprise exposure is behavioral, not malicious. Teams take risks when secure choices are slow, unclear or unavailable. Every time security creates friction without providing a usable alternative, the business invents a workaround. That is how shadow IT becomes “just how things get done.” GenAI is the most visible example today: ban ChatGPT and employees move to lesser-known tools or personal accounts, and you lose both control and awareness (as seen in the rise of unauthorized AI use). Innovation, when aligned to business outcomes, is exposure reduction through usability. This is where CISOs should behave like platform leaders: Build self-service security capabilities that reduce queues, such as standardized secrets management, approved identity patterns and reusable logging pipelines Publish golden paths for delivery teams, so the secure route is also the fastest route Rationalize tooling, because overlapping tools increase operational load and decrease signal quality Measure adoption, because a control that is not used is not a control The goal is not to remove governance. The goal is to remove unnecessary friction so that secure-by-design becomes the default behavior of the organization. A discipline overlay: Run innovation like a portfolio, and prove what changes outcomes Innovation without exposure requires one more layer: discipline in measurement and prioritization. This mirrors the broader industry push for secure-by-design and secure-by-default accountability, including CISA’s Secure by Design pledge (summarized CSO senior writer Jon Gold in “CISA inks 68 tech vendors to secure-by-design pledge — but will it matter?“). Treat innovation like a portfolio of risk-reduction investments: Define the business outcome you are protecting (time-to-market, uptime, fraud loss, customer trust, regulatory posture) Define the security outcome you are shifting (attack surface reduction, detection coverage, response speed, blast radius containment) Define the operational outcome you are improving (toil reduction, fewer false positives, better prioritisation, healthier on-call) Then measure what changed. If you cannot show movement in these metrics, you have activity, not progress. A simple 90-day plan to start: Days 1 – 30: Establish the runway Quantify toil and burnout signals in your security operations and engineering workflows Define standard guardrails for AI, IoT, and cloud, including data boundaries, identity, logging and segmentation Publish two or three golden path patterns that teams can reuse Set a fortnightly innovation review that focuses on design risk early, not sign-off late Days 31 – 60: Run two pilots with clear exit criteria Pilot 1: Delete toil in an operational workflow, and measure the time returned to the team Pilot 2: A secure-by-design pilot in emerging tech, such as an AI assistant with strict data boundaries, an IoT segmentation model or a cloud policy-as-code gate Days 61 – 90: Operationalize, rationalize and standardize Turn what worked into supported platform patterns and documented standards Retire what did not, to avoid innovation debt Measure adoption of golden paths and reduction in exceptions, alongside operational outcomes like queue health and response times Closing thought Innovation is already happening in your organization. The only question is whether it happens inside your guardrails, aligned to business outcomes, or in the shadows where it becomes exposure. For CISOs, the leadership move is disciplined innovation: Protect your people by deleting toil, keep pace with AI-enabled offense, embed secure-by-design principles into AI, IoT and cloud from the start, and reduce friction so the business stops routing around security. Do that consistently, and innovation becomes one of your strongest controls, not your biggest risk. The organizations pulling ahead are the ones that made GenAI safe to use at scale, with controls that move at the speed of their employees, not the speed of the next policy review cycle. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Have you once watched a leadership team clap for their “security culture month” like they’d landed a rover? Posters everywhere. Quizzes. A prize draw. Someone baked cupcakes with padlocks iced on top. Cute. Two weeks later, a product manager asked an engineer to “just share the admin credentials for an hour” because the vendor demo was in thirty minutes and the CEO was joining. The engineer hesitated, then shrugged and sent them. Nobody wanted to be the person who ruined the moment. That is culture. People in action, not process — just people trying to help each other, with good intent and possibly very bad outcomes. Not just the cupcakes… Awareness is what people can repeat. Ownership is what they do when the calendar screams and the boss stares. Your job is to turn the first into the second. Then prove it with numbers that mean something. What culture is when you stop romanticizing it Cybersecurity and risk culture isn’t a vibe. It’s a set of actions, behaviors and attitudes you can point to without raising your voice. Culture shows up in five places: When someone asks for an exception. When a change goes in late. When an alert fires at 2 a.m. When a junior analyst spots something odd and wonders if it’s worth escalating. When an executive wants speed, and the team wants safety. Ownership means people act like the risk is partly theirs. They don’t outsource judgment to “security.” They don’t hide behind process. They use the process as a tool. You can see ownership. It looks like this: A developer uses the approved deployment path instead of the clever shortcut. A finance lead challenges a risky vendor clause because they know who bears the breach liability. A team flags a near-miss and expects a response, not punishment. A leader says, “We’ll slip the release,” and doesn’t make a martyr out of the person who raised the red flag. You can’t train people into that. You have to build an environment where that behavior makes sense, an environment based on trust and performance not one or the other Why awareness stalls and ownership never arrives Most organizations don’t have a people problem. They have a system that trains people to behave badly and then acts surprised when they do. There are many examples, here are a few of our favorites: Mixed rewards. Leaders say, “Be secure,” then celebrate only speed, cost and heroics. People learn fast. If the quickest route wins promotions, it becomes policy. Foggy decision-making. Policies often read like a wish list. “Ensure least privilege.” “Maintain secure configurations.” Fine. But what do you do when a third party needs access today, the contract is vague and the project is already late? Real life lives in the gaps between policy sentences. Friction tax. If the secure path requires three approvals and a sacrifice, people will take the unofficial path. Shadow IT isn’t rebellion. It’s survival. Diffused accountability. “Security is everyone’s responsibility” sounds noble. It also means nobody is responsible. Everyone becomes an audience member. Security becomes the clean-up crew. Dead feedback loops. A junior person reports something suspicious. It disappears into a ticket queue. No acknowledgement. No learning. No change. Next time, they keep quiet. Your culture just taught them to. If you recognize yourself here, don’t panic. It’s normal. It’s also fixable. But the fix isn’t another awareness campaign. It’s a redesign. Redesign the operating system so ownership becomes the obvious move Ownership is a design outcome. Treat it like product design. Remove friction. Clarify choices. Make it hard to do the wrong thing by accident and easy to make the best possible decision. Make the secure path the easiest path People choose defaults. Give them good ones. Create golden paths for common work. Secure templates. Approved tools. Automated guardrails. Self-service access with sane limits. If your secure path feels like an obstacle course, you are manufacturing risk and hurting culture. Clarify decision rights in plain language Who can accept risk? Who must escalate? Who has the final call? Put it on one page. Add examples. “Any request for privileged access outside the approved workflow triggers escalation to the control owner.” That sentence beats a 10-page policy every day. Embed security inside the workflow, not at the end Late-stage gates create late-stage resentment. Shift checks into the delivery rhythm. Intake. Design. Build. Deploy. Keep each control point lightweight. One question. One evidence item. One decision. Turn “everyone” into “someone” Create local ownership roles where work happens. Product risk leads. Engineering champions. Business control owners. Give them time and authority. Don’t make it a volunteer hobby for the already-busy. Handle consequences like adults on the same team Protect good-faith reporting. People won’t raise their hand if you slap it. Also, address repeated bypass. Calmly. Consistently. Without drama. Culture hates inconsistency. It feeds on it. When you do this well, people stop fighting security. They start using it because it helps them ship with fewer landmines. Measure culture without turning it into theatre If you can’t measure the behavior, you can’t claim the culture. You can claim a feeling. Feelings don’t survive audits, incidents or Board scrutiny. We’ve seen teams measure what’s easy and then call the numbers “maturity.” Training completion. Controls “done.” Zero incidents. Nice charts. Clean dashboards. Meanwhile, the real culture runs beneath the surface, making exceptions, working around friction and staying quiet when speaking up feels risky. When interviewed at McKinsey, Richard Fain spoke about culture. “It’s not DNA. It’s not magic. It’s a daily effort, driven by leadership choices. If that’s true, your metrics aren’t a report. They’re your steering wheel. They tell you what your leaders are really building. Not what they say they value.” One of the most dangerous culture metrics is silence dressed up as success. “Zero incidents reported” can mean you’re safe. It can also mean people don’t trust the system enough to speak up. The difference matters. The wrong interpretation is how organizations walk into breaches with a smile. Measure culture as you would safety in a factory. You don’t celebrate that nobody pulled the emergency cord. You ask whether people would pull it if needed and whether the system would respond without disruption. The 5 metrics that move you from awareness to ownership These five aren’t perfect. They’re useful. They track whether people tell the truth early, whether the right owners act fast, whether you stop tolerating repeat risk and whether you learn by removing failure paths. That’s ownership in measurable form. They also align with what research shows matters most. Employee behavior. Especially the extra-role behavior people choose when nobody forces them. 1) Speak up rate What it is. The percentage of staff who raised a security concern or near miss in the last 90 days, per 100 employees. Why it matters. It tests psychological safety with receipts. People don’t report when they think it’s pointless, risky or embarrassing. When they do report, they’re signalling trust. Not just awareness. Make it sharper by adding a quality tag. Actionable versus FYI. Actionable means it triggered a review, a mitigation or a decision. FYI means vague noise, or a handoff with no context. If your Speak up rate rises but everything is FYI, you haven’t built ownership. You’ve built a complaint channel. What it replaces. “Zero incidents reported.” That metric rewards silence. It trains people to keep problems invisible. 2) Time to escalation What it is. The median time from the first signal. alert, anomaly, user report, to “right owner engaged. “Why it matters: This is decision velocity in a cyber suit. If escalation depends on a heroic individual noticing the right thing at the right time, your culture is brittle. A resilient culture routes signals to owners fast and reliably. What it exposes. Fuzzy decision rights, weak handoffs and teams that spend hours arguing about whose problem it is. Those delays aren’t technical. They’re cultural. How to measure properly. Track the median and the long tail. The tail is where breakdowns hide. 3) Repeat exception rate What it is. The number of repeated policy exceptions per quarter, and the percentage with an approved end date. Why it matters. Culture shows up in what you keep tolerating. One exception can be pragmatic. Repeated exceptions are a habit. Habits are culture. No end date means the exception became the real policy, just without the honesty of writing it down. What it replaces. “100% control completion.” Controls can be “complete” while exceptions quietly hollow them out. Use it as a lens, not a whip. split “new” versus “repeat” exceptions. Then sort repeats by root cause: friction, vendor constraints, unclear ownership, unrealistic delivery pressure. The point isn’t blame. The point is to fix the system that keeps producing the exception. 4) Phishing reporting ratio What it is. User-reported phishing versus tool-detected phishing, plus the median time to report. Why it matters. This metric captures vigilance, confidence and trust in one line. If users report fast, they believe reporting matters. They believe they won’t be mocked. They believe something will happen. That’s culture. If tools catch everything and users report nothing, you might still be protected, but you’re running a passive workforce. Passive workforces don’t surface near misses. They surface breaches. What it replaces. Training completion and simulation click rates used as stand-alone evidence of culture. Those can be useful inputs. They are not proof of ownership. 5) Fix-forward rate What it is. The percentage of recurring control failures eliminated at the root cause within 60 days. Not patched. Why it matters. High-performing cultures remove failure paths. They don’t babysit them. This is organizational learning you can’t fake. It also protects you from the comforting lie of activity. You can close a thousand tickets and still keep the same failure alive. “Closed on time” can be theatre. Fix-forward asks a sharper question. Did the failure stop happening? Make it ungameable. define “root cause eliminated” up front. If the same failure happens again, it wasn’t eliminated. It was rescheduled. Keep the scorecard simple, and test the signal While the ORCS standard uses 5 levels, a good starting point is to use three levels. Basic. Managed. Predictive. Tie each level to evidence, not optimism. Then do one thing many teams skip. Validate signal quality. Ask whether improving these metrics reduces harm or speeds recovery. If the metric moves and nothing improves, kill it. Legacy metrics derail transformation because people optimize what you track. In cyber, that can turn measurement into misdirection. If you build around these five, you stop measuring culture as intention. You start measuring it as behavior, decision speed, tolerance for repeat risk and the ability to learn fast. That’s the difference between “we care about security” and “we act like we do.” Keep the scorecard simple. Basic. Managed. Predictive. Tie each level to evidence, not confidence. “We think we’re better” is not a metric. It’s a hope. Turn measurement into governance that changes decisions Metrics without governance create cynical employees. They see numbers. They never see action. Then they stop caring. Be careful not to make compliance ‘the culture’ as it’s what people do when no one is looking that counts. Make culture a leadership routine Review the culture scorecard monthly. Treat it like revenue. Like reliability. Like safety. Quarterly, go deeper on hotspots. Repeat failures. Friction points. Assign real owners Each metric requires someone who can change, adapt and influence the system. Not just report the number. Security can advise and enable. The business must own the risk and the trade-offs. Reward the right stories Stop celebrating only heroic recoveries. Celebrate prevented incidents. Celebrate early escalation. Celebrate boring discipline. If you want ownership, reward the behaviors that create it. Fund friction removal Budget is culture. Invest in automation, secure defaults, identity hygiene and vendor controls that make the safe path easy to follow. Defund theatre. The posters. The annual checkbox training that no one remembers by Friday. Close the learning loop fast After an incident, don’t ask “what happened?” forever. Ask, “What will change by Friday?” Then track it. Publicly. When people see changes land, they keep reporting. When they don’t, they stop. Sustain ownership when the novelty wears off Culture doesn’t fail in the first month. It often fails in month seven, when priorities shift and the organization becomes fatigued. HBR shows the governance pattern that makes metrics live, and modern metrics must be embedded in routines and tied to ownership. Build micro-habits that survive stress Add a two-minute risk pause to major change approvals. Remember to use breathing to help manage stress Run pre-mortems before big releases. “How could this go wrong?” sounds simple. It saves you later. Give managers escalation scripts. People freeze when they need words. Give them words with aligned meaning. Tell better stories Most security stories start with shame. They end with blame. Tell stories about good judgment. About near-misses caught early. About a leader who chose safety and still shipped. Celebrating good news not just bad news is very important. Stories travel faster than policies. They also train identity. “This is who we are.” Rebuild ownership during onboarding Every hire is a culture reset. Teach new joiners how decisions really work. Who to call. What gets escalated? What does good look like in daily work? Role-based scenarios delivered with passion beat generic slides; every time. Equip middle managers Middle managers translate strategy into Tuesday — they are the oil and glue of the system. If they don’t model ownership, nobody will. Give them tools, not slogans. Trade-off language. Decision rules. Support when they push back on risky demands. Stress-test the system Run exercises that test decisions, not just technical response. Include product, legal, comms, procurement and key vendors. Ask one hard question. “Who can accept this risk right now?” If the room goes quiet, your culture just confessed. The road ahead Awareness is polite. Ownership is personal. Awareness says, “I attended.” Ownership says, “I changed how I work.” You build ownership by making it possible to care without getting punished. So, pick three behaviors you want to see. Make the secure path easier than the shortcut. Assign owners. Measure the signal. Review it monthly. Fix friction fast. Then, the next time someone asks for admin credentials “just for an hour,” you won’t need a cupcake to say no. Make cultural high performance the foundation of great security! This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

immer mehr betroffene Unternehmen und Organisationen folgen dem Rat, kein Lösegeld zu zahlen fadfebrian – shutterstock.com Laut einem neuen Bericht des Analyseunternehmens Chainalysis konnten Hacker im Jahr 2025 im Zusammenhang mit Ransomware-Angriffen insgesamt 820 Millionen Dollar erbeuten. Auch wenn die Summe hoch ist, im Vergleich zum Vorjahr ist sie damit um 28 Prozent gesunken. Zudem ist zu berücksichtigen, dass die Zahl der Angriffe im Jahr 2025 um 50 Prozent gestiegen ist (gegenüber 2024). Warnung vor Lösegeldzahlungen wirken Die Analysten erklären sich den Rückgang damit, dass immer mehr betroffene Unternehmen und Organisationen dem Rat folgen, kein Lösegeld zu zahlen. Wer auf die Forderungen eingeht, läuft nämlich ein höheres Risiko, künftig erneut Ziel ähnlicher Angriffe zu werden. Hinzu kommt, dass die Zahlung von Ransomware-Lösegeldern unter Umständen strafbar sein kann. Auffällig ist jedoch, dass die durchschnittliche Höhe der Lösegeldzahlungen deutlich gestiegen ist: Während die Gesamteinnahmen stagnierten, erhöhte sich die durchschnittliche Zahlung im Vergleich zum Vorjahr um 368 Prozent auf fast 60.000 Dollar. Das deutet laut Chainalysis darauf hin, dass betroffene Unternehmen im Einzelfall höhere Beträge zahlen – offenbar in der Hoffnung, dass die Cyberkriminellen gestohlene Daten tatsächlich löschen und nicht weiterverkaufen oder mit anderen Bedrohungsakteuren teilen. Laut Bleeping Computer ist dies das vierte Jahr in Folge, in dem die Gesamtlösegeldsumme rückläufig ist. (mb) View the full article

immer mehr betroffene Unternehmen und Organisationen folgen dem Rat, kein Lösegeld zu zahlen fadfebrian – shutterstock.com Laut einem neuen Bericht des Analyseunternehmens Chainalysis konnten Hacker im Jahr 2025 im Zusammenhang mit Ransomware-Angriffen insgesamt 820 Millionen Dollar erbeuten. Auch wenn die Summe hoch ist, im Vergleich zum Vorjahr ist sie damit um 28 Prozent gesunken. Zudem ist zu berücksichtigen, dass die Zahl der Angriffe im Jahr 2025 um 50 Prozent gestiegen ist (gegenüber 2024). Warnung vor Lösegeldzahlungen wirken Die Analysten erklären sich den Rückgang damit, dass immer mehr betroffene Unternehmen und Organisationen dem Rat folgen, kein Lösegeld zu zahlen. Wer auf die Forderungen eingeht, läuft nämlich ein höheres Risiko, künftig erneut Ziel ähnlicher Angriffe zu werden. Hinzu kommt, dass die Zahlung von Ransomware-Lösegeldern unter Umständen strafbar sein kann. Auffällig ist jedoch, dass die durchschnittliche Höhe der Lösegeldzahlungen deutlich gestiegen ist: Während die Gesamteinnahmen stagnierten, erhöhte sich die durchschnittliche Zahlung im Vergleich zum Vorjahr um 368 Prozent auf fast 60.000 Dollar. Das deutet laut Chainalysis darauf hin, dass betroffene Unternehmen im Einzelfall höhere Beträge zahlen – offenbar in der Hoffnung, dass die Cyberkriminellen gestohlene Daten tatsächlich löschen und nicht weiterverkaufen oder mit anderen Bedrohungsakteuren teilen. Laut Bleeping Computer ist dies das vierte Jahr in Folge, in dem die Gesamtlösegeldsumme rückläufig ist. (mb) View the full article

With ongoing skills gaps, AI reshaping roles and workforce stress as standing concerns for many CISOs, ensuring the resilience of the workforce has become top of mind. But due to budget constraints, return to office mandates and teams struggling to keep up with the threat landscape, CISOs are faced with a real challenge. Stephen Ford, VP and CISO at Rockwell Automation, knows what many CISOs face: it’s often difficult to find the properly skilled resources to deliver a strong cybersecurity program and capabilities. “So, workforce sustainability is an important consideration,” says Ford. Workforce resilience requires data-backed planning, managing the skills mix, and looking after the team as another element of risk management. How CISOs are approaching workforce planning Because the nature of cybersecurity work is unpredictable, Ford actively monitors his team to have a sense of how they’re managing. “There’s a fair amount of project work, but there’s also a lot of work that’s a reaction to events and depending on how many events or issues we run into, we could easily overwhelm the team,” he says. This concern is well founded, with the 2025 ISC2 Cybersecurity Workforce Study finding 47% of participants report feeling overwhelmed with the workload they’re expected to bear. Jon France, ISC2 CISO, agrees that workforce sustainability — managing stress, burnout and workload — is a standing concern, not a side issue. “Looking after the team and leveraging the team without killing them is on our agenda too,” says France. Ford has developed strategies to not only recruit talent but maintain their interests and get them through the ebbs and flows of daily life in cybersecurity. “I put a focus around monitoring the workforce and trying to get a good sense of the workloads that are coming in.” Having a team that’s properly staffed is important and this is where data is helpful to gauge the workload and make the argument to support resourcing. “It can sometimes be a little difficult to get your arms around it, but the right processes and ability to measure work help to calculate the expected workload and determine an acceptable resource level to support that workload,” Ford says. The challenge of quantifying workload and justifying resourcing decisions is commonplace. Only 55% of respondents believe their organizations have the resources needed to adequately address security incidents over the next two to three years, according to the ISC2 study. Burnout leads to job dissatisfaction Burnout is an ongoing concern for many CISOs and their teams, especially when unpredictable events can trigger workload spikes, burnout can escalate fast. “It’s something that can overwhelm pretty quickly,” Ford says. Industry surveys continue to flash red on persistent burnout that leads to job dissatisfaction. The ISC2 study found almost half of respondents (48%) saying they felt exhausted trying to keep on top of the latest threats and emerging technology. Ford approaches it as both a leadership and an operating-model issue, keeping in touch with workloads in the team and having a sustainable pipeline of talent to avoid overwhelming them with attrition. “I try to hire good people, empower them to operate, and delegate as much as I can.” While it’s hard to eliminate these issues entirely, using data to inform staffing levels, aiming to balance workloads as much as possible, and paying attention to the culture that surrounds the team are some of Ford’s strategies. “We spend time building good teams and we need to spend time to understand the challenges, the workload, and how they feel about the work.” AI as a force multiplier, not a headcount strategy Tooling and technology have always reshaped roles, and it’s no different with AI. This time, it’s the scale and speed of adoption, the fear, uncertainty and doubt about what it means for entry-level roles. More than two-thirds (69%) of respondents are on a path towards regular AI use, ISC2 indicates, which includes evaluating, testing and incorporating these tools into their operations. At software vendor Kantata, there’s a shift towards an AI-augmented workforce model that prioritizes automating high-volume tasks and integrating AI co-pilots to act as a force multiplier for team members. This includes high-friction areas like TPRM, security assessments such as RFP/RFI responses, and threat monitoring to significantly reduce operational noise. “By automating the first pass of data ingestion and alert triaging, our teams can focus on high-fidelity incidents and strategic decision-making rather than repetitive manual tasks,” says Taison Kearney, Kantata’s CISO and DPO. To ensure this doesn’t simply increase the workload, they reinvest the time saved into formalized upskilling, ensuring efficiency gains support team longevity and professional growth. Kearney believes that automation combined with upskilling helps reduce burnout and allows internal expertise to adapt to the threat landscape. “It secures our long-term sustainability by preserving institutional knowledge and providing our talent with a clear, high-growth career path.” France sees AI changing entry-level work but not erasing it. Citing the example of SOC analysts, he says it’s not going to replace the human in the loop. “But it’ll get them to a decision quicker, or at least get them to a more accurate picture of what’s going on.” He acknowledges fears about losing foundational experiences, but he believes we’ve been through this with other technical revolutions. “I think it’ll change some roles, but ultimately will not replace them. Coupled with that, it’s an efficiency gain,” France says. Kearney thinks AI is compressing the career ladder by automation of repetitive Tier 1 tasks that traditionally served as an entry-level apprenticeship. Consequently, junior roles are shifting from manual triage towards more complex problem solving — to the benefit of both employees and organizations. “This forces new hires to possess architectural and strategic skills much earlier in their career, ultimately potentially driving a higher reliance on AI capabilities for these individuals to be successful,” Kearney says. Staff have dedicated time for training, and the goal is for the team to develop the deep architectural knowledge with ‘human-in-the-loop’ expertise that’s increasingly required for complex defense. “This approach transforms the ‘urge to learn’ into a clear career pathway that values institutional knowledge and continuous professional evolution,” Kearney says. Building the cyber team amid a skill shortage Managing workload is a day-to-day concern but alongside this challenge is the task of building the right cyber team — using recruitment and developing existing staff. Yet it’s by no means a simple task, almost two-thirds of respondents in the ISC2 survey identified critical or significant skills shortages within their teams, underscoring that the challenge is both staffing and capability. Ford agrees it’s difficult to find top-tier talent across all the different cybersecurity disciplines, especially for a large organization like Rockwell. His strategy entails bringing in a key expert or two in different disciplines with years of experience and adding more junior, early career people. “Pairing them with seasoned experts allows you to build an effective, sustainable team over time, and I’ve seen that work extremely well for organizations with early career programs.” He also looks for experts from adjacent disciplines such as infrastructure, the data center space or application development keen to break into cyber. “I’m not recruiting for everyone. I’m recruiting for a few top experts and then building a pipeline either through early career or other similar activities from a technology space to get an effective cyber team,” he says. Rockwell has college intern and early career programs and strong relationships with local universities to bring in early talent and make them part of its projects with hopes of retaining some for full-time employment. The early career people don’t always fully grasp the different disciplines and activities that one can do in cybersecurity and Ford says they focus on helping them learn and gain an interest in cyber. “You end up with somebody that’s committed through time and a very strong employee and you can start looking at building the pipeline for senior level positions.” Where other organizations may look to fill gaps with external providers like managed service providers, Ford said Rockwell would rather cultivate the talent and expertise in-house. He finds it helps develop staff with an understanding of the critical knowledge about the organization and its operations — rather than see this valuable “thought leadership” sit outside the building. In some cases, early careers professionals are able to solve complex problems based on them being closer to new technology. “Some of the younger generations are actually more wired and suited to leverage some of the new technologies like AI, whereas some of the older, more seasoned professionals may be more of a traditionalist,” Ford tells CSO. Hiring managers and cybersecurity professionals are closely aligned, with the study showing problem solving, collaboration, communications, willingness to learn, and strategic thinking are the top non-technical skills across both groups. France widens what “good security talent” looks like, emphasizing communication skills, critical thinking, and curiosity in addition to core technical skills. Approaching it this way there is a broader talent pool to draw from. “You don’t have to come from a technical background, you can come from adjacent industries and bring those experiences in.” How CISOs can manage workforce planning 1. Bake in human sustainability Treat stress and burnout like any other risk indicator. Design rotations, on‑call policies, and staffing to manage workloads. 2. Use AI to redesign roles, not erase them For entry‑level roles shift tasks from: – Manual sifting → AI‑assisted triage and investigation. – Pure grunt work → judgment, escalation, and interpretation. Maintain human in the loop in job descriptions and process design. 3. Protect foundational learning in an automated environment Plan structured skills pathways: simulations, labs, red/blue exercises so juniors still learn what AI automates away. Pair juniors with senior analysts to upskill and explain why the tooling is making decisions. 4. Plan skills mix, not just headcount Intentionally recruit for communication, critical thinking, curiosity, not just technical certifications. Map your team to both technical depth and business‑risk communication needs. 5. Treat culture as part of resilience Delegate, manage staffing pipeline, and pay attention to team workload and culture. Encourage leaders to plug into peer networks for both intel sharing and emotional support, recognizing that CISO burnout is a systemic risk. View the full article

View the full article

View the full article

Anatoliy Eremin | shutterstock.com Kubernetes hat sich unter Enterprise-Softwareentwicklern zu einem durchschlagenden Erfolg entwickelt. Das veranlasst kriminelle Hacker zunehmend dazu, entsprechende Installationen mit speziell entwickelten Exploits anzugreifen. Dabei werden die Bedrohungsakteure immer besser darin, ihre Schadsoftware zu verstecken, (triviale) Sicherheitskontrollen zu umgehen und sich lateral durch Netzwerke zu bewegen, um weiteren Schaden anzurichten. Wie die von Sicherheitsanbietern wie Palo Alto, Wiz und Aqua Security eigens aufgesetzten Kubernetes-Honeypots demonstrieren, vergehen inzwischen im ungünstigsten Fall lediglich knapp zwanzig Minuten, bis erste Angriffsversuche auf neu erstellte Kubernetes-Cluster erfolgen. Dabei werden die bekannten TCP/IP-Ports gescannt, die etwa von Containern genutzt werden, um untereinander zu kommunizieren. Solche vorgelagerten Scans laufen demnach täglich Dutzende Male ab – was ein Hinweis darauf ist, dass die kriminellen Hacker auf automatisierte Kompromittierung setzen. Zwar gibt es einige Best Practices im Bereich Kubernetes Security – diese sind allerdings nicht weitläufig bekannt. Zudem erfordern sie teilweise spezielles Knowhow, Tools und Taktiken, die sich ganz wesentlich von dem unterscheiden, was nötig ist, um gewöhnliche Cloud-Instanzen oder virtuelle Maschinen abzusichern. Dieser Artikel analysiert zunächst ausführlich die Kubernetes-Bedrohungslandschaft. Anschließend erfahren Sie, wie Sie Ihre Cluster (besser) absichern. Die Kubernetes-Bedrohungslandschaft Wie komplex die Datenflüsse, Abhängigkeiten und Prozesse der Kubernetes-Landschaft miteinander verwoben sind, darüber gibt ein Blogbeitrag der Cloud Native Computing Foundation (CNCF) Aufschluss. Sämtliche Komponenten müssen dabei jeweils mit eigenen Methoden abgesichert werden, um: die Kommunikation zu verschlüsseln, Container, Storage Repositories und User angemessen zu authentifizieren sowie Container vor Exploits zu schützen. Dieses Diagramm (die Basis stammt von der CNCF, die Interpretation von Trend Micro) lässt erahnen, wie steil die Lernkurve ist, wenn es darum geht, das komplexe Kubernetes-Beziehungsgeflecht zu durchdringen. Assaf Morag, ehemals Datenanalyst bei Aqua Security, erklärt, warum das so ist: “Die Komplexität dieser Architektur wurde absichtlich geschaffen, denn Kubernetes ist darauf konzipiert, den Benutzern Freiheiten, eine offene Architektur und ein standardmäßig offenes Sicherheitsmodell zu ermöglichen.” Wie die Spezialisten von Palo Alto in ihrem “Complete Guide to Kubernetes Security” (Download gegen Daten) schreiben, ist das jedoch kein Grund zu verzweifeln. Die Tatsache, dass Kubernetes eine weitverbreitete Plattform mit vielen Integrationen sei, erleichtere es, automatisierte, systematische Prozesse zu entwickeln, die die Security zum Herzstück des Kubernetes-Build- und Deployment-Prozesses machen. Diese inhärente Offenheit von Kubernetes bedeutet jedoch auch: Es gibt kein allgemeines Security-Toolset, um das zu bewerkstelligen. Deshalb haben wir im Gespräch mit Cybersicherheitsexperten herausgefunden, wo der Schuh in Sachen Kubernetes-Sicherheit erfahrungsgemäß am meisten drückt. Leider mussten wir diesbezüglich nicht lange suchen. Denn oft fallen mit Blick auf Container bereits grundlegende Maßnahmen der Netzwerksicherheit unter den Tisch. Dabei wird zum Beispiel versäumt: Encryption Keys geheimzuhalten. komplexe Passwörter festzulegen. verschiedene Segmentierungsschemata anzuwenden. dem Least-Privilege-Prinzip zu folgen. Mit dem letztgenannten Basisversäumnis hängt ein weiteres zusammen, wie Nathaniel Quist, Manager of Cloud Threat Intelligence bei Palo Alto Networks, konstatiert: “Rollenbasierten Zugriff zu implementieren, kann sich diffiziler gestalten als bei anderen Cloud-Anwendungen. Das liegt am äußerst komplexen Modell von Kubernetes.” Analysten von Aqua Security konnten im April 2023 einen der ersten Backdoor-Angriffe auf Kubernetes-Cluster über rollenbasierte Zugangskontrollen beobachten. Dieser zielte laut den Experten auf mindestens sechzig unterschiedliche Cluster ab und führte zur erfolgreichen Installation von Cryptomining-Malware. Dabei wurden die Zugriffsrechte so manipuliert, dass die Schadsoftware über Admin-Rechte verfügte. Shay Berkovich, Threat Researcher bei Wiz, ordnet ein: “Diese kryptobasierten Angriffe sind auf dem Vormarsch. Vor allem, weil sich Kubernetes-Cluster als hocheffiziente Execution-Plattformen ideal für solche Workloads eignen.” Beispielhaft führt der Sicherheitsexperte die von seinem Arbeitgeber identifizierten Cryptomining-Angriffskampagnen “PyLoose” und “newhello” an. Ein neues Phänomen ist Cryptomining-Malware in Zusammenhang mit Kubernetes allerdings nicht. E-Auto-Pionier Tesla wurde bereits im Jahr 2018 mit Malware infiltriert, die Kryptowährungen schürft. Die Ursache war dabei offenbar ein unzureichend konfiguriertes Kubernetes-Dashboard. Venkat Thiruvengadam, CEO beim DevOps-Spezialisten DuploCloud, ergänzt: “Den Nutzern unter Einhaltung des Least-Privilege-Prinzips Zugriff auf die Kubernetes-API zu ermöglichen, ist eine schwierige, aber entscheidende Aufgabe. Eine standardisierte und automatisierte Methode zu etablieren, um diesen Zugang zu gewährleisten, stellt einen essenziellen Schritt dar, um Kubernetes-Umgebungen sicher zu gestalten.” Eine andere Herausforderung ergibt sich aus der verteilten Architektur von Kubernetes, wie Rani Osnat, Sicherheitsexperte bei Backslash Security, erklärt: “Auch wenn es um Code geht, gilt: Zu viele Köche verderben den Brei. Möglicherweise gibt es jeweils eigene Teams, um Cluster zu betreiben, Entwicklungs-Pipelines zu managen und Zugriffskontrollen durchzusetzen. Wenn diese Teams nicht konsequent miteinander kommunizieren, kann ein Governance-Mangel entstehen.” Laut Ami Luttwak, CTO bei Wiz, kann in einem solchen Setup auch die gemeinsame Nutzung von Code Repositories problematisch sein: “Das kann zwar zur Effektivität beitragen, birgt aber auch Risiken, wenn der gemeinsam genutzte Code kompromittiert wird. Getrennt arbeitende Teams sollten ihren Code auch in getrennten Clustern ausführen. Das ist noch lange keine gängige Praxis.” Das vielleicht größte Problem in Sachen Kubernetes-Sicherheit ist jedoch, dass es im Handumdrehen Supply-Chain-Angriffe automatisieren kann – insbesondere in Zusammenhang mit offengelegten geheimen Informationen und Schlüsseln. Sicherheitsforscher von Aqua Security konnten im Rahmen von Recherchen hunderte von Datensätzen identifizieren, die solche Geheimnisse offenlegten. Dazu durchsuchten die Experten die GitHub-API nach Anmeldeinformationen, wie sie in einem detaillierten Blogbeitrag beschreiben. “Es besteht ein klarer Bedarf für quelloffene Tools und Secrets Scanners, um die Detection-Fähigkeiten zu erhöhen, wenn es um kodierte Geheimnisse geht”, resümieren die Aqua-Experten. 5 Best Practices gegen Kubernetes-Exploits Folgende Best Practices empfehlen die Experten, mit denen wir gesprochen haben, um zu verhindern, dass Kubernetes-Cluster kompromittiert werden: umfassende, rollenbasierte Zugriffskontrollen, die Netzwerk-Richtlinien und User Namespaces voneinander trennen; “In-Cluster Separation”-Sicherheitsmaßnahmen; Key und Secret Management (Services); regelmäßige Cluster-Audits, um Fehlkonfigurationen zu identifizieren und zu beheben; entsprechende Schulungen für Mitarbeiter und Entwickler. Das “Kubernetes Security Cheat Sheet” von OWASP enthält diverse weitere, sehr spezifische Empfehlungen, um Ihre Cluster nachhaltig abzusichern. View the full article

Network admins with Juniper PTX series routers in their environments are being warned to patch immediately, because a newly-discovered critical vulnerability could lead to an unauthenticated threat actor running code with root privileges. The hole is “especially dangerous, because these devices often sit in the middle of the network, not on the fringes,” said Piyush Sharma, CEO of Tuskira. “If an attacker gains control of a PTX, the impact is bigger than a single device compromise because it can become a traffic vantage point and a control point at the same time. This opens the door to the stealthy interception of data flows, controller redirected traffic, or easy pivots into adjacent networks.” This issue affects PTX routers running versions of the Junos OS Evolved operating system earlier than 25.4R1-S1-EVO and 25.4R2-EVO. It doesn’t affect the standard Junos OS. In a notice, Juniper said it isn’t aware of any malicious exploitation of this vulnerability. The hole was found during internal product security testing or research. The PTX line is a series of modular high performance core routers powered by HPE Juniper Networks’ latest generation of custom Express family ASICs and optimized for 400G and 800G migrations. They offer native 400G and 800G inline MACsec, deep buffering and flexible filtering. The company says they are built for longevity in demanding WAN (wide area network) and data center use cases and deployment scenarios, including core, peering, data center interconnect, data center edge, metro aggregation, and AI data center networking. In its notice, Juniper says an Incorrect Permission Assignment for Critical Resource vulnerability in the On-Box Anomaly detection framework of the operating system allows an unauthenticated, network-based attacker to execute code as root. The detection framework is enabled by default. “The On-Box Anomaly detection framework should only be reachable by other internal processes over the internal routing instance, but not over an externally exposed port,” the alert adds. “With the ability to access and manipulate the service to execute code as root, a remote attacker can take complete control of the device.” To resolve the issue, admins should make sure version 25.4R1-S1-EVO of Junos OS Evolved is installed. They should also note that versions 25.4R2-EVO and 26.2R1-EVO are on the way. If the update can’t be installed immediately, admins should use access control lists or firewall filters to limit access to only trusted networks and hosts, to reduce the risk of exploitation of this issue. Ensure such filters only permit explicitly required connections and block all others. Another option is to disable the service by entering request pfe anomalies disable in the operating system’s command line. Sharma said Juniper vulnerabilities have attracted a lot of attention from hackers over the years because of the premium positioning the routers give if long-term footholds are established. “As a network operating system, Junos sits at the crossroads of major control points like identity, policy, and traffic, which means a single exploit can scale quickly across valuable networks,” he said. “Additionally, these footholds provide attackers a longer window to find and exploit vulnerable devices, since core network gear is painful to apply patching to due to long downtimes.” To prevent vulnerabilities such as the current flaw from leading to exploitation, organizations need a defense platform that can continuously monitor for anomalies across networks and alert security teams when malicious behavior is detected, he added. Disclosure of the vulnerability comes as Juniper’s parent firm HPE prepares to introduce new PTX12000 and PTX10002 router families at next week’s Mobile World Congress. HPE bought Juniper last year. View the full article

Google Cloud API keys, normally used as simple billing identifiers for APIs such as Maps or YouTube, could be scraped from websites to give access to private Gemini AI project data, researchers from Truffle Security recently discovered. According to a Common Crawl scan of websites carried out by the company in November, there were 2,863 live Google API keys that left organizations exposed. This included “major financial institutions, security companies, global recruiting firms, and, notably, Google itself,” Truffle Security said. The alarming security weakness was caused by a silent change in the status of Google Cloud Platform (GCP) API keys which the company neglected to tell developers about. For more than a decade, Google’s developer documentation has described these keys, identified by the prefix ‘Aiza’, as a mechanism used to identify a project for billing purposes. Developers generated a key and then pasted it into their client-side HTML code in full public view. However, with the appearance of the Gemini API (Generative Language API) from late 2023 onwards, it seems that these keys also started acting as authentication keys for sites embedding the Gemini AI Assistant. No warning Developers might build a site with basic features such as an embedded Maps function whose usage was identified for metering purposes using the original public GCP API key. When they later added Gemini to the same project, to, for example, make available a chatbot or other interactive feature, the same key effectively authenticated access to anything the owner had stored through the Gemini API, including datasets, documents and cached context. Because this is AI, extracting data would be as simple as prompting Gemini to reveal it. That same access could also be exploited to consume tokens through the API, potentially generating large bills for the owners or exhausting their quotas, said Truffle Security. All an attacker would need to do is view a site’s source code and extract the key. “Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill,” the researchers pointed out. “Nobody told you.” API key exploitation is more than hypothetical. In a different context, a student who reportedly exposed a GCP API key on GitHub last June was left nursing a $55,444 bill (later waived by Google) after it was extracted and re-used by others. Truffle Security said it disclosed the issue with the keys to Google in November, and the company eventually admitted the issue was a bona fide bug. After being told of the 2,863 exposed keys, the company restricted them from accessing the Gemini API. On February 19, the 90-day bug disclosure window closed, with Google apparently still working on a more comprehensive fix. “The initial triage was frustrating; the report was dismissed as ‘Intended Behavior.’ But after providing concrete evidence from Google’s own infrastructure, the GCP VDP team took the issue seriously,” said Truffle Security. “Building software at Google’s scale is extraordinarily difficult, and the Gemini API inherited a key management architecture built for a different era.” Mitigation The first job for concerned site admins is to check in the GCP console for keys specifically allowing the Generative Language API. In addition, look for unrestricted keys, now identified by a yellow warning icon. Check if any of these keys are public. Exposed keys should all be rotated or ‘regenerated,’ with a grace period that considers the effect this will have on downstream apps that have cached the old one. This vulnerability underlines how small cloud evolution oversights can have wider, unforeseen consequences. Truffle Security noted that Google now says in its roadmap that it is taking steps to remedy the API key problem: API keys created through AI Studio will default to Gemini-only access, and the company will also block leaked keys, notifying customers when they detect this to have happened. “We’d love to see Google go further and retroactively audit existing impacted keys and notify project owners who may be unknowingly exposed, but honestly, that is a monumental task,” Truffle Security admitted. View the full article

A recent job ad is causing plenty of head-shaking, suggesting that some government high-ups appear to be out of touch with the current state of the cybersecurity job market. There is plenty of evidence that the world needs cybersecurity talent. According to a recent ISC2 survey, 33% of organizations cannot staff their security teams adequately The result of this shortage is that these professionals are handsomely rewarded — but no-one appears to have told the UK government. Government Communications Headquarters (GCHQ, the UK equivalent of the US’s National Security Agency, or NSA), has just advertised for a chief information security officer. The role, which the ad describes as “one of the most influential cyber security leadership roles in the UK,” offers a maximum salary of £130,000 (about $175,000) — and none of the stock options or other inducements common in industry. Successful candidates will have “expertise in securing cloud environments and emerging technologies within digital transformation programmes, alongside a strong understanding of regulatory compliance frameworks such as NIST, ISO 27001, GDPR and GovS 007. Professional certifications such as CISSP, CISM or CCISO are highly desirable,” the ad said. The job ad stresses the importance of the role. “As CISO, you will work with colleagues to set and implement the organisation’s cyber and information security strategy, striking the right balance between capability, acceptable risk and technological progress. You will integrate security governance into a complex set of cross-agency organisational decision-making forums ensuring that information risks are managed effectively.” It’s a daunting set of responsibility for a senior professional working for an organization responsible for keeping an entire nation safe from cybercriminals and hostile powers, while pulling in a salary roughly equivalent to the salary of a security architect at a mid-level US company. View the full article

If you thought running an AI agent locally kept it safely inside your machine’s walls, you’re in for a surprise. Researchers at Oasis Security have disclosed a flaw chain that allowed a malicious website to quietly connect to a locally running OpenClaw agent and take full control. The issue stems from a fundamental assumption baked into developer tools that anything coming from “localhost” can be trusted. In reality, however, modern browsers allow external websites to open WebSocket connections to local services. According to Oasis findings, malicious browser pages can silently connect to the OpenClaw gateway, which auto-trusts localhosts and disables rate limits, enabling rapid password brute-forcing and unauthorized device pairing. “The modern web browser acts as a porous membrane, permitting untrusted, external JavaScript to bridge the gap to local services via WebSockets,” said Jason Soroko, senior fellow at Sectigo. “By relying on a local IP address to grant immunity from rate-limiting and to silently auto-approve device pairings, the system abandons the core tenets of a zero-trust architecture.” Once hijacked, the attacker can obtain the OpenClaw agent’s high privileges, including autonomous workflows, access to codebases, integrations, and credentials. Oasis researchers called the flaw ClawJacked, tracked under CVE-2026-25253, and reported full proof-of-concept (PoC) code to OpenClaw, which then promptly fixed it. ‘localhost’ became a weaklink Oasis Security’s research showed how a combination of design choices enabled the flaw. OpenClaw relied on local binding, automatic device pairing, and minimal authentication friction to streamline onboarding. Because WebSocket connections to localhost are not constrained by traditional cross-origin protections, a hostile website could initiate communication with the agent’s local gateway. From there, weak authentication controls and implicit trust in local origins allow the attacker to pair a device session and begin issuing commands. “What stands out is that it’s clear that product usefulness improved faster than security,” said Randolph Barr, CISO at Cequence Security. “The design focused on making the developer experience as smooth as possible by using local binding, automatic device pairing, and less friction for connectivity. This made adoption faster but also made defensive controls less effective.” Gal Moyal of Noma Security echoed this concern that agentic AI tools prioritize seamless developer experience over security. He noted that WebSocket access to localhost is a known browser behavior, “but its intersection with an unthrottled authentication endpoint and automatic device trust from localhost creates a particularly dangerous combination.” The full attack chain involves a victim visiting a malicious website whose hidden script connects to the locally running OpenClaw gateway via WebSockets, brute-forces its password without rate limits, and silently registers as a trusted device due to implicit localhost trust. Once authenticated, the attacker gains full control of the AI agent and its accessible data and functions. A larger blast radius Unlike regular software vulnerabilities, compromised AI agents have a bigger blast radius as they hold sensitive API keys, session tokens, file system access, and the authority to execute tasks across enterprise tools. Barr emphasized that autonomous systems “aggregate identity, credentials, and workflow authority,” meaning a failure doesn’t occur quietly. Instead, the agent executes actions “with the full authority of the user, at machine speed and machine scale.” In developer environments, that could include modifying code repositories, accessing internal systems, or triggering automated processes. Soroko described the browser itself as the unexpected attack vector, effectively bypassing the developer’s physical perimeter and “turning a simple background tab into an effective lock-pick.” Oasis noted that the OpenClaw team responded quickly, coordinating disclosure and issuing a fix (OpenClaw v2026.2.25 or later) within 24 hours. However, experts caution that rapid patching alone may not address the broader architectural risks. Organizations deploying AI agents should implement stronger authentication, explicit user approval for session pairing, rate limiting, credential scoping, and behavioral monitoring, they noted. View the full article

The US authorities have made it clear that they will have no truck with any individuals trying to by-pass regulations on trading cyberweapons with hostile powers. Selling sensitive cyber-exploit components to a Russian company landed Australian citizen Peter Williams with an 87-month prison sentence from the US District Court for the District of Columbia on February 24. “Williams took trade secrets comprised of national security software and sold them for up to $4 million in crypto currency. These incredibly powerful tools would have allowed Russia to access millions of digital devices,” said US Attorney Jeanine Pirro for the District of Columbia. “By betraying a position of trust and selling sensitive American technology, Williams’ crime is not only one of theft, it is a crime of national security. On the same day, the Department of the Treasury’s Office of Foreign Assets Control (OFAC) sanctioned Sergey Sergeyevich Zelenyuk and his company, Matrix LLC (trading as Operation Zero) for their acquisition and distribution of cyber tools harmful to US national security. Operation Zero trades in exploits of software vulnerabilities, and offered rewards to anyone who would provide them with exploits for US products. Among the exploits that Operation Zero acquired were proprietary cyber tools that had been created for the US government. These were then sold to at least one unauthorized user. “If you steal US trade secrets, we will hold you accountable,” said US Secretary of the Treasury Scott Bessent. “Treasury will continue to work alongside the rest of the Trump Administration to protect sensitive American intellectual property and safeguard our national security.” As a result of the sanction, all property or possessions held by Zelenyek and Matrix in the US will be blocked, with the possibility of criminal charges for transaction of any assets. View the full article

For a long time, I thought of the load balancer as a performance device. Its job was to distribute traffic, improve uptime, and make applications feel fast. Security was something that happened elsewhere, on firewalls, inside WAFs or deep in the application code. That perspective changed early in my consulting career. I worked with a customer who had invested heavily in security tools like firewalls, endpoint protection and a WAF buried deep in the stack. The technology was solid. The problem wasn’t the tools; it was the architecture. At the edge, the load balancer was treated purely as a performance device, tuned only for speed. Security policies such as strict TLS enforcement, request hygiene, and basic abuse controls were pushed to later phases. The attacker didn’t break our tools. They simply walked through the open path our design had left behind. Nothing failed technically. The architecture failed. Since then, every architecture I design starts with one principle: Application security begins at the traffic entry point. And in most modern environments, that entry point is the load balancer. What I saw go wrong in real projects I’ve worked with banks, healthcare systems, SaaS companies, and retailers. Different industries, same pattern: Internet traffic hits the load balancer The load balancer forwards traffic as fast as possible Security happens later The problem is simple. If the first system doesn’t enforce trust, everything behind it is already compromised by design. Example 1: Financial services The team invested heavily in downstream security tools. But the load balancer accepted weak TLS versions and ciphers because some legacy clients still needed it. Attackers forced connections down to older TLS versions, exploited weak cipher suites, and gained visibility into traffic that should never have been exposed. Fix: Disable TLS 1.0 and 1.1, enforce strong cipher suites, implement HSTS and OCSP stapling, and prefer TLS 1.3 with modern AEAD ciphers. Many teams treat TLS configuration at the load balancer as a compatibility setting rather than a security control. In practice, it defines the cryptographic trust boundary for the entire application stack. NIST’s TLS guidance is especially relevant here because it does not simply list preferred protocols. It explains why older versions introduce unacceptable risk, including downgrade attacks, weak key exchange mechanisms, and deprecated cryptographic primitives. When a load balancer allows legacy TLS for convenience, it creates an attack surface that downstream systems cannot correct. From an architectural standpoint, enforcing NIST-aligned TLS policies at the load balancer eliminates entire classes of attacks before traffic ever reaches a WAF or application server. It also provides a defensible baseline for audits and regulatory reviews, particularly in financial and healthcare environments where encryption standards are closely scrutinized Example 2: Retail platform The site faced massive bot traffic, such as scrapers, credential stuffers, and inventory scalpers. Protections were added inside the application, but the load balancer treated all traffic equally. Automated abuse consumed capacity before deeper security layers even saw it. Legitimate users paid the price. During peak periods, a large portion of incoming traffic was automated abuse. The business impact was clear: slower pages, failed checkouts, and lost revenue. What makes the OWASP Automated Threats guide particularly valuable is its focus on scale rather than sophistication. Most automated attacks do not rely on novel exploits. They succeed because they generate high volumes of traffic that look superficially legitimate. This is where load balancers play a critical role. They see traffic before authentication, before session state, and before business logic is invoked. If every request is forwarded downstream without discrimination, automated abuse can exhaust infrastructure long before application-level controls engage. By applying rate limits, connection caps, and behavioral thresholds at the load balancer, organizations can disrupt automated attacks at a fraction of the cost. The turning point: securing the entry layer Today, when I design systems, the first question I ask isn’t “How fast is it?” but “How much do I trust what enters here?” I treat the load balancer as a policy enforcement point for encryption, identity, protocol correctness, and abuse prevention. It becomes the first checkpoint in a zero trust path, not just a distributor of packets. Four key practices at the load balancer 1. Strong encryption and identity at the edge: Enforce TLS 1.3 where possible Allow TLS 1.2 only with modern AEAD cipher suites Disable legacy protocols that enable downgrade attacks 2. Protocol and request sanitation Normalize and validate traffic before it reaches the app Reject malformed headers (e.g., duplicate Host headers, invalid characters) and strip hop-by-hop header 3. Bot and abuse control Implement token bucket rate limiting keyed by IP or session Detect and block scrapers and credential stuffing early 4. Integration with deeper security layers The load balancer complements WAF and application security Enforce transport, identity, and hygiene before semantic inspection Cloud Security Alliance guidance consistently emphasizes shared responsibility and defense-in-depth. Why this matters beyond technology This isn’t just a technical argument, it’s a business one. When applications go down, customers leave. When breaches happen, trust is lost. Both often begin with small design decisions made early in architecture. A strong edge reduces total cost of ownership by cutting wasted capacity, lowering false positives downstream, and reducing incident response hours. Why edge security decisions compound over time Security decisions made at the load balancer tend to compound, for better or worse. A permissive edge may appear harmless at first, especially when applications are small and traffic volumes are manageable. Over time, however, those early choices harden into technical debt. Allowing weak encryption for compatibility today becomes an exception that must be supported indefinitely. Deferring abuse controls pushes more responsibility onto application teams that are already focused on features and delivery timelines. Pushing request hygiene downstream increases noise for WAFs and intrusion detection systems, leading to alert fatigue and slower incident response. The opposite is also true. When strong controls are enforced at the entry point, downstream systems benefit immediately. Applications receive cleaner, more predictable traffic. Security tools operate with higher signal and fewer false positives. Infrastructure capacity is preserved for real users instead of being consumed by automated abuse. This has a measurable business impact. Teams spend less time firefighting performance issues during peak traffic events. Incident response becomes faster because the scope of investigation is smaller. Compliance reviews are easier because baseline controls are consistently enforced at the edge. Most importantly, a strong entry layer creates architectural flexibility. Applications can evolve, scale, and migrate across environments without redefining security assumptions each time. The load balancer becomes a stable trust boundary, absorbing change while maintaining consistent protection. These benefits are rarely visible on day one. They become obvious only when something goes wrong, and by then, the quality of the front door determines how much damage occurs. Final thought I used to think application security lived deep inside the stack. Experience taught me otherwise. Every major incident I’ve seen had one thing in common: the attacker entered easily. That’s why I now say this without hesitation: application security must start at the load balancer. Not because it replaces other controls, but because every system needs a strong front door. When the front door is strong, everything behind it becomes easier to secure, easier to scale, and easier to trust. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

View the full article

Large language models (LLMs) have arrived in security in three different forms at once: as productivity tools that sit beside analysts, as components embedded inside products and workflows and as targets that attackers can probe, manipulate and steal. That convergence is why the conversation feels messy. The same capability that can summarize an incident in seconds can also generate a believable pretext for a spear phish. The same assistant that can draft detection logic can also be induced to leak sensitive context if it is wired into internal knowledge bases without guardrails. I treat LLMs as another high-impact system: define outcomes, model threats and build controls that assume the model will be wrong or manipulated. How LLMs are changing the work of security teams When people say “LLMs in the SOC,” they often picture a chat interface. The more meaningful shift is architectural: LLMs make it cheap to translate unstructured security data into structured hypotheses, narratives and next steps. That matters because a large share of security work is not technically difficult. It is context stitching. If I were rolling out an LLM capability inside a security program, I would start with a narrow set of workflows where the output is advisory and easy to verify. Then I would expand only after the team can measure quality and manage failure modes. Here are high-value use cases that are well-suited to early adoption: Alert triage summaries that turn raw telemetry into a short “what happened, why it matters and what I should check next” narrative Investigation copilots that generate a timeline from logs, tickets and chat transcripts, then highlight gaps and recommended pivots Detection engineering assistance for drafting Sigma, YARA or query language snippets that an engineer can review and test Vulnerability management copilots that cluster similar findings, explain exploitability in business terms and propose patch windows Policy and standards Q&A, where the assistant answers questions by citing the exact internal control language it relied on Even in these safe scenarios, the operating rule I use is simple: treat the LLM output as untrusted. If a model is allowed to write code, recommend a containment action or reference internal data, you should assume it can hallucinate, be socially engineered or be prompted into unsafe behavior. The OWASP community has cataloged common failure modes for LLM-enabled applications, including prompt injection, insecure output handling, sensitive information disclosure, excessive agency and overreliance. Those are not academic concepts. They map directly to the ways LLMs fail in security workflows. See OWASP Top 10 for LLM applications. Practically, I think of an LLM deployment in security as three layers: the model, the data it can see and the actions it can take. You can get significant value by widening the first layer (e.g., by using better models or prompts) while keeping the other two layers constrained. Three design choices consistently reduce risk without killing value: Make sources explicit: Use retrieval-augmented generation so the assistant answers from curated documents, tickets or playbooks and show the cited snippets to the analyst. Keep the model out of the blast radius: The model should not hold secrets. Use short-lived credentials, scoped tokens and brokered access to tools. Gate actions: Anything that changes a system state (blocking, quarantining, deleting, emailing) should require human approval or a separate policy engine. Leadership still needs to be clear-eyed about measurement. If you cannot quantify whether the assistant reduces response time or improves signal quality, you are taking on a new class of operational risk for uncertain gain. How attackers are using the same capability to scale and personalize Defenders are not the only ones automating context stitching. Attackers can use LLMs to do reconnaissance, craft language and iterate quickly. The result is not new attacks so much as a change in the economics of attackers: cheaper personalization, faster iteration and fewer language barriers. The most immediate impact is in social engineering. A good phishing email is not just about correct grammar. It is situational relevance: the right tone, the right internal jargon and the right moment in a business process. LLMs make that kind of tailoring trivial at scale. A 2024 study by Heiding, Lermen, Kao, Schneier and Vishwanath evaluated fully automated spear phishing campaigns validated on human subjects. In their experiment, AI-generated emails performed on par with human experts and far better than a generic phishing control group. The paper is worth reading in full because it quantifies the problem and makes the attacker economics tangible. At the same time, organizations are creating a new set of soft targets by wiring LLMs into internal knowledge bases, ticketing systems and workflow tools. If an attacker can induce prompt injection through a user-controlled input, a document in a shared repository or a compromised web page that the assistant is allowed to read, the model can become a conduit for data leakage or unsafe actions. That is why I treat LLM security as both an offensive and defensive discipline. You are defending your organization from LLM-enabled threats and you are defending your own LLM-enabled systems from being turned against you. The UK Department for Science, Innovation and Technology has mapped vulnerabilities across the AI lifecycle from design through maintenance, which is a useful mental model for security teams. To keep it actionable, I group attacker opportunities into three buckets: LLMs as persuasion engines: better pretexts, better multilingual scams, better impersonation and better fraud scripting LLMs as productivity engines: faster iteration on commodity malware, scripts, recon reports and exploit adaptation LLMs as targets and pivots: stealing prompts, extracting system instructions, poisoning data sources or manipulating tool-using agents The defensive implication is uncomfortable: some of your existing controls matter more than ever, especially verification, identity proofing and process hardening. If an executive approval workflow can be bypassed with a convincing message, an LLM will help attackers find and exploit that weakness faster. LLMs also complicate content-based detection. When attackers can generate clean language, I put more weight on technical and behavioral signals (sender authentication, unusual login, anomalous payment request pattern) than on tone or grammar cues. A control stack that lets you use LLMs without losing the plot I do not think organizations need a brand-new governance regime for LLMs. They need to apply existing governance muscle to new failure modes. The closest fit is risk management, not model worship. A helpful anchor is the NIST Artificial Intelligence Risk Management Framework, which organizes activities into govern, map, measure and manage. The value is less in the labels and more in the discipline: define accountability, understand context and impacts, measure risk and then operationalize mitigations. If I were advising a security and risk committee on an LLM program, I would propose the following control stack. It is intentionally pragmatic and it assumes a mixed environment of third-party models, internal data and tool integrations: Govern: Define what the model is allowed to do, who owns it and what unsafe means in your context (data classes, regulated workflows, critical decisions) Map: Document the end-to-end system, including prompts, data sources, retrieval pipelines, plugins and downstream actions; not just the model endpoint Secure the data: Inventory training, fine-tuning and retrieval corpora, enforce access controls and monitor for poisoning, leakage and unauthorized reuse Threat model with AI-specific techniques: Map likely adversary behaviors using MITRE ATLAS and include prompt injection and tool abuse in your scenarios Build guardrails at the boundaries: Input validation, content filtering, output constraints and schema-based parsing for any output that feeds automation Gate high-impact actions: Require explicit approvals, step-up authentication or policy engine checks before an agent can change state in production Test like you mean it: Red-team the assistant, run jailbreak and prompt injection suites and measure error rates under realistic loads Instrument, monitor and respond: Log prompts, tool calls and outputs, detect anomalous usage patterns and maintain a kill switch for unsafe automation Further steps Two pieces of public guidance are worth reading because they translate secure AI into operational steps. First, “Guidelines for secure AI system development” — a document published by UK National Cyber Security Centre (NCSC), the US Cybersecurity and Infrastructure Security Agency (CISA) — provides lifecycle guidance from secure design through secure operation and maintenance. Second, “Deploying AI systems securely” — published jointly by the US National Security Agency’s Artificial Intelligence Security Center (AISC) and the Cybersecurity and Infrastructure Security Agency (CISA), along with other national and international agencies — focuses on best practices for deploying and operating externally developed AI systems. Finally, I treat excessive agency as a line you cross deliberately. The more autonomy you give an LLM-based agent, the more you are building a new class of privileged software. If you would not give a junior script unfettered API access, you should not give it to a probabilistic model either. The convergence of LLMs and cybersecurity is not optional. Attackers will use these tools and employees already are. The advantage comes from capturing productivity gains while keeping control of data, identity and change management. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

View the full article

There is nothing like attending a face-to-face event for career networking and knowledge gathering, and we don’t have to tell you how helpful it can be to get a hands-on demo of a new tool or to have your questions answered by experts. Fortunately, plenty of great conferences are coming up in the months ahead. If keeping abreast of security trends and evolving threats is critical to your job — and we know it is — then attending some top-notch security conferences is on your must-do list for 2025. From major events to those that are more narrowly focused, this list from the editors of CSO, will help you find the security conferences that matter the most to you. We’ll keep it updated with new conferences so check back often. While we don’t expect this calendar to be comprehensive, we do aim to have it be highly relevant. If there’s something we’ve missed, let us know. You can email your additions, corrections and updates to Samira Sarraf>. March 2026 Cloud & Cyber Security Expo, London, UK: 4-5 March @Hack, Montreal, Canada: 7-8 March Gartner Security & Risk Management Summit, Mumbai, India: 9- 10 March Gartner Identity & Access Management Summit, London, UK: 9-10 March Billington State and Local CyberSecurity Summit, Washington, DC, US: 9-11 March Critical Infrastructure Protection & Resilience North America, Louisiana, US: 10-12 March FutureCon Tampa, Florida, US: 12 March Next IT Security, Stockholm, Sweden: 12 March CyberBay 2026, Florida, US: 12-13 March Gartner Security & Risk Management Summit, Sydney, Australia: 16-17 March SANS OSINT Summit & Training, virtual and Virginia, US: 16-22 March SecureWorld Charlotte, North Carolina, US: 18 March FutureCon Philadelphia, Pennsylvania, US: 19 March ASIS Europe, Antwerp, Belgium: 23-25 March Security Leadership 2026, Utrecht, Netherlands: 24 March InCyber Forum Europe, Lille, France: 31 Mar – 2 April April 2026 Cyphercon, Wisconsin, US: 1-2 April Gartner Security & Risk Summit, Dubai, UAE: 5-7 April SecureWorld Boston, Massachusetts, US: 8-9 April SpecterOps SO-CON 2025, Virginia, US: 13-14 April Next IT Security, Amsterdam, Netherlands: 16 April Aus Gov Data Summit, Canberra, Australia: 21-23 April Black Hat Asia, Marina Bay Sands, Singapore: 21-24 April Third Party and Supply Chain Cyber Security Summit, Munich, Germany: 22-24 April SecureWorld Houston, Texas, US: 30 April May 2026 CyberSecFest SP, São Paulo, Brazil: May TBC View the full article

Ransomware attackers are switching tactics in favor of more stealthy infiltration, as the threat of public exposure of sensitive corporate data is becoming the main mechanism of extortion. Picus Security’s annual red-teaming report shows attackers shifting away from loud disruption toward quiet, long-term access — or from “predatory” smash-and-grab tactics to “parasitic” silent residency. Four in five of the most common attack techniques deployed by ransomware strains are designed to stay hidden once attackers gain initial access. For example, ransomware operations are increasingly using defense evasion and persistence techniques as their tradecraft has evolved, according to Picus Security, a cybersecurity firm that specializes in breach and attack simulation. Attackers are also increasingly routing command-and-control (C2) traffic through trusted enterprise services such as OpenAI and AWS so that malign activity more closely resembles normal business traffic. Picus Security’s conclusions come from attack simulations combined with an analysis of 1.1 million malicious files and 15.5 million adversarial actions mapped to the MITRE ATT&CK framework. The Picus findings about attackers favoring stealth and persistence over loud disruption are consistent with the findings of ransomware research by Securin, which reports that attackers are chaining vulnerabilities in their attacks on corporate systems. “Ransomware groups no longer treat vulnerabilities as isolated entry points,” says Aviral Verma, lead threat intelligence analyst at penetration testing and cybersecurity services firm Securin. “They assemble them into deliberate exploitation chains, selecting weaknesses not just for severity, but for how effectively they can collapse trust, persistence, and operational control across entire platforms.” AI is now widely accessible to threat actors, but it primarily functions as a force multiplier rather than a driving force in ransomware attacks. Double jeopardy Ransomware gangs commonly favor double extortion where blackmail based on the threatened leak of stolen information is combined by the disruption caused by encrypting data after breaking into corporate networks. Picus reports a 38% drop in encryption over the past 12 months as more cybercriminals turn to silently exfiltrating data for extortion as their main stock in trade. Picus’ suggestion that the volume of ransomware attacks is dropping is disputed by other experts. Tony Anscombe, chief security evangelist at endpoint security vendor Eset, offered a contrasting perspective. “In the recent Eset H2 2025 Threat Report, the detection data shows a 13% increase between H1 and H2, coupled with the number of publicly reported victims increasing by 40% reported via ecrime.ch, then it [ransomware] does not appear to be in decline,” Anscombe tells CSO. Nick Hyatt, senior threat intelligence consultant at cybersecurity services firm GuidePoint Security, says the data of more than 7,000 victims was publicly posted last year, a figure that likely excludes “victims who paid and were never posted by the threat actor.” Far from showing any signs of consolidation, the number of active ransomware groups hit an all-time high last year, according to GuidePoint. “Threat actors streamlined their attack capabilities, using a mix of established techniques, vulnerability exploitation, and novel attacks to execute on their objectives,” says Hyatt. Rogues gallery Experts polled by CSO commonly rated Qilin, Cl0p and Akira as among the most active ransomware groups but there was no shortage of other contenders. “Akira stands out as the No. 1 ransomware group today from Huntress’ 2025 data,” says Dray Agha, senior manager of security operations at managed detection and response firm Huntress. “Their tradecraft is rapidly evolving specifically to neutralize existing security solutions, and we are seeing them aggressively target the hypervisor level to completely bypass traditional endpoint security protections.” Collin Hogue-Spears, senior director distinguished technical expert at application security firm Black Duck Software, says that ransomware operators have stopped operating like organized crime and started operating like a platform business. “Qilin posted over 1,000 victims in 2025, a seven-fold increase over the prior year,” according to Hogue-Spears. “LockBit 5.0 clawed back to operational capacity after its takedown.” Meanwhile the Scattered Spider/Lapsus$/ShinyHunters (SLSH) federation is running extortion-as-a-service, an approach that makes it easier for less technically skilled cybercriminals to make a dishonest living. SLSH has created a “structural shift” in the cybercrime ecosystem. “Seventy-three new groups appeared in six months because they no longer need to build their own tooling,” says Hogue-Spears. “They rent it.” New threat techniques require security rethink Vasileios Mourtzinos, a member of the threat team at managed detection and response firm Quorum Cyber, says that more groups are moving away from high-impact encryption towards extortion-led models that prioritize data theft and prolonged, low-noise access. “This approach, popularized by actors such as Cl0p through large-scale exploitation of third-party and supply chain vulnerabilities, is now being mirrored more widely, alongside increased abuse of valid accounts, legitimate administrative tools to blend into normal activity, and in some cases attempts to recruit or incentivize insiders to facilitate access,” Mourtzinos says. The evolving tradecraft of ransomware groups should prompt a rethink of defensive strategies. “For CISOs, the priority should be strengthening identity controls, closely monitoring trusted applications and third-party integrations, and ensuring detection strategies focus on persistence and data exfiltration activity,” Mourtzinos advises. View the full article

Color4260 / Shutterstock Crowdstrike hat die aktuelle Ausgabe seines Global Threat Report veröffentlicht – mit mehreren bemerkenswerten Erkenntnissen. So benötigte ein Angreifer im Jahr 2025 im Schnitt nur noch 29 Minuten, um sich vollständigen Zugriff auf ein Netzwerk zu verschaffen. Damit läuft die Kompromittierung rund 65 Prozent schneller ab, als im Vorjahr. Schnellste Breakout-Time aller Zeiten Die schnellste gemessene Zeit lag sogar bei 27 Sekunden – im Vergleich zu 51 Sekunden im Jahr 2024. In einem Fall begann die Datenexfiltration innerhalb von nur vier Minuten nach dem initialen Zugriff. Als Hauptgrund für diese Entwicklung führt Crowdstrike den zunehmenden Einsatz von KI-Tools bei Cyberangriffen an. So hätten Angreifer, die KI nutzen, ihre Aktivitäten um 89 Prozent erhöht. Den Sicherheitsforschern zufolge setzen insbesondere staatlich unterstützte und kriminelle Gruppen zunehmend KI ein, um ihre Angriffe effizienter zu gestalten: So habe die Russland-nahe Cybercrime-Gruppe „Fancy Bear“ die LLM-basierte Malware „Lamehug“ genutzt, um ihre Informationsbeschaffung zu automatisieren. Und die Hackerbande „Punk Spider“ konnte mithilfe KI-generierter Skripte sowohl Zugangsdaten deutlich schneller extrahieren als auch forensische Spuren beseitigen. Die Nordkorea-nahe Gruppe „Famous Chollima“ wiederum setzte KI-generierte Identitäten ein, um Insider-Operationen im größeren Maßstab durchzuführen. „Es ist ein Wettrüsten im Bereich der Künstlichen Intelligenz“, erklärt Adam Meyers, Head of Counter Adversary Operations bei CrowdStrike. „Die Breakout-Time ist das deutlichste Signal, wie sich die Angriffe verändert haben. KI verkürzt die Zeit zwischen Intention und Durchführung und macht gleichzeitig KI-Systeme in Unternehmen zu Zielen. Security-Teams müssen schneller sein als die Angreifer, um zu gewinnen.“ View the full article

Google has disrupted a China-linked espionage group that used Google’s spreadsheet application as a covert spy tool to compromise telecom providers and government agencies across 42 countries, sending commands and receiving stolen data through it, Google’s Threat Intelligence Group (GTIG) said on Thursday. Working with Mandiant, GTIG confirmed intrusions at 53 organizations across 42 countries, with suspected infections in at least 20 more. The group, identified by Google as UNC2814, is a suspected PRC-nexus actor that GTIG has tracked since 2017. “This prolific, elusive actor has a long history of targeting international governments and global telecommunications organizations across Africa, Asia, and the Americas,” GTIG said in a blog post. Unlike Salt Typhoon, UNC2814, the China-linked group whose intrusions into US telecom carriers drew scrutiny from Congress and federal regulators last year, operates with distinct tactics and targets a different set of victims globally, the post added. How UNC2814 gains its initial foothold has not been determined, though GTIG said the group has a history of exploiting and compromising web servers and edge systems. Once inside, it deployed a novel backdoor and maintained persistent access across target networks. A spreadsheet repurposed as a spy tool That backdoor, which GTIG named GRIDTIDE, did not communicate the way most malware does. “The backdoor leverages Google Sheets as a high-availability C2 platform, treating the spreadsheet not as a document, but as a communication channel to facilitate the transfer of raw data and shell commands,” GTIG said. The attackers wrote commands into spreadsheet cells and retrieved stolen data from them the same way. The malware polled the sheet every second for new instructions, wrote status updates back on task completion, and wiped the first 1,000 rows at the start of each session to erase traces of prior activity, the blog post explained. “This activity is not the result of a security vulnerability in Google’s products; rather, it abuses legitimate Google Sheets API functionality to disguise C2 traffic,” GTIG added. “The most unsettling detail about the GRIDTIDE backdoor is how it abuses legitimate Google Sheets API calls to function as its C2 channel, while still utilizing techniques like ‘living off the land’ to blend in with regular enterprise activities,” Andrew Costis, manager of the Adversary Research Team at AttackIQ, said. “This camouflage buys attackers time by slipping past the triggers defenders rely on, like obvious malware signatures or noisy beaconing, and hiding inside the same cloud app patterns teams are used to seeing.” How Mandiant found it The campaign came to light during a Mandiant Threat Defense investigation, when analysts flagged unusual activity on a CentOS server. A binary named xapt, designed to masquerade as the apt package manager on Debian-based Linux systems, had already escalated to root and was running shell commands to confirm its access level, GTIG said. The attacker had the highest available privileges on the system before the alert was raised. From that foothold, the threat actor used a service account to move laterally via SSH, deployed living-off-the-land binaries for reconnaissance, and installed GRIDTIDE as a persistent systemd service to survive reboots. The threat actor also deployed SoftEther VPN Bridge to maintain an encrypted outbound channel. “VPN configuration metadata suggests UNC2814 has been leveraging this specific infrastructure since July 2018,” GTIG said. The extent of that access became clear when investigators examined what the attackers were targeting. The real target was individuals The attackers planted GRIDTIDE on endpoints that held personally identifiable information, including full names, phone numbers, dates of birth, voter IDs, and national ID numbers. “We assess the targeting of PII in this engagement is consistent with cyber espionage activity in telecommunications, which is primarily leveraged to identify, track, and monitor persons of interest,” GTIG said in the post. GTIG did not directly observe exfiltration during this campaign, but noted that “historical PRC-nexus espionage intrusions against telecoms have resulted in the theft of call data records, unencrypted SMS messages, and the compromise and abuse of lawful intercept systems.” Chinese cyberespionage groups have consistently prioritized telecommunications as a target precisely because of the access their networks provide to sensitive communications and lawful intercept infrastructure. “When telecom firms and government agencies are in the blast radius, the stakes go beyond one company’s incident report,” Costis said. “Access to telecom environments can enable broad intelligence collection, help map relationships, and create opportunities for long-term monitoring that is hard to unravel once compromised.” To dismantle the operation, GTIG terminated all Google Cloud projects controlled by the attackers, disabled their accounts, revoked Google Sheets API access, and sinkholed current and historical C2 domains. It said it has also notified affected organizations and published indicators of compromise through Google Threat Intelligence, including IP addresses, domains, and file hashes tied to UNC2814. View the full article

There’s a phrase that’s become gospel in cybersecurity: “Employees are the last line of defense.” We’ve built an entire industry around it. Billions of dollars in security awareness programs, mandatory simulations and user-reporting workflows across endpoints, applications and collaboration tools. All predicated on a premise that sounds reasonable until you examine what we’re actually asking. Here’s what we’re asking: for the marketing coordinator, the accounts payable clerk and the sales rep to catch what sophisticated security tools and trained professionals missed. That’s not a security strategy. That’s asking farmers to repel mercenaries. The hierarchy we don’t talk about Think of the actual defensive capabilities in a typical organization. Your security team has years of specialized training, access to SIEM platforms, threat intelligence feeds and forensics tools. Their full-time job is defense. Your CISO has decades of experience, strategic visibility across the organization and the authority to make architectural decisions. Defense is their entire professional identity. Your employees have a short annual training module, a reporting workflow and whatever attention they can spare from the job they were actually hired to do. We’ve built a multi-billion dollar industry around the idea that the third group will succeed where the first two are failing. The evidence is already in This isn’t a theoretical complaint — it shows up in research on how real SOCs work. A study by the University of Oxford based on surveys and interviews with SOC practitioners found they “confirmed the high” false-positive rates of tools in use, and that many “false positives” are actually benign triggers that still require human validation. That’s not employee failure. That’s employees doing exactly what we trained them to do — and the training is producing volume rather than clarity. User reporting systems have become noise amplifiers. Employees are encouraged to flag anything that feels out of pattern: unusual access prompts, unexpected system messages, automated workflows, new integrations, time-sensitive requests. These signals once indicated risk. Today, they often reflect how modern, automated businesses actually operate. The cues we taught employees to distrust increasingly describe normal work. Meanwhile, SOC teams are drowning. It’s not just the queues — it’s the human cost. ISACA’s 2024 research found 66% of cybersecurity professionals say the job is more stressful now than it was five years ago, citing a more complex threat landscape alongside resourcing constraints. And our answer is: the accountants will save us. The real human layer Here’s the contrarian take the industry needs to hear: the ‘human layer’ that matters isn’t your employees. It’s your security team. When we talk about the human element in security, we should be talking about the CISOs running on four hours of sleep during an incident. The analysts pattern-matching across thousands of signals. The threat hunters who notice something slightly off in authentication logs. The architects who see the structural weakness before it becomes a breach. These are elite defenders. Trained professionals. The actual human intelligence in your security posture. If they can’t keep up — if their capacity is consumed by false positive triage, user-submitted reports, operational escalations and the constant pressure to clear queues — then no amount of awareness training for end users is going to close that gap. You don’t compensate for overwhelmed special forces by handing rifles to farmers. The uncomfortable math Let me walk through what’s actually happening in most organizations: The security team receives hundreds of alerts daily. Many originate from automated controls, user reporting workflows and precautionary detections designed to err on the side of caution. A significant percentage require investigation — you can’t know something is harmless until you look. Each investigation takes 15–20 minutes. The math quickly consumes 100% of available analyst capacity. When false positive volume hits capacity, strategic threat hunting drops to zero. There’s no time for pattern recognition across multiple signals, correlation with threat intelligence or the slow careful analysis that catches sophisticated attacks. The sophisticated attacks don’t announce themselves. They wait in queue, looking like everything else. Detection becomes random — a function of luck, not design. This is the crisis facing the actual human layer of defense. And we’re addressing it by asking frontline employees to identify subtle anomalies in systems and workflows that already passed through layers of automated controls. What this means I’m not arguing that baseline security hygiene is worthless. Employees should follow sensible practices and avoid obviously risky behavior. Basic discipline matters. But we’ve elevated awareness training from ‘basic hygiene’ to ‘strategic defense,’ and that elevation is dangerous. It creates a false sense of coverage. It allows organizations to underinvest in actual defensive capability because they’ve ‘addressed the human element.’ The human element that needs addressing is your security team’s capacity. Their tools, their processes, their ability to do strategic work instead of drowning in noise. Even regulators and standards bodies implicitly acknowledge the same bottleneck: monitoring has to be implemented in a way that minimizes false positives and false negatives — because human review capacity is finite. The question worth asking Every CISO should be asking: What percentage of my security team’s capacity is consumed by work that doesn’t actually reduce risk? If the answer is ‘most of it’ — if your analysts spend their days clearing precautionary alerts, reviewing benign activity and responding to internal escalations driven by uncertainty rather than threat — then you have a human layer problem. But the solution isn’t more training for end users. It’s restoring capacity to the people actually trained to defend you. The farmers have fields to tend. Let them farm. The question is whether your mercenaries have room to fight. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

RSA 2026 is still weeks away and the hype machine is humming. This year’s theme, “The Power of Community,” is somewhat ironic as the overwhelming chatter at the Moscone Center in San Francisco from March 23 to March 26 will be about AI agents, not humans. Welcome to the cybersecurity community, agents, automatons, and robots! While cybersecurity is an extremely diverse area covering everything from humans to critical infrastructure, here are five cybersecurity areas certain to have a starring role at RSA 2026 — and worthy of being on any CISO’s attendance agenda. The rise of the AI-SOC In 2026, we are moving beyond AI copilots toward autonomous agents performing traditional security operations center (SOC) activities such as triaging alerts, investigating malicious activity, isolating hosts, and patching software on our behalf. The trend is expected to reshape operations in the SOC even if the early realities haven’t yet fully aligned with agentic expectations. Still, there’s a lot of innovation happening from established vendors (e.g., Cisco/Splunk, CrowdStrike, Google, Microsoft, etc.) and startups (e.g., Andesite, Crogl, Prophet Security, etc.) alike. While AI-SOCs have potential, security pros remain leery about AI hallucinations and “black box” tools, and agents will succeed or fail based on a foundation of accurate and timely data access — threat intelligence, log files, tools integration, and so on. For RSA attendees, I recommend cautious optimism. One way or another the AI-SOC is coming — and sooner than you think. But CISOs should come prepared with requirements, lots of questions, and a willingness to cast a wide net rather than simply defaulting to existing tools vendors. CTEM in the spotlight In another evolutionary trend, most organizations are moving beyond scanning for software snafus to continuous threat exposure management (CTEM). By doing so, security teams hope to get a full picture of all assets, as well as their configurations, locations, software vulnerabilities, ownership, and business criticality. Armed with this data, CTEM platforms look at threat intelligence to assess adversary tactics, techniques, and procedures (TTPs), helping organizations prioritize which vulnerable assets represent the highest risks to the business. Some tools can even predict which assets may be most vulnerable to future exploits. CTEM tools from vendors such as Nucleus Security, ServiceNow (Armis), and Tenable (Vulcan Security) will be front and center at RSA but there’s a confusing cast of thousands in this space. While promising, CTEM done wrong will just add another tool to the security stack. Before succumbing to the shining objects at RSA, security teams should audit — and clean up — their data, define “crown jewel” assets, create their own risk scoring system, and build a mobilization plan for emergency and day-to-day patching processes between security and IT teams. Cyber resilience takes center stage According to Special Publication 800-160, Volume 2, from the National Institute of Standards and Technology (NIST), cyber resilience is defined as: “The ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources.” Note the expansive definition. Anticipating threats requires threat intelligence analysis, solid and continuous exposure management, and effective security controls. Withstanding and recovering from threats demands rapid detection, incident response, solid data backup and restoration, and a formal — and tested — business continuity and disaster recovery plan. Adapting involves security technology tuning, detection rules engineering, targeted investments, and CISO leadership. Obviously, there’s no one product that covers the entire spectrum but that won’t stop some vendors from claiming they are in the cyber-resilience business. Caveat emptor, my cybersecurity friends. Identity as the ‘new’ security perimeter Anyone remember the Jericho Forum circa 2004? The group argued that since data was moving outside the corporate network, security should be attached to data and user identity, rather than the physical or logical network location. Twenty-two years later, some vendors have had a similar epiphany about identity management. Okay, beyond my snark, I’m encouraged by the focus on identity management in areas like improved identity governance (SailPoint, Saviynt), passwordless authentication (Microsoft, Okta, Ping), and identity threat detection and response (Grip Security, Permiso Security). There is also copious use of AI in the identity space to assess user entitlements, user “liveness,” and identity configuration settings. Great stuff, but I’ve always found that identity and access management (IAM) is an area where everyone has an ownership stake but no one actually owns it. CISOs will have to work with business owners, CIOs, and application developers to address identity risks, making strategic projects lengthy and complex — a difficult environment for security startups. Everything AI: Future-proofing security operations All the areas above have an AI component, of course, but it’s worth carving out a discussion on AI across those and other AI cybersecurity categories here. First, CISOs face a significant challenge in their need to secure the development and usage of AI. This includes buckets of technologies, such as model context protocol (MCP) security, AI firewalling, content sanitation, digital content authenticity, AI security posture management, AI-driven DevSecOps, and so on. These technologies should support an overall business and technology strategy and governance framework around AI. Next, RSA will be a hotbed of AI threat chatter, with alarming discussions about vulnerability chaining, polymorphic payloads, and security control bypassing — all legitimate topics, but like defenders, adversaries are mostly using AI for research and process automation. Attendees should focus on relevant threat intelligence while discarding profuse hype. There are too many AI sub-topics to cover, but in my humble opinion, RSA participants should pay special attention to AI-centric skills and training sessions. Given an AI-enabled future, organizations will need security data engineers and AI security specialists, rare skill sets today. And as we supplant Tier-1 analyst functions with AI, we’ll also need to upskill junior cybersecurity specialists to become AI orchestrators who excel at human-agent teaming. AI skills development and training should be a top CISO priority. Other contenders Beyond my personal top 5, here are a few honorable mentions for CISO RSA 2026 agendas: Zero trust. This area rides shotgun with identity management and cyber-resilience strategies. As such, zero trust is still a top priority. CISOs should have an eye out for AI-enabled innovation that could accelerate their ZT implementation. Cloud security. Between multicloud, SaaS, and AI development, cloud security remains a bear. Organizations need an organic security strategy that grows with their cloud usage. CISOs should use the conference to help hone their growing multi-cloud/SaaS security needs. Cybersecurity platforms. There is lots of vendor money in this area as well. Security platforms are likely appropriate for most smaller firms but perhaps not for larger enterprises where the business and IT run far faster than cybersecurity. CISOs must weigh the benefits of platform efficiency against tools efficacy and rip-and-replace pain. *DR. CDR, EDR, and XDR (etc.), oh my! There’s lots of detection and response innovation around the edges of the cloud and network that will likely lead to highly distributed security operations. CISOs should explore how these blending and evolving spaces will impact a future centralized or distributed security operations architecture. IT and OT security. Yeah, we’ve been talking about this for years, but AI will be a force multiplier for smart devices and edge computing. For example, in the next five years, healthcare will transform based on wearable connected devices for data collection and patient care, so device availability and integrity could equate to life and death situations. Security teams can’t be left behind. Be on the lookout for evolutions in how to further secure IT/OT convergence and purpose-built AI agents for IoT/OT security. Post quantum cryptography (PQC). To me, this topic is hit or miss. CISOs working for intelligence agencies, defense contractors, or financial services firms should pay attention. Others can probably eschew this area – at least this year. The power of community. There’s that theme again, but this isn’t hyperbole. Cybersecurity professionals already learn from each other at RSA and Black Hat, and through professional groups like the Information Systems Security Association (ISSA). I’m hoping that agents can join the community in an era of collective defense — where many organizations band together in real-time to protect one another. One final thought With the proliferation of AI, this year’s RSA will feature more eye candy than in the past. Vendors pay millions of dollars for the chance to over stimulate users in this way. As always, security professionals should approach RSA with a list of requirements that support business strategy and technical needs. Eschew AI gaga and remember the sage words of Bruce Schneier, “Security is a process, not a product.” View the full article