Connecter en toute sécurité des tiers à un incident en direct sans exposer l'incident

Les incidents majeurs existent rarement dans les limites informationnelles d'une seule organisation.

La police, les ambulances et les pompiers peuvent chacun gérer leur propre intervention via leurs propres salles de contrôle et systèmes de gestion des incidents. Les autorités locales, les hôpitaux, les opérateurs d'infrastructures et d'autres agences peuvent faire de même.

Dans le même temps, des informations précieuses peuvent provenir d'organisations qui ne sont absolument pas impliquées dans la gestion de l'incident.

Les universités, les organismes de recherche, les systèmes de surveillance environnementale, les fournisseurs d'infrastructures et les services de modélisation spécialisés peuvent détenir des informations susceptibles d'améliorer sensiblement la connaissance de la situation.

Ce sont des relations très différentes, mais elles créent un problème commun :

Comment permettre à des tiers de confiance de contribuer des informations à un incident multi-agences en direct sans leur donner un accès inutile au système central de gestion des incidents, et sans leur imposer d'ouvrir leurs propres systèmes en retour ?

C'est l'un des problèmes que nous adressons avec ORDU Studio et, plus précisément, ORDU Connect.

Le partage d'informations n'exige pas un accès partagé

Il est tentant de considérer le partage d'informations multi-agences comme un problème de permissions.

Ajouter chaque organisation participante en tant qu'utilisateur. Leur donner des comptes. Restreindre ce qu'ils peuvent voir.

Ou aborder le problème dans l'autre sens et se connecter directement aux systèmes de chaque organisation, en donnant à la plateforme centrale la permission de récupérer les informations dont elle a besoin.

Les deux approches élargissent potentiellement le périmètre de sécurité.

Un incident actif peut contenir des informations opérationnelles hautement sensibles : décisions internes, détails du personnel, localisations, vulnérabilités, communications, plans d'intervention et informations fournies par d'autres organisations.

De même, les systèmes exploités par la police, les ambulances, les pompiers, les hôpitaux, les fournisseurs d'infrastructures, les universités et d'autres organisations peuvent contenir des informations qui n'ont absolument aucune raison d'être exposées à une plateforme centrale multi-agences.

L'exigence de partager une information ne doit pas devenir une exigence d'exposer un système entier.

ORDU traite donc la contribution d'informations, la réception d'informations et l'accès aux systèmes d'une autre organisation comme des concepts distincts.

Une organisation peut contribuer à l'image opérationnelle multi-agences sans devenir utilisatrice d'ORDU Console.

ORDU peut recevoir des informations d'une organisation sans se voir accorder l'accès aux systèmes internes de cette organisation.

Cette séparation est fondamentale dans l'architecture d'ORDU Connect.

Fournisseurs Tiers Vérifiés et Sécurisés

Au sein d'ORDU Studio, nous désignons les fournisseurs d'informations externes de confiance sous le terme de Fournisseurs Tiers Vérifiés et Sécurisés, ou SV3P.

Un SV3P peut être une organisation opérationnelle telle qu'un service de police, d'ambulance ou de pompiers gérant sa propre salle de contrôle d'incident.

Il peut s'agir d'un hôpital, d'une autorité locale, d'une compagnie de services publics ou d'un opérateur d'infrastructure.

Il peut tout aussi bien s'agir d'une organisation n'ayant absolument aucun rôle dans la coordination de l'incident, mais qui exploite un système, un ensemble de données ou une capacité analytique spécialisés devenant pertinents dans certaines circonstances.

Une université exécutant un modèle d'impact sismique en est un bon exemple.

Ces organisations entretiennent des relations très différentes avec un incident, de sorte qu'ORDU Connect ne peut pas supposer que chaque SV3P doit disposer du même niveau d'accès ou échanger les mêmes informations.

Plus important encore :

Le SV3P contrôle quelles informations il partage et quand il les partage.

Connecter une organisation à ORDU ne signifie pas ouvrir les systèmes de cette organisation à ORDU.

Cela ne signifie pas non plus donner à cette organisation un accès illimité aux informations détenues au sein d'ORDU.

