Topic
NIST
Passphrases vs. Leetspeak Passwords: Why Four Random Words Outperform P@ssw0rd!2026
Policy & Regulation
Building the Foundation of Digital Trust: Why Identity Security Remains Undervalued
Policy & Regulation
How Malware Evades Sandboxes: Detection Techniques and Defense Strategies
Malware & BotnetsNVD Disruptions Force Security Teams to Diversify Vulnerability Intelligence Sources
The vulnerability management ecosystem has undergone major shifts over the past two years, undermining reliance on a single authoritative database. NVD, long considered the central enrichment layer for CVE records, has experienced significant operational problems that affect timeliness and completeness of data. Russian organizations are increasingly turning to BDU FSTEC as the national vulnerability database that provides official descriptions, remediation guidance, and coverage of domestic software. CVE maintained by MITRE continues to serve as the universal identifier standard, yet it lacks the detailed scoring and product mappings previously supplied by NVD. Vendor security bulletins from Microsoft, Cisco, Astra Group, and Positive Technologies often deliver the earliest and most accurate information. The article explains why a multi-source approach has become essential for comprehensive vulnerability management programs.
NIST Bans Periodic Password Rotation While Russia's FSTEC Mandates 90-Day Changes for Government Systems
In July 2025, NIST released the final version of SP 800-63B, explicitly prohibiting periodic password changes with the requirement that verifiers and CSPs shall not require subscribers to change passwords periodically. Eight months later, in April 2026, FSTEC approved a methodological document requiring passwords in state information systems and critical information infrastructure to be changed at least every 90 days, with mobile devices limited to 30 days and no reuse of the last 12 passwords. The requirements originate from Order No. 117, which itself contains no mention of passwords, but delegates details to lower-level methodological documents including the April 2026 guide that defines measure IAF.3. Compliance is enforced through the KZI protected indicator calculation submitted to FSTEC twice a year, with penalties including zeroing of the 0.25 weight group for repeated failures and immediate zeroing during penetration testing. The policy applies to government bodies, state unitary enterprises, institutions, and CII subjects, while commercial organizations outside this scope retain flexibility to set their own policies based on threat models. NIST and FSTEC requirements align closely on minimum length, failed attempt limits, MFA for privileged accounts, and prohibition of default passwords, differing primarily on the rotation mandate.
AI Agents Given Code and API Access Can Now Assist Attackers
An AI assistant that only answers questions can make mistakes, but an AI agent with access to email, code execution, corporate APIs and internal data can make those mistakes inside production infrastructure. The difference is fundamental: once tools, credentials and internal data are connected to the model, it becomes a privileged user that may not distinguish legitimate commands from hidden instructions on a web page. OWASP lists prompt injection, sensitive data disclosure, unsafe output handling and excessive autonomy as key risks for LLM applications. MITRE ATLAS specifically describes techniques involving prompt injection, context poisoning and tool invocation by AI agents. The article examines how agents differ from chatbots, how attackers can control them through untrusted content, and why a system prompt alone cannot protect code, data and APIs. CyberED is running its free NeuroAugust series of events and materials on AI in cybersecurity, including a session on secure AI system development.
Prompt Injection Emerges as Top Risk for LLM Applications in Production
Prompt injection attacks are moving from theoretical demonstrations to real-world exploits targeting AI assistants in enterprise environments. Attackers embed malicious instructions in emails, documents, and code comments that override developer rules when models process untrusted input. Incidents involving Microsoft 365 Copilot, GitHub Copilot, and Cursor have shown data exfiltration and remote code execution risks with severity scores above 9.0. The core issue stems from the lack of strict boundaries between trusted system prompts and untrusted external content fed into large language models. Defenses require layered controls including code-enforced permissions, input filtering, human confirmation for high-risk actions, and explicit marking of external data. Major vendors including OpenAI, Anthropic, and Google acknowledge that no single static defense can fully eliminate the threat. OWASP ranks prompt injection as the leading risk for LLM applications, urging organizations to treat AI agents as systems with untrusted inputs.
Security Vision SIEM Tackles Alert Overload with Data Quality Monitoring and MITRE ATT&CK Coverage
The article examines persistent SIEM challenges illustrated by the 2013 Target breach, where FireEye detected the compromise but response processes failed. It cites recent statistics showing organizations receive nearly 3,000 daily alerts with 46 percent false positives and 63 percent left uninvestigated. Security Vision SIEM, built on the Low-Code Security Vision 5 platform, integrates event collection, normalization, correlation, asset context, and basic response. Key July 2026 updates add collection stability monitoring, SLA dashboards, statistical anomaly detection, Sigma rule exchange, and retrospective process chain reconstruction. The product offers more than 1,200 correlation rules covering over 70 percent of MITRE ATT&CK techniques along with FSTEC BDU mappings and expert response recommendations. It supports remote and agent-based collection across 150 integrations while providing visual No-Code tools for connectors, rules, and dashboards.
Password Rotation Policies Under Scrutiny: NIST Guidelines, Historical Origins, and Logical Flaws
The article examines the long-standing practice of mandatory password rotation every 90 days, contrasting it with modern recommendations from NIST that advocate changing passwords only upon confirmed compromise rather than on a fixed schedule. It dissects common arguments in favor of periodic rotation, such as limiting offline hash cracking time and terminating unknown sessions, and demonstrates how these rely on reverse logic that starts from the control rather than from actual threats. Historical analysis traces the 90-day rule back to the 1985 DoD Green Book (CSC-STD-002-85), revealing that its own calculations showed password lifetime has minimal impact on security when proper rate limiting is in place. The piece distinguishes between data leakage and credential compromise, emphasizing that internal organizational signals provide far better indicators for targeted password changes than public breach databases. It concludes that scheduled rotation only makes sense as a substitute for mature detection capabilities, a trade-off explicitly recognized in PCI DSS v4.0.