Cela faisait un petit moment que je voulais produire cette synthèse mais le temps me manquait et j’ai enfin pu mettre sur papier les différents brouillons.
Je vais tout d’abord présenter le cadre général de la CJIS Security Policy version 6.0 (CJISSECPOL v6.0), publiée par le FBI le 27 décembre 2024.
Cette politique de sécurité définit un ensemble minimal de mesures de protection destinées à l’ensemble des organismes traitant des informations de justice pénale (Criminal Justice Information ou CJI) aux États-Unis.
Elle s’applique à toute personne ou entité – qu’il s’agisse d’une agence de justice pénale, d’un organisme non pénal accédant à des données CJIS, d’un contractant privé ou d’un prestataire – ayant accès à des informations de justice pénale ou participant à leur traitement.
Son objectif fondamental est de protéger le cycle de vie complet des données CJI, que ce soit pendant leur création, utilisation, transmission, stockage ou destruction. À cette fin, la CJISSECPOL v6.0 fournit des contrôles de sécurité appropriés pour garantir la confidentialité, l’intégrité et la disponibilité de ces informations sensibles, aussi bien lorsqu’elles sont stockées que lorsqu’elles circulent sur des réseaux.
Administrée selon un principe de gestion partagée, la politique CJIS est le fruit des directives du FBI, de textes de loi fédéraux et des décisions de la communauté police/justice. Elle est élaborée en concertation avec le CJIS Advisory Policy Board (APB), organe consultatif représentant les agences de justice criminelle et non criminelle de tous les États et territoires américains (ainsi qu’un représentant du Canada).
L’APB émet des recommandations afin que la politique intègre les besoins opérationnels du terrain, les nouvelles menaces et les évolutions technologiques. La version 6.0 s’inscrit ainsi dans un effort de modernisation de la politique de sécurité CJIS, validé par l’APB et le Compact Council fin 2024 (d’où le passage en numérotation majeure 6.0). Le document est structuré en 20 domaines thématiques de sécurité, alignés en grande partie sur les familles de contrôles du NIST 800-53.
Il couvre un large spectre d’exigences allant des accords d’échange d’informations inter-agences jusqu’à la gestion des risques, en passant par la formation, le contrôle d’accès, la sécurité physique, etc. (Policy Area 1 à 19), et inclut désormais un domaine dédié aux dispositifs mobiles (Policy Area 20) reflétant l’importance accrue de ces derniers. La CJISSECPOL est mise à jour périodiquement afin d’intégrer les nouvelles menaces et technologies, tout en offrant aux agences une latitude pour adopter des mesures encore plus strictes en fonction de leurs besoins locaux.
La gouvernance, Les responsabilités et la conformité
La gouvernance de la sécurité CJIS repose sur une répartition claire des rôles et responsabilités entre le FBI CJIS et les agences utilisatrices, selon le principe de gestion partagée mentionné plus haut. Au niveau fédéral, le FBI (via sa division CJIS) définit la politique et assure un rôle de supervision. Chaque État ou territoire dispose d’une CJIS Systems Agency (CSA), généralement une agence de justice pénale étatique, responsable de l’application de la politique CJIS dans sa juridiction.
La CSA est tenue de nommer un CJIS Systems Officer (CSO), qui est son référent sécurité CJIS. Le CSO supervise l’administration des réseaux et systèmes CJIS dans l’État et veille à la mise en œuvre des contrôles de sécurité.
Par directive, le rôle de CSO ne peut être externalisé. Le CSO définit notamment les normes de sélection, de formation et de supervision du personnel ayant accès aux données CJIS, et élabore les politiques d’utilisation des systèmes (réseaux, pare-feux, routeurs, etc.) traitant des CJI. Il s’assure également que chaque organisme relié à la CSA désigne un responsable de la sécurité (Information Security Officer au niveau CSA, Terminal Agency Coordinator au niveau local) et que tous les utilisateurs disposant d’un accès CJI reçoivent une formation de sensibilisation à la sécurité adaptée à leur rôle.
Au sein de chaque organisme local utilisant CJIS, un Terminal Agency Coordinator (TAC) ou Local Agency Security Officer (LASO) est généralement désigné. Il s’agit du point de contact sécurité chargé de la conformité de l’agence locale aux politiques CJIS et de la coordination avec la CSA et le FBI. L’adhésion à la CJISSECPOL est en effet contractuelle : toute agence qui accède aux services CJIS doit accepter et appliquer les exigences de la politique. En cas de recours à des prestataires privés, ceux-ci doivent signer l’addendum de sécurité CJIS (Security Addendum) annexé aux contrats.
Cet addendum, approuvé par le FBI, impose aux fournisseurs les mêmes obligations de sécurité que celles des agences publiques. Il formalise également l’engagement du contractant à se soumettre aux contrôles et audits de conformité CJIS.
La conformité est en effet vérifiée par des audits formels réguliers. Le FBI CJIS Division est habilité à conduire des audits de sécurité auprès des agences utilisatrices au moins tous les trois ans. De son côté, chaque CSA effectue des audits ou évaluations auprès des organismes de son ressort pour s’assurer du respect des exigences (ex : vérification des politiques locales, inspections des sites, examens techniques).
Si des manquements graves sont constatés, le FBI peut décider de restreindre ou suspendre l’accès de l’agence aux services CJIS jusqu’à correction. Ce mécanisme d’audit garantit une amélioration continue et une responsabilisation des entités participantes. Il convient de souligner que l’adoption de la CJISSECPOL, bien qu’exigeante, est perçue comme essentielle pour préserver l’accès fédéral aux données de justice pénale : ne pas s’y conformer exposerait l’agence à une perte d’accès, ce qui dans le contexte actuel de menaces cyber croissantes serait lourd de conséquences.
la,sécurité du personnel et la formation associée
La politique CJIS v6.0 insiste fortement sur la fiabilité des personnes ayant accès aux informations sensibles. Toutes les personnes – agents, employés administratifs, prestataires ou techniciens – accédant aux systèmes ou données CJI doivent faire l’objet d’un criblage de sécurité préalable.
En pratique, cela implique la réalisation d’une enquête de fond sur le personnel, comprenant notamment une vérification des antécédents criminels par recherche d’empreintes digitales au niveau de l’État de résidence et au niveau fédéral (vérification d’habilitation dite fingerprint-based record check).
La CJISSECPOL prévoit que ces contrôles d’habilitation soient effectués conformément aux lois et réglementations en vigueur, et réitérés périodiquement ou en cas de changement de poste sensible.
Dans les États où la loi ne permet pas ce type de contrôle pour certaines catégories de personnel, des dérogations existent, mais l’intention générale est qu’aucune personne présentant un risque ne puisse accéder aux données CJIS.
Ce que je retiens c’estque tout manquement grave d’un employé aux règles de sécurité doit entraîner des sanctions disciplinaires adaptées (Policy Area 12 Personnel Security et PS-8 Personnel Sanctions).
En complément du filtrage à l’embauche, la CJIS Security Policy impose une formation régulière de tous les utilisateurs autorisés. Chaque personne ayant accès à des CJI doit suivre une formation de sensibilisation à la sécurité (CJIS Security Awareness Training) dès sa prise de fonction puis chaque année par la suite.
Le contenu de la formation est adapté au niveau d’accès et de responsabilités de chacun. La version 6.0 détaille quatre niveaux de formation (basic, awareness, advanced, technical) afin de couvrir les besoins spécifiques : par exemple, un agent de maintenance qui entre dans une zone sécurisée aura une formation de base (niveau 1), alors qu’un analyste ayant directement accès aux données CJI ou un administrateur système CJIS suivra un niveau de sensibilisation avancé (niveaux 3 et 4) axé sur la protection technique des systèmes, la gestion des incidents, etc.. Cette démarche vise à instaurer une culture de sécurité homogène à travers toutes les organisations manipulant des données de justice pénale.
Les participants doivent notamment connaître les règles de comportement attendues (par ex. interdiction de partager des comptes ou des informations non autorisées), les procédures en cas d’incident, la reconnaissance des tentatives de social engineering, etc.
La bonne complétion de ces formations doit être tracée et les supports pédagogiques conservés, car ils pourront être examinés lors des audits de conformité.
Contrôle d’accès et authentification
Le contrôle d’accès logique aux informations et systèmes CJI est un pilier central de la CJISSECPOL. La politique impose la règle du moindre privilège (least privilege), ce qui signifie que chaque utilisateur ne doit se voir attribuer que les droits minimum nécessaires à l’accomplissement de ses missions.
Cette approche limite l’exposition des données en cas de compromission d’un compte et rejoint les principes généraux de séparation des tâches (AC-5 Separation of Duties). La version 6.0 renforce également les mesures contre les accès non autorisés ou inappropriés via des contrôles techniques comme l’interdiction d’utilisation de comptes partagés, l’inactivité maximum avant déconnexion ou le blocage après plusieurs échecs de connexion (verrouillage de compte après N tentatives, contrôle AC-7).
Chaque action d’administration ou d’accès aux données est associée à un identifiant d’utilisateur unique, de manière à assurer une traçabilité individuelle (voir section Auditabilité ci-dessous).
L’un des apports majeurs de CJIS v6.0 est l’obligation d’une authentification multi-facteur (MFA) systématique pour tous les accès utilisateurs, qu’ils soient « privilégiés » (administrateurs, comptes à haut niveau) ou non privilégiés.
Ce qui m’a frappé, la simple combinaison identifiant/mot de passe n’est plus jugée suffisante pour accéder aux systèmes contenant des CJI : il faut y ajouter au moins un second facteur d’authentification, comme un jeton physique ou un élément biométrique (empreinte digitale, etc.).
Cette exigence, adoptée par le FBI CJIS avec prise d’effet au 1er octobre 2024, généralise le concept d’“Advanced Authentication” qui, dans les versions précédentes de la politique, ne s’appliquait qu’aux accès distants.
Peu importe le type d’accès (local, distant, sur site sécurisé ou via internet), tous les comptes utilisateurs accédant à des CJI doivent être renforcés par une MFA adéquate. Concrètement, cela peut être implémenté par l’usage combiné d’un mot de passe et d’un jeton d’authentification physique ou logiciel (par exemple une appli OTP sur mobile ou une carte à puce PIV/CAC), ou d’un mot de passe et d’une donnée biométrique, etc.
En parallèle, la politique encourage l’adoption d’autres mécanismes de sécurité complémentaires tels que l’authentification non rejouable (anti-replay, contrôle IA-2(8)) ou l’acceptation de certificats d’identité fédéraux (PIV) pour harmoniser l’authentification des agents fédéraux.
La gestion des comptes et identifiants fait l’objet de contrôles précis (famille AC-2 et IA-4 notamment). Il est exigé que chaque utilisateur soit identifié de façon unique (pas de compte générique) et que les comptes obsolètes soient désactivés ou supprimés rapidement.
Les comptes à privilèges élevés doivent être limités en nombre et leur utilisation strictement encadrée (contrôles AC-6 sur les comptes privilégiés). De plus, CJIS v6.0 impose qu’une liste à jour des utilisateurs autorisés soit tenue et revue périodiquement par les agences, afin d’éviter que d’anciens employés ou des comptes non autorisés subsistent sans contrôle.
Finalement, toute connexion externe aux systèmes CJI (par exemple depuis un réseau non sécurisé ou via Internet) est considérée comme accès distant et doit non seulement satisfaire aux exigences MFA ci-dessus, mais également passer par des canaux sécurisés (voir Exigences Cloud et Cryptographie ci-après).
L’ensemble de ces mesures de contrôle d’accès vise à garantir que seules les personnes autorisées accèdent aux informations sensibles, et uniquement dans le cadre d’un usage approuvé.
Des éxigences pour les services cloud et l’externalisation
L’adoption croissante de solutions cloud computing par les forces de l’ordre et partenaires oblige la CJIS Security Policy à définir des garde-fous spécifiques pour l’usage du cloud. La v6.0 explicite ces exigences, notamment via son Annexe G.3 Cloud Computing.
Un principe fondamental est que le stockage de données CJI dans le cloud n’est autorisé que sous juridiction américaine ou d’un pays membre de l’APB.
En clair, les données CJIS ne doivent pas sortir du sol américain (États-Unis, territoires, réserves tribales amérindiennes) ou du Canada, et doivent rester sous l’autorité légale d’une agence membre de l’APB.
Cette restriction s’applique quel que soit le niveau de chiffrement appliqué aux données: même chiffrées, les CJI ne peuvent être hébergées sur un serveur situé en dehors des États-Unis ou d’un territoire approuvé. Des exceptions formelles existent uniquement pour des échanges internationaux spécifiques (entraide pénale, extraditions, etc.) fondés sur des accords gouvernementaux.
En pratique, toute utilisation d’un fournisseur cloud par une agence soumise à CJIS doit faire l’objet d’une analyse rigoureuse de conformité.
La politique invite à se poser une série de questions préalables avant de migrer des données CJI vers le cloud, par exemple :
Le datacenter du prestataire satisfait-il aux critères d’un emplacement physiquement sécurisé ? Les données seront-elles chiffrées au repos et en transit, et si oui, par qui et avec quelles clés ? Le prestataire autorisera-t-il le FBI et la CSA à conduire des audits de sécurité de ses infrastructures ?.
À cet égard, le fournisseur cloud est considéré comme un contractant : il doit donc, comme tout prestataire ayant accès à des CJI non chiffrées, soumettre son personnel aux vérifications d’habilitation et signer l’addendum de sécurité CJIS. La politique précise d’ailleurs que si une solution SaaS implique que des employés du fournisseur aient un accès logique ou physique non escorté à des CJI en clair, ces employés doivent être traités comme du personnel habilité CJIS (avec enquête d’antécédents, engagement contractuel, formation, etc.).
Une question cruciale est celle du chiffrement des données dans le cloud. La CJISSECPOL recommande fortement que l’agence cliente conserve la maîtrise exclusive des clés de chiffrement de ses données. En d’autres termes, il est préférable que l’agence chiffre elle-même les données avant de les envoyer dans le cloud, de sorte que le fournisseur n’ait jamais accès aux données en clair ni aux clés.
La documentation CJIS mentionne explicitement qu’il n’est pas recommandé de confier les clés de chiffrement au prestataire cloud, sauf impossibilité opérationnelle. Dans le cas où le chiffrement serait intégralement géré par l’agence (modèle Client-side encryption), les personnels du fournisseur n’accèderaient qu’à des données chiffrées et seraient alors exemptés des contrôles d’habilitation CJIS (puisqu’aucune donnée en clair n’est exposée à eux).
En revanche, si le fournisseur ou ses sous-traitants peuvent accéder à des données non chiffrées (par exemple pour assurer la maintenance d’un système hébergeant des CJI en clair), ils tombent pleinement sous le coup de la politique CJIS.
La CJIS Security Policy n’interdit pas l’usage de services cloud commerciaux, mais elle exige que toutes les mesures de sécurité de la politique soient applicables dans ces environnements, sans exception. Elle souligne que des certifications externes (de type FedRAMP, StateRAMP, SOC 2, etc.) peuvent être prises en compte par une agence pour évaluer un cloud, mais ne garantissent pas à elles seules la conformité CJIS.
Dans les faits, les contrats cloud traitant des CJI doivent inclure des clauses assurant le respect de la CJISSECPOL (localisation des données, audits inopinés, notification d’incident, suppression sécurisée, etc.). La politique cloud de CJIS v6.0 fournit plusieurs scénarios d’utilisation types pour guider les agences :
Par exemple :
Scénario 1 où une agence chiffre localement ses données avant stockage cloud (aucune CJI en clair dans le cloud),
Scénario 2 où l’agence utilise un IaaS avec cloud privé virtuel sécurisé (le personnel du fournisseur n’a ni accès logique ni physique aux serveurs traitant des CJI), ou encore un scénario de type SaaS où le fournisseur gère l’application et a potentiellement accès aux données (dans ce cas, contraintes accrues sur le fournisseur).
Dans tous les cas, « l’utilisation de services cloud ne dispense pas de se conformer aux exigences de sécurité » de la CJISSECPOL, et il appartient aux agences d’intégrer ces contraintes dès la phase de contractualisation et d’architecture du projet cloud.
La cryptographie et la protection des données
La protection cryptographique des données sensibles est un thème transversal dans la CJIS Security Policy v6.0, adressé principalement dans les contrôles de la famille SC (System and Communications Protection) et les annexes techniques (ex : Annexe G.6 Encryption).
Un principe fondamental est que toute donnée CJI transmise sur un réseau non sécurisé doit être chiffrée. Plus précisément, la politique requiert l’usage de mécanismes cryptographiques approuvés pour garantir la confidentialité et l’intégrité des CJI en transit lorsqu’elles circulent en dehors d’une zone physiquement sécurisée.
Le chiffrement à appliquer doit répondre aux normes fédérales : il est imposé d’utiliser soit des modules cryptographiques ayant la certification FIPS 140-3 (dernière norme en date), soit au minimum des algorithmes validés FIPS.
Dans la vrai vie, cela signifie qu’on doit employer un algorithme tel que l’AES (norme FIPS 197) avec une clé symétrique d’au moins 128 bits pour chiffrer les données CJIS en transit. Cette exigence vaut typiquement pour les communications traversant Internet ou tout réseau public (ex : requêtes vers NCIC, envois de fichiers hors du SI local).
Aucune connexion non chiffrée contenant des CJI ne doit transiter à l’extérieur d’un réseau sécurisé. À noter que la politique précise une échéance pour l’obsolescence de FIPS 140-2 : à compter de septembre 2026, les anciens modules certifiés FIPS 140-2 ne seront plus acceptés et devront avoir migré vers des modules conformes FIPS 140-3. Cela témoigne de l’importance accordée à l’usage d’une cryptographie à jour et validée.
Concernant les données « at rest » (stockées sur disque, base de données, etc.), la CJISSECPOL encourage fortement leur chiffrement également, bien que les modalités dépendent du contexte.
Le contrôle SC-28 stipule de mettre en œuvre des mécanismes cryptographiques pour empêcher tout accès non autorisé aux CJI stockées en dehors d’un emplacement sécurisé. En d’autres termes, si des informations de justice pénale sont stockées sur un support qui n’est pas dans une zone de sécurité physique contrôlée (par ex. sur un serveur dans le cloud, sur un ordinateur portable, ou sur tout support mobile), alors elles doivent être chiffrées. En revanche, si les données résident dans un centre de données agréé avec contrôles d’accès physiques (bâtiment sécurisé), le chiffrement n’est pas explicitement obligatoire mais reste recommandé comme mesure de défense en profondeur.
La politique laisse aux organisations la liberté de choisir les mécanismes de protection à appliquer aux données au repos (chiffrement de volume, chiffrement applicatif, tokenisation, etc.), du moment que le niveau de sécurité obtenu est conforme au niveau de sensibilité de ces données.
Si je prend l’exemple, pour des CJI particulièrement sensibles (ex. données d’empreintes ou d’ADN), une agence pourra imposer un chiffrement fort même en stockage local. En tout état de cause, les métadonnées dérivées de CJI non chiffrées doivent être protégées comme des CJI elles-mêmes (afin d’éviter qu’un fournisseur ne les analyse à des fins commerciales, par ex.).
La CJIS Security Policy donne aussi des lignes directrices sur la gestion des clés cryptographiques, point crucial pour l’efficacité de la protection. Elle précise que la génération, la distribution, le stockage, la révocation et la destruction des clés de chiffrement doivent être sous le contrôle de l’agence utilisatrice.
Cela rejoint à mon sens le point évoqué plus haut pour le cloud : l’organisation doit idéalement conserver la maîtrise de ses clés pour éviter toute exposition indue. Par ailleurs, seuls des algorithmes et paramètres cryptographiques recommandés par NIST ou approuvés par le NSA (pour les besoins classifiés) doivent être utilisés.
Ainsi, les protocoles vulnérables ou dépassés (comme le WEP pour le Wi-Fi ou les premières versions de WPA) sont formellement proscrits puisqu’ils ne répondent pas aux exigences FIPS 140-2/3.
De même, la politique impose le chiffrement des sessions d’administration des équipements (ex : utiliser SSH au lieu de Telnet, exiger TLS 1.2+ pour les interfaces web) et le chiffrement des mots de passe en stockage comme en transmission. En résumé, toute donnée ou canal contenant du contenu CJIS doit bénéficier d’un niveau de chiffrement robuste homologué, sans exception liée à la localisation sur un réseau tiers ou propriétaire.
L’auditabilité et la traçabilité des opérations
Garantir l’auditabilité des accès et actions effectués sur les systèmes CJIS est essentiel pour détecter les usages abusifs et reconstituer d’éventuels incidents de sécurité. La CJISSECPOL consacre un domaine entier à la journalisation et à la responsabilité (Auditing and Accountability) – Policy Area 4 – qui se décline en plusieurs contrôles (AU-2 journalisation des événements, AU-3 contenu des journaux, AU-6 examen et rapport d’audit, AU-7 réduction des journaux, AU-8 horodatage, AU-9 protection des journaux, etc.).
De ma compréhension, la politique exige que les organismes génèrent des enregistrements d’audit pour toutes les actions significatives sur les systèmes contenant des CJI. Cela inclut notamment l’enregistrement de tout accès aux données CJI (consultation, modification, suppression), des tentatives d’accès échouées, des changements de permissions, des événements de sécurité du système, etc.
Les journaux doivent permettre de répondre aux questions : qui a accédé à quelle information, quand, quoi a été fait, et avec quel résultat. Par exemple, si un utilisateur consulte le casier judiciaire d’une personne via NCIC, le système d’audit doit tracer l’identifiant de l’agent, la date/heure, l’identifiant de la personne recherchée ou le fichier consulté, et indiquer si l’accès a été autorisé ou refusé.
La tenue de ces journaux ne suffit pas : la CJIS Policy impose qu’ils soient conservés pendant une durée minimum d’au moins un an, sauf si des obligations légales imposent un délai plus long. Cette durée de rétention d’un an vise à couvrir à la fois les besoins d’investigation a posteriori (par ex. enquête interne sur un abus d’accès plusieurs mois après les faits) et les obligations réglementaires (réponses à des réquisitions judiciaires, FOIA, etc.).
Certains États ou agences peuvent décider de conserver les logs plus longtemps, mais un an est le plancher national. En outre, ces journaux d’audit doivent être protégés de toute altération ou accès non autorisé (contrôle AU-9) : seuls quelques administrateurs en charge de la sécurité peuvent y accéder, et ils doivent être stockés de manière sécurisée (de préférence sur un serveur ou support distinct, éventuellement en write-once pour éviter l’effacement).
La séparation des rôles est de mise : idéalement, l’administrateur système ne doit pas pouvoir modifier les logs qui pourraient révéler ses propres actions (d’où la nécessité de distinguer les privilèges d’audit et d’administration).
La CJIS Security Policy requiert aussi une analyse régulière des journaux. Le contrôle AU-6 stipule que les enregistrements d’audit doivent être examinés, analysés et des rapports produits pour détecter d’éventuelles activités inhabituelles ou violations. Cela signifie qu’une agence doit mettre en place un processus (souvent automatisé via un outil SIEM) pour passer en revue les logs et signaler les incidents tels que des accès non autorisés, des connexions à des heures indues, des tentatives répétées d’accès échouées, etc. La corrélation entre différentes sources de journaux est encouragée (ex : recouper les logs d’accès applicatifs avec ceux du pare-feu réseau – voir AU-6(3)) pour avoir une vision globale.
En cas de défaillance du mécanisme de journalisation (ex : disque saturé, service de log arrêté), des procédures doivent être en place pour réagir et ne pas perdre d’information (AU-5).
L’auditabilité recouvre aussi la traçabilité externe: comme évoqué dans la section Gouvernance, le FBI se réserve le droit d’auditer les agences tous les trois ans, ce qui implique que lors de ces audits, les agences doivent pouvoir fournir leurs journaux de sécurité de l’année écoulée, les rapports d’analyse, les listes d’utilisateurs, etc., afin de démontrer leur conformité.
La v6.0 maintient ces obligations et insiste sur la notion de redevabilité (accountability) des utilisateurs : toute action sur des CJI doit pouvoir être reliée à une identité humaine spécifique, d’où l’interdiction des comptes partagés et l’importance des journaux. Enfin, notons que la CJISSECPOL adresse également l’audit physique (contrôle PE-6 Monitoring Physical Access) pour les sites abritant des infrastructures CJIS : il convient de tenir des registres des accès physiques, par exemple enregistrements de badges ou de visiteurs, vidéosurveillance, etc., et de les conserver selon des politiques similaires.
La ségmentation du réseau et la sécurité périmétrique
La segmentation des réseaux et la protection des communications sont des composantes essentielles pour isoler les systèmes CJIS des menaces externes. Le contrôle SC-7 Boundary Protection exige de contrôler et filtrer les communications à toutes les interfaces réseau externes du système CJIS, ainsi qu’aux interfaces internes critiques. En pratique, cela signifie déployer des dispositifs de sécurité périmétrique (firewalls, passerelles, filtres IP, systèmes de détection/prévention d’intrusion) aux points d’entrée/sortie du réseau de l’agence, afin de surveiller et restreindre les flux de données.
La politique prescrit de plus la mise en place de sous-réseaux démilitarisés (DMZ) pour tout composant du système qui doit être accessible publiquement depuis Internet. Par exemple, si une application web permet à des partenaires externes d’interroger une base CJIS, cette application devrait résider dans une DMZ isolée du réseau interne de l’agence, avec des règles de pare-feu strictes pour contrôler les échanges entre la DMZ et le réseau contenant les données sensibles.
Ceci vise à compartimenter le réseau : même en cas de compromission d’un serveur en DMZ, l’attaquant ne doit pas pouvoir rebondir librement vers les serveurs internes CJIS sans franchir d’autres barrières de sécurité.
La connexion aux réseaux externes ne peut se faire qu’à travers des interfaces maîtrisées (managed interfaces) comportant des dispositifs de protection en cascade, conformément à une architecture de sécurité bien définie. En d’autres termes, les systèmes CJIS d’une agence ne doivent jamais être directement connectés à Internet ou à un autre réseau non sûr sans médiation : il faut intercaler des pare-feux, VPN, proxies authentifiés ou autres composants de sécurité.
Toutes ces mesures s’inscrivent dans une stratégie de défense en profondeur visant à réduire la surface d’attaque. Par exemple, la politique recommande de limiter le nombre de points de connexion du système vers l’extérieur pour faciliter la surveillance du trafic et le contrôle des flux. Elle mentionne aussi des bonnes pratiques telles que le filtrage anti-usurpation (bloquer en périmètre toute adresse source interne sortant de l’organisation, et vice-versa), ou l’utilisation d’architectures à plusieurs niveaux (par ex. un proxy d’authentification pour les accès distants aux applications CJIS).
En interne, la segmentation s’applique également afin d’isoler les composants critiques. Le contrôle SC-2 Separation of system and user functionality stipule que les postes utilisateurs ne doivent pas héberger de fonctions serveur sensibles, limitant ainsi l’exposition si un poste utilisateur est compromis.
De même, les bases de données contenant des CJI restreints (CHRI – Criminal History Record Information) devraient idéalement être sur des segments réseau séparés du reste du SI, avec accès filtré uniquement aux services applicatifs autorisés. La politique encourage aussi le recours aux techniques de virtualisation sécurisée pour cloisonner les environnements. L’Annexe G.1 (Best Practices – Virtualization) recommande par exemple la segregation des devoirs d’administration entre l’hyperviseur et les machines virtuelles, la journalisation centralisée hors de l’environnement virtualisé, et le chiffrement des flux entre VM et hôte.
Ces mesures garantissent qu’un éventuel attaquant qui aurait compromis une VM ne puisse pas facilement compromettre l’ensemble de l’infrastructure.
Un autre aspect de la segmentation concerne la distinction entre zones sécurisées physiquement et zones non sécurisées. La CJISSECPOL définit la notion de Physically Secure Location (section 5.9) : c’est un espace où l’accès physique est contrôlé et limité aux personnels autorisés (bâtiments ou salles sécurisées par badges, surveillance, etc.). Beaucoup d’exigences techniques (chiffrement, authentification renforcée) s’appliquent dès qu’on sort de ces zones sûres.
Si on prend, un poste de travail relié au réseau CJIS à l’intérieur d’un commissariat verrouillé n’a pas besoin d’établir un VPN chiffré pour interroger NCIC, car la ligne dédiée ou le réseau sécurisé est considéré comme dans le périmètre de confiance. En revanche, le même accès depuis un véhicule de patrouille ou depuis le domicile via Internet est un accès externe et doit être chiffré via VPN et soumis à MFA. Ainsi, la segmentation physique (contrôle des locaux) et logique (séparation des réseaux, tunneling VPN) se complètent pour assurer qu’à chaque frontière de sécurité, les données soient protégées de bout en bout.
Une conclusion sur la politique qui aborde la protection des endpoints et du trafic via le contrôle SC-5 Denial-of-Service Protection (dispositifs anti-DDoS si pertinent), SC-8 Transmission Confidentiality and Integrity (déjà couvert par le chiffrement), SC-13 Cryptographic Protection (couvert en partie précédente), SC-7(24) qui attire l’attention sur la protection des informations personnelles identifiables (PII) en périmètre (éviter qu’elles ne transitent en clair).
Je finirai cette partie par le fait que le CJIS v6.0 attend des agences qu’elles déploient une architecture réseau sécurisée et segmentée, avec des frontières bien gardées (pare-feu, filtres, passerelles), isolant les ressources CJIS du reste et du monde extérieur, et que les communications s’effectuent via des canaux chiffrés et contrôlés.
La sécurité des systèmes mobiles
Consciente que les appareils mobiles (ordinateurs portables, tablettes, smartphones) sont omniprésents dans les activités policières et judiciaires modernes, la CJIS Security Policy consacre de nouvelles dispositions spécifiques à leur égard (regroupées notamment dans la Policy Area 20: Mobile Devices).
L’utilisation de terminaux mobiles pour accéder à des CJI présente des risques particuliers (perte ou vol de l’appareil, connexions sans fil vulnérables, etc.), que la politique cherche à atténuer par des contrôles techniques et organisationnels adaptés.
Premièrement, tous les appareils mobiles autorisés à traiter ou stocker des CJI doivent être configurés selon des exigences renforcées. Le contrôle AC-19 impose d’établir des configurations de sécurité minimales pour ces terminaux, de définir les conditions de connexion (par ex. seuls des appareils contrôlés par l’organisation peuvent accéder aux systèmes CJIS) et de n’autoriser la connexion des mobiles aux systèmes qu’après validation expresse. En complément, le contrôle AC-19(5) requiert la mise en œuvre d’un chiffrement intégral du dispositif ou d’un chiffrement par conteneur pour protéger les données CJI sur les appareils mobiles.
A ma lecture, qu’il s’agisse d’un smartphone, d’une tablette ou d’un ordinateur portable, s’il contient ou peut accéder à des CJI, son stockage doit être chiffré (par exemple via BitLocker, FileVault, ou des solutions EMM chiffrant un conteneur d’applications). Cette mesure garantit que si l’appareil est perdu ou volé, les données sensibles ne pourront pas être extraites par un tiers non autorisé.
La politique note que le chiffrement par conteneur (c’est-à-dire restreint à certaines applications ou espaces de données) peut être utilisé pour cibler plus finement les données CJIS sur un appareil personnel, mais recommande le chiffrement global du disque comme solution offrant la protection la plus large.
Deuxièmement, la CJISSECPOL encourage fortement l’usage de solutions de Mobile Device Management (MDM). L’Annexe G.4 mentionne qu’un MDM permet d’appliquer à distance des politiques de sécurité uniformes sur les mobiles (ex : forcer un code PIN fort, effacement à distance, verrouillage après inactivité, interdiction d’installer des applications non approuvées, etc.). On retrouve ces principes dans les contrôles CM-11 User-Installed Software (désactiver l’installation libre d’applis) et MA-6 Timely Maintenance (assurer les mises à jour rapides) adaptés aux mobiles. De plus, Wireless Device Management est évoqué comme une priorité : les organismes doivent mettre en place des mesures pour mitiger les risques propres aux connexions sans fil (Policy 20.3 Wireless Device Risk Mitigations).
Prenons cet exemple, sur le contrôle 5.20.1.1 qui interdit d’utiliser des protocoles wifi obsolètes (WEP, WPA1) puisque non conformes à FIPS 140-2; il faut privilégier WPA2/WPA3 avec AES. Les points d’accès mobiles (5.20.1.4 Mobile Hotspots) doivent être sécurisés ou désactivés s’ils ne sont pas nécessaires. De même, le Bluetooth (5.20.1.3) doit être configuré de manière sécurisée (codes d’appairage robustes, mode non visible, etc. ou désactivé).
Troisièmement, les appareils mobiles doivent respecter les mêmes exigences d’authentification que les postes fixes. Le contrôle 5.20.7 stipule que l’authentification locale sur l’appareil (code de déverrouillage, biométrie) doit être activée. Surtout, l’Advanced Authentication (MFA) est requise pour accéder aux applications CJIS depuis le mobile (5.20.7.2). En pratique, cela signifie par exemple qu’un policier consultant une base CJIS via sa tablette devra s’authentifier avec un second facteur (token, certificat sur la carte agent, etc.), en plus du verrouillage de l’appareil lui-même. La politique prévoit des contrôles compensatoires (5.20.7.2.1) pour les situations où la MFA native sur mobile serait difficile, mais l’objectif reste de garantir un niveau d’authentification équivalent à celui des accès depuis un poste fixe.
Quatrièmement, une attention particulière est donnée à la sécurité logicielle et à la maintenance des mobiles. Le contrôle 5.20.4 exige d’appliquer les mises à jour/patches de sécurité des OS mobiles dès qu’ils sont disponibles, et de déployer des solutions de protection anti-programmes malveillants adaptées (antivirus mobile, analyse des applis, etc.).
Un personal firewall est également recommandé sur les ordinateurs portables accédant aux CJIS (Annexe G.4, point G.4.3) afin de filtrer le trafic entrant/sortant et prévenir les compromissions. La journalisation d’audit doit s’étendre aux événements mobiles (connexions du mobile au VPN CJIS, synchronisations, etc.), ce qui permet de tracer l’usage de ces appareils (contrôle AU-2 élargi aux connexions sans fil et mobiles).
Des procédures d’incident response sur mobile (5.20.5) sont requises : par exemple, en cas de perte d’un appareil contenant des CJI, l’agence doit avoir un plan pour le wiper à distance et notifier l’incident conformément à la politique d’incident (Policy Area 3).
Si je devais faire la synthèse du CJIS v6.0 qui reconnaît que les dispositifs mobiles sont devenus indispensables sur le terrain, mais impose qu’ils soient gérés dans un cadre de sécurité strict équivalent aux systèmes traditionnels.
Aucun appareil mobile non maîtrisé ne doit accéder aux données CJIS, et toutes les précautions (chiffrement, MFA, MDM, mises à jour, politiques d’usage) doivent être prises pour en faire des extensions sûres du système d’information de l’agence.
Ces mesures spécifiques, conjuguées aux exigences générales déjà évoquées (contrôle d’accès, cryptographie, audit…), visent à réduire la surface de vulnérabilité introduite par la mobilité tout en permettant aux forces de l’ordre de tirer parti des nouvelles technologies sur le terrain en toute confiance.
Enjoy !
Sources
- FBI CJIS Division – Criminal Justice Information Services Security Policy, version 6.0, Federal Bureau of Investigation, 27 décembre 2024. PDF officiel : https://le.fbi.gov/file-repository/cjis_security_policy_v6-0_20241227.pdf (Law Enforcement)
- Compass IT Compliance, CJIS Security Policy v6.0 – Key Updates You Need to Know, 10 février 2025. Résumé des principaux changements de la version 6.0 : https://www.compassitc.com/blog/cjis-security-policy-v6.0-key-updates-you-need-to-know (compassitc.com)
- Oregon State Police, Requirements Companion Document to the FBI CJIS Security Policy Version 6.0, 27 décembre 2024. Document annexe fournissant des détails sur les contrôles, priorités et échéances : https://www.oregon.gov/osp/programs/cjis/Documents/CJIS_Security_Policy_Requirements_Companion_Document_v6-0.pdf (État de l’Oregon)
- Michigan State Police, Updates to the CJIS Security Policy – Encryption requirements, PDF du service, mentionnant les règles sur le chiffrement en transit et au repos : https://www.michigan.gov/msp/-/media/Project/Websites/msp/911/ETS-Page/Updates-to-the-CJIS-Security-Policy.pdf (Michigan)
- Security Boulevard / Enzoic, Meeting CJIS v6.0 Password Security Requirements, 11 juin 2025. Description des nouvelles exigences sur les mots de passe (listes interdites, contrôle continu) : https://securityboulevard.com/2025/06/meeting-cjis-v6-0-password-security-requirements/ (securityboulevard.com