ORDU Connect fournit un canal numérique contrôlé entre des environnements par ailleurs séparés.

Trois portes, avec ORDU Connect au milieu

Il existe une différence architecturale importante entre l'intégration et l'accès.

Une intégration traditionnelle peut exiger qu'une organisation ouvre une porte numérique dans ses systèmes afin qu'un autre système puisse y pénétrer et récupérer les informations dont il a besoin.

Pour la gestion des incidents, en particulier entre organisations, cela crée une question de sécurité inconfortable :

Quelle part de votre environnement numérique devez-vous exposer pour que quelqu'un d'autre puisse obtenir la petite quantité d'informations dont il a réellement besoin ?

ORDU Connect adopte une approche différente.

Imaginez l'architecture comme trois portes dans un couloir.

La première porte protège l'environnement opérationnel de l'organisation externe.

La troisième porte protège l'environnement d'incident d'ORDU.

Et entre les deux se trouve la deuxième porte :

ORDU Connect.

L'organisation externe ne donne pas à ORDU la clé de sa porte.

ORDU ne donne pas à l'organisation externe la clé de l'incident.

Au lieu de cela, les deux parties communiquent par la porte du milieu, contrôlée.

ORDU Connect est le gardien.

L'organisation d'origine décide quelles informations elle souhaite laisser sortir de son environnement et quand elle souhaite les partager.

Ces informations sont délibérément soumises par la porte du milieu.

ORDU Connect authentifie la source, valide et traite la soumission, l'associe à l'incident approprié et met les informations structurées à la disposition d'ORDU Console.

La communication devient :

Organisation → ORDU Connect → ORDU Console

plutôt que :

ORDU → ouverture d'un système externe → recherche d'informations → récupération de données

Cette distinction est importante.

ORDU n'a pas besoin d'autorisation pour parcourir les systèmes d'une autre organisation à la recherche d'informations.

Le tiers n'a pas besoin d'accéder à ORDU Console pour fournir des informations.

Les portes protégeant les deux environnements opérationnels restent fermées.

ORDU Connect fournit la porte du milieu contrôlée par laquelle les informations approuvées peuvent transiter.

L'expéditeur contrôle sa porte

Cela change qui contrôle la relation de partage d'informations.

Avec un système conçu pour extraire des informations d'une autre organisation, le système receveur demande effectivement :

« Que suis-je autorisé à récupérer ? »

Avec ORDU Connect, l'organisation d'origine décide plutôt :

« Que veux-je partager ? »

et :

« Quand veux-je le partager ? »

Ceci est particulièrement important lors de la connexion d'organisations opérationnelles telles que la police, les ambulances et les pompiers.

Leurs systèmes peuvent contenir de grandes quantités d'informations qui ne devraient jamais être exposées en dehors de leur propre périmètre de sécurité.

Se connecter à ORDU ne devrait pas signifier accorder à ORDU l'accès à ces systèmes.

Au lieu de cela, lorsqu'une organisation détermine qu'une mise à jour opérationnelle particulière devrait faire partie de l'image multi-agences, elle peut publier cette information spécifique par la porte du milieu fournie par ORDU Connect.

Tout le reste reste derrière la propre porte de l'organisation d'origine.

Cas d'usage 1 : renseignement spécialisé sans accès à l'incident

Notre première intégration SV3P constitue un bon exemple d'organisation qui n'est pas directement impliquée dans la gestion d'un incident.

Une université modélise l'impact potentiel des tremblements de terre sur les services d'urgence.

L'université ne s'intéresse pas à chaque incident géré via ORDU.

Elle s'intéresse spécifiquement aux incidents impliquant des catastrophes naturelles où la localisation générale de l'incident se situe dans une distance définie d'un tremblement de terre détecté.

Cela crée une relation d'information très spécifique.

L'université a besoin de suffisamment d'informations pour établir :

« Y a-t-il un incident pertinent pour notre modèle sismique ? »

Elle n'a pas besoin de demander :

« Que se passe-t-il à l'intérieur de cet incident ? »

Cette distinction guide l'échange d'informations.

Ne partager que ce qui suffit à établir la pertinence

ORDU Console est l'environnement opérationnel protégé où les équipes autorisées coordonnent un incident.

ORDU Connect fournit la limite contrôlée entre cet environnement et les systèmes externes.

Pour le cas d'usage sismique, l'université n'a pas besoin de la chronologie de l'incident, des décisions opérationnelles, des informations sur le personnel, des plans, des messages ou d'autres informations sensibles détenues au sein de Console.

Elle n'a besoin que des informations limitées nécessaires pour déterminer si un incident relève de son domaine de pertinence.

Dans ce cas, cela pourrait inclure des facteurs tels que la classification de l'incident et une localisation suffisamment généralisée.

Le SV3P peut comparer ces informations limitées à ses propres données :

Incident de catastrophe naturelle → localisation générale → tremblement de terre détecté → seuil de distance → correspondance potentielle

Si ces conditions ne sont pas satisfaites, rien de plus ne doit se produire.

Le fournisseur n'a reçu que le minimum d'informations nécessaire pour établir que l'incident ne le concerne pas.

Si les conditions sont satisfaites, en revanche, le système externe peut effectuer son travail spécialisé.

Laisser les spécialistes rester des spécialistes

Une fois qu'un incident pertinent a été identifié, l'université peut exécuter son modèle d'impact sismique en utilisant ses propres systèmes, ensembles de données et expertise spécialisée.

ORDU n'a pas besoin de reproduire cette capacité.

C'est un autre principe architectural important d'ORDU Connect.

Un système de gestion des incidents n'a pas besoin de devenir un système météorologique, une plateforme de modélisation sismique, une plateforme de surveillance d'infrastructures, un système médical, un système policier et tout autre système spécialisé susceptible de contribuer à un incident.

Ces capacités existent déjà.

L'objectif devrait être de permettre à leurs résultats pertinents de contribuer à l'image opérationnelle lorsque nécessaire.

La modélisation sismique détaillée reste donc au sein de l'environnement de l'université.

Une fois l'analyse terminée, l'université peut choisir de soumettre les résultats pertinents en toute sécurité à ORDU Connect.

Transformer le renseignement externe en information opérationnelle

Les informations reçues par ORDU Connect ne sont pas simplement déversées dans l'incident.

Connect peut traiter la soumission et la convertir en un message structuré qu'ORDU Console comprend.

Ce message peut ensuite être affiché dans le tableau de bord Console pour l'incident concerné.

L'équipe d'incident n'a pas besoin de comprendre le système sous-jacent, les structures de données ou la plateforme de modélisation de l'université.

Elle reçoit les informations dans l'environnement où elle coordonne déjà la réponse.

Le flux devient :

ORDU Connect → informations de pertinence limitées → SV3P

suivi, le cas échéant, par :

SV3P → analyse spécialisée → ORDU Connect → message structuré → ORDU Console

L'organisation externe reste en dehors de l'environnement de gestion des incidents tandis que son renseignement pertinent devient partie de l'image opérationnelle.

Amener la source détaillée à portée de main

Parfois, les informations structurées présentées dans ORDU Console suffiront.

Parfois, les personnes prenant une décision devront approfondir leurs recherches.

Un SV3P peut donc également inclure des liens sécurisés vers les informations détenues au sein de ses propres systèmes.

Dans l'exemple sismique, l'université pourrait maintenir un tableau de bord spécialisé contenant une modélisation, des visualisations, des ensembles de données ou des informations complémentaires bien plus détaillées.

ORDU peut afficher un lien vers cette ressource aux côtés des informations reçues via Connect.

Il est important de noter qu'ORDU ne tente pas de contourner les contrôles de sécurité du fournisseur externe.

La plupart des membres de l'équipe d'incident peuvent ne pas avoir la permission d'accéder à ce tableau de bord universitaire.

C'est attendu.

Ceux qui disposent des identifiants appropriés peuvent suivre le lien et s'authentifier auprès du fournisseur en utilisant les contrôles d'accès déjà en place pour protéger ce système.

Cela devient particulièrement précieux lors de réunions, de discussions et de prises de décision opérationnelles.

Plutôt que quelqu'un doive se rappeler qu'un autre système spécialisé existe, trouver l'application appropriée, localiser la bonne analyse et établir s'il y a accès, la source peut être immédiatement disponible à partir de l'information opérationnelle qui a suscité la discussion.

ORDU fournit le contexte. L'organisation externe garde le contrôle des informations détaillées.

Cas d'usage 2 : connecter des salles de contrôle opérationnelles

La même architecture répond à un problème très différent lorsque le SV3P répond lui-même à l'incident.

Considérez un incident majeur impliquant la police, les ambulances et les pompiers.

Chaque service peut avoir sa propre salle de contrôle, ses propres systèmes, procédures, périmètres de sécurité et responsabilités opérationnelles.

Ils peuvent déjà disposer de capacités matures de gestion des incidents.

ORDU Studio ne devrait pas exiger que ces organisations abandonnent leurs systèmes ni forcer tout le monde impliqué dans un incident multi-agences à travailler via une seule application énorme.

L'exigence est différente.

L'équipe de coordination multi-agences a besoin d'informations pertinentes de la part de ces organisations.

Et ces organisations ont besoin d'un mécanisme sécurisé et fiable par lequel elles peuvent choisir de les fournir.

Le problème du téléphone

Sans intégration numérique, l'échange d'informations entre salles de contrôle peut encore dépendre fortement des appels téléphoniques.

Un opérateur dans une salle de contrôle lit des informations de son système.

Il les communique verbalement à quelqu'un dans une autre salle de contrôle.

La personne recevant l'appel l'écoute et l'enregistre dans un autre système ou journal d'incident.

L'information a effectivement parcouru cette chaîne :

Système → personne → téléphone → personne → système

Considérez ce qui est arrivé aux données.

Elles ont commencé numériquement.

Elles ont été interprétées par une personne.

Elles ont été converties en parole.

Elles ont voyagé par téléphone.

Elles ont été entendues et interprétées par une autre personne.

Elles ont ensuite été reconverties en informations numériques en étant saisies manuellement dans un autre système.

Chacune de ces étapes introduit une opportunité pour l'information d'être mal comprise, abrégée, mal transcrite, mal saisie ou dépouillée de structure et de contexte utiles.

La personne qui parle peut omettre quelque chose dont elle ne réalise pas l'importance.

La personne qui écoute peut mal entendre un chiffre.

Une localisation peut être mal transcrite.

Une heure peut perdre son contexte.

La terminologie utilisée par une organisation peut être interprétée différemment par une autre.

Et une fois que cette information a été saisie dans le journal central de l'incident, la version mal transcrite peut commencer à paraître faisant autorité simplement parce qu'elle est désormais écrite dans le système.

Lors d'un incident majeur, où l'information peut changer rapidement et où les décisions opérationnelles peuvent dépendre de petits détails, cela compte.

L'information numérique doit rester numérique

ORDU Connect offre une autre voie.

Là où les systèmes peuvent s'intégrer numériquement, les informations structurées peuvent être transmises en toute sécurité depuis l'environnement propre d'une organisation vers l'incident multi-agences.

Au lieu de :

Salle de contrôle A → opérateur → téléphone → opérateur → journal d'incident multi-agences

l'information peut voyager :

Salle de contrôle A → ORDU Connect → message structuré → incident multi-agences

L'information qui quitte l'organisation d'origine est celle qui arrive.

Les dates restent des dates.

Les heures restent des heures.

Les localisations restent des localisations.

Les coordonnées restent des coordonnées.

Les références restent des références.

Les identifiants restent des identifiants.

Les champs structurés restent des champs structurés.

L'information n'a pas à être convertie en une description parlée puis reconstruite manuellement à l'autre bout.

Cela ne retire pas les personnes de la gestion des incidents.

Bien au contraire.

Cela permet aux personnes de consacrer davantage de temps à comprendre l'information, à discuter de son importance et à prendre des décisions plutôt qu'à agir comme des interfaces humaines de transcription de données entre systèmes informatiques.

Préserver ce qui a réellement été dit

Il existe un autre avantage important de la communication numérique structurée.

La soumission originale peut être conservée.

Cela signifie qu'il peut y avoir une distinction entre :

ce que l'organisation d'origine a réellement envoyé

et :

comment cette information est ensuite présentée, interprétée ou utilisée.

Ceci est particulièrement important dans un journal d'incident.

Si l'information est communiquée verbalement et saisie manuellement dans un journal, ce journal peut contenir la transcription ou l'interprétation de quelqu'un de l'information originale.

Avec la communication numérique structurée, le message original peut rester partie de la piste d'audit.

Cela crée une provenance plus solide et fournit un enregistrement beaucoup plus clair de la façon dont l'information est entrée dans l'image opérationnelle multi-agences.

Les SV3P choisissent ce qu'ils partagent

Rien de tout cela ne signifie qu'une salle de contrôle police, ambulance, pompiers ou autre intégrée devrait automatiquement diffuser toutes ses informations d'incident vers ORDU.

Cela irait à l'encontre de l'un des principes de sécurité centraux de Connect.

Le SV3P décide ce qu'il partage.

Le SV3P décide quand il le partage.

La police peut détenir des informations inappropriées pour une diffusion plus large.

Les services d'ambulance peuvent détenir des informations confidentielles n'ayant pas leur place dans l'image opérationnelle multi-agences plus large.

Les services d'incendie et de sauvetage peuvent avoir des informations opérationnelles internes détaillées n'ayant pas besoin de quitter leur propre environnement de contrôle.

Une université peut disposer de vastes données de recherche alors qu'une petite partie seulement de son analyse est pertinente pour l'incident.

Connecter ces organisations à ORDU ne crée pas de visibilité illimitée entre les frontières organisationnelles.

Cela crée un mécanisme contrôlé par lequel l'organisation d'origine peut dire :

« Cette information est pertinente pour la réponse multi-agences, et nous choisissons de la partager. »

Cette information peut ensuite transiter en toute sécurité par ORDU Connect.

Tout le reste demeure au sein du propre périmètre de sécurité de l'organisation.

Intégrer ne signifie pas renoncer au contrôle de vos données.

Faire confiance à la source, pas à chaque information

Il existe une autre distinction importante.

Une source vérifiée ne signifie pas que chaque information qu'elle envoie doit automatiquement être traitée comme un fait opérationnel.

ORDU Connect peut établir qu'une soumission provient d'un SV3P reconnu.

Cela fournit la provenance.

Mais provenance et validation opérationnelle sont deux choses différentes.

Un modèle reste un modèle.

Une prédiction reste une prédiction.

Un rapport opérationnel peut être ultérieurement remplacé.

L'information peut être incomplète ou contredire une information reçue d'une autre source.

Maintenir cette distinction devient particulièrement important lors d'incidents complexes impliquant plusieurs organisations.

Le système doit donc être capable de répondre à des questions telles que :

• Qui a fourni cette information ?
• Quand a-t-elle été soumise ?
• Quelle intégration vérifiée l'a soumise ?
• À quel incident était-elle associée ?
• Quelle information a été reçue à l'origine ?
• Comment cette information a-t-elle été présentée dans Console ?
• Existe-t-il un système source contenant plus de détails ?
• Des informations plus récentes ont-elles été reçues depuis ?

Cela crée une chaîne d'informations auditable sans exiger que le fournisseur externe entre dans l'environnement opérationnel.

Le principe de divulgation minimale nécessaire

L'architecture repose sur un principe de sécurité simple :

N'exposer que ce dont une autre organisation a besoin pour remplir son rôle.

Pour le modèle sismique universitaire, cela peut signifier savoir qu'un incident de catastrophe naturelle existe dans une zone générale particulière.

Cela ne nécessite pas de savoir quel personnel intervient, quelles ressources ont été déployées, quelles décisions ont été prises ou ce que d'autres agences ont rapporté.

Pour un service d'urgence, cela peut signifier partager une mise à jour opérationnelle structurée avec l'équipe multi-agences tout en conservant les informations internes sensibles au sein de ses propres systèmes.

Pour l'équipe centrale d'incident, cela peut signifier recevoir le résultat d'un modèle spécialisé sans se voir accorder l'accès à l'ensemble de la plateforme du fournisseur.

Chaque organisation reste responsable de la protection de ses propres informations.

ORDU Connect fournit l'échange d'informations contrôlé entre elles.

Communication sécurisée sans ouvrir le réseau

C'est finalement ce qu'ORDU Connect est conçu pour fournir :

une limite de communication sécurisée, pas une limite d'intégration ouverte.

L'objectif n'est pas de créer un accès toujours plus profond entre organisations.

Ce n'est pas non plus de créer un système central capable d'atteindre chaque organisation connectée.

Et ce n'est pas d'exiger que chaque organisation contribuant des informations devienne utilisatrice d'ORDU Console.

L'objectif est de créer une voie de confiance par laquelle les organisations peuvent échanger exactement les informations requises pour coordonner un incident.

Repensez à ces trois portes.

Derrière la première se trouve l'organisation externe et les informations qu'elle protège.

Derrière la troisième se trouve l'environnement d'incident ORDU et l'image opérationnelle sensible qu'il protège.

Entre elles se trouve ORDU Connect.

La porte du milieu existe pour qu'aucune des deux autres n'ait à être ouverte.

ORDU Connect devient le gardien entre des environnements opérationnels par ailleurs séparés.

Il sait qui communique.

Il contrôle la route vers ORDU.

Il peut valider ce qui est reçu.

Il préserve la structure et la provenance des informations échangées.

Il associe ces informations à l'incident approprié.

Et, surtout, il permet aux environnements opérationnels de chaque côté de rester protégés.

Vous n'avez pas à ouvrir vos systèmes pour participer à la coordination numérique d'un incident. Vous n'avez qu'à faire passer les informations que vous choisissez de partager par une porte du milieu contrôlée.

De l'intégration de systèmes à la coordination de l'information

Cela change notre façon de penser l'interopérabilité dans la gestion des incidents.

L'objectif n'est pas de mettre chaque organisation dans un seul système énorme.

Ce n'est pas de donner à tout le monde accès aux données de tout le monde.

Et ce n'est pas simplement de connecter autant d'API que possible.

L'objectif est de permettre à la bonne information de circuler en toute sécurité entre les organisations, sous une forme structurée, au moment où elle devient opérationnellement utile.

Parfois, cela signifie apporter un renseignement spécialisé d'une université ou d'un organisme de recherche dans l'image opérationnelle.

Parfois, cela signifie permettre à la police, aux ambulances, aux pompiers ou à une autre organisation intervenante d'envoyer une mise à jour opérationnelle structurée depuis sa propre salle de contrôle directement dans l'incident multi-agences.

Parfois, cela signifie fournir aux membres autorisés de l'équipe d'incident une voie sécurisée vers des informations plus détaillées détenues au sein d'un système externe spécialisé.

Dans chaque cas, le principe reste le même.

L'organisation d'origine conserve le contrôle de ce qu'elle partage et quand.

L'organisation réceptrice n'a pas besoin d'un accès illimité au système d'origine.

L'organisation externe n'a pas besoin d'un accès illimité à l'incident central.

L'information reste numérique et structurée plutôt que d'être inutilement traduite d'un système en parole puis reconvertie dans un autre système.

Et ORDU Connect se situe entre ces environnements comme la porte du milieu contrôlée.

ORDU Console reste l'environnement protégé dans lequel l'incident multi-agences est coordonné.

ORDU Connect fournit le pont contrôlé par lequel les organisations et systèmes de confiance peuvent contribuer à cette image opérationnelle.

Parce qu'une coordination multi-agences efficace dépend du partage d'informations.

Cela ne devrait pas exiger d'ouvrir vos portes numériques.

Et lorsque l'information existe déjà numériquement, cela ne devrait pas dépendre de la lire au téléphone en espérant qu'elle soit correctement notée à l'autre bout.