Bezpečné propojení třetích stran s aktivním incidentem bez jeho odhalení

Velké incidenty jen zřídka existují v informačních hranicích jediné organizace.

Policie, záchranná služba a hasiči mohou každý řídit vlastní zásah prostřednictvím svých vlastních operačních středisek a systémů pro řízení incidentů. Totéž mohou dělat místní samosprávy, nemocnice, provozovatelé infrastruktury a další subjekty.

Zároveň mohou cenné informace pocházet od organizací, které se na řízení incidentu vůbec nepodílejí.

Univerzity, výzkumné organizace, systémy environmentálního monitoringu, poskytovatelé infrastruktury a specializované modelovací služby mohou disponovat informacemi, které by mohly podstatně zlepšit situační přehled.

Jde o velmi odlišné vztahy, ale všechny vytvářejí stejný problém:

Jak umožnit důvěryhodným třetím stranám přispívat informacemi do živého vícerezortního incidentu, aniž by získaly zbytečný přístup do centrálního systému řízení incidentů, a aniž by musely na oplátku otevřít vlastní systémy?

To je jeden z problémů, které řešíme pomocí ORDU Studio a konkrétně ORDU Connect.

Sdílení informací nevyžaduje sdílený přístup

Je lákavé chápat vícerezortní sdílení informací jako otázku oprávnění.

Přidat každou zúčastněnou organizaci jako uživatele. Vytvořit jim účty. Omezit, co mohou vidět.

Nebo k problému přistoupit z opačné strany a připojit se přímo k systémům každé organizace, přičemž centrální platforma získá oprávnění získávat potřebné informace.

Oba přístupy mohou potenciálně rozšířit bezpečnostní hranici.

Aktivní incident může obsahovat vysoce citlivé provozní informace: interní rozhodnutí, údaje o personálu, lokace, zranitelná místa, komunikaci, plány zásahu a informace poskytnuté jinými organizacemi.

Stejně tak systémy provozované policií, záchrannou službou, hasiči, nemocnicemi, provozovateli infrastruktury, univerzitami a dalšími organizacemi mohou obsahovat informace, které vůbec nemají důvod být zpřístupněny centrální vícerezortní platformě.

Požadavek na sdílení jedné informace by se neměl proměnit v požadavek na odhalení celého systému.

ORDU proto chápe poskytování informací, přijímání informací a přístup do systémů jiné organizace jako oddělené koncepty.

Organizace může přispívat do vícerezortního operačního obrazu, aniž by se stala uživatelem ORDU Console.

ORDU může od organizace přijímat informace, aniž by získal přístup do jejích interních systémů.

Toto oddělení je základem architektury ORDU Connect.

Zabezpečení ověření poskytovatelé třetích stran

V rámci ORDU Studio označujeme důvěryhodné externí poskytovatele informací jako Zabezpečené ověřené poskytovatele třetích stran, neboli SV3P.

SV3P může být operační organizace, například policie, záchranná služba nebo hasiči, provozující vlastní operační středisko pro řízení incidentů.

Může to být nemocnice, místní samospráva, energetická společnost nebo provozovatel infrastruktury.

Stejně tak to může být organizace, která nemá při koordinaci incidentu vůbec žádnou roli, ale provozuje specializovaný systém, datovou sadu nebo analytickou schopnost, jež se za určitých okolností stává relevantní.

Dobrým příkladem je univerzita provozující model dopadu zemětřesení.

Tyto organizace mají s incidentem velmi odlišné vztahy, takže ORDU Connect nemůže předpokládat, že by každý SV3P měl mít stejnou úroveň přístupu nebo si vyměňovat stejné informace.

Nejdůležitější je:

SV3P sám řídí, jaké informace sdílí a kdy je sdílí.

Propojení organizace s ORDU neznamená otevření systémů dané organizace vůči ORDU.

Neznamená to ani poskytnutí neomezeného přístupu této organizaci k informacím uloženým v rámci ORDU.

ORDU Connect poskytuje řízený digitální kanál mezi jinak oddělenými prostředími.

Tři dveře, ORDU Connect uprostřed

Existuje důležitý architektonický rozdíl mezi integrací a přístupem.

Tradiční integrace může vyžadovat, aby jedna organizace otevřela digitální dveře do svých systémů, aby do nich mohl jiný systém vstoupit a získat potřebné informace.

Při řízení incidentů, zejména napříč organizačními hranicemi, to vyvolává nepříjemnou bezpečnostní otázku:

Jak velkou část svého digitálního prostředí musíte odhalit, aby někdo jiný mohl získat malé množství informací, které skutečně potřebuje?

ORDU Connect volí odlišný přístup.

Představte si architekturu jako troje dveře na chodbě.

První dveře chrání provozní prostředí externí organizace.

Třetí dveře chrání prostředí incidentu ORDU.

A mezi nimi jsou druhé dveře:

ORDU Connect.

Externí organizace nedává ORDU klíč od svých dveří.

ORDU nedává externí organizaci klíč od incidentu.

Místo toho obě strany komunikují prostřednictvím řízených prostředních dveří.

ORDU Connect je strážce.

Zdrojová organizace rozhoduje, jaké informace chce nechat vystoupit ze svého prostředí a kdy je chce sdílet.

Tyto informace jsou záměrně předávány prostřednictvím prostředních dveří.

ORDU Connect ověří zdroj, ověří a zpracuje podání, přiřadí je k příslušnému incidentu a zpřístupní strukturované informace pro ORDU Console.

Komunikace se tak stává:

Organizace → ORDU Connect → ORDU Console

místo:

ORDU → otevření externího systému → vyhledávání informací → získání dat

Na tomto rozdílu záleží.

ORDU nepotřebuje oprávnění procházet systémy jiné organizace a hledat v nich informace.

Třetí strana nepotřebuje přístup do ORDU Console, aby mohla informace předat.

Dveře chránící obě provozní prostředí zůstávají zavřené.

ORDU Connect poskytuje řízené prostřední dveře, jimiž mohou procházet schválené informace.

Odesílatel řídí své vlastní dveře

Tím se mění, kdo řídí vztah v oblasti sdílení informací.

U systému navrženého pro získávání informací z jiné organizace se přijímající systém v podstatě ptá:

„Co smím získat?“

U ORDU Connect naopak rozhoduje zdrojová organizace:

„Co chci sdílet?“

a:

„Kdy to chci sdílet?“

To je obzvláště důležité při propojování operačních organizací, jako je policie, záchranná služba a hasiči.

Jejich systémy mohou obsahovat velké množství informací, které by nikdy neměly být odhaleny mimo jejich vlastní bezpečnostní hranici.

Propojení s ORDU by nemělo znamenat, že ORDU získá přístup do těchto systémů.

Místo toho, když organizace usoudí, že konkrétní provozní aktualizace by měla být součástí vícerezortního obrazu, může tuto konkrétní informaci zveřejnit prostřednictvím prostředních dveří poskytovaných ORDU Connect.

Všechno ostatní zůstává za vlastními dveřmi zdrojové organizace.

Případ použití 1: Specializované poznatky bez přístupu k incidentu

Naše první integrace SV3P je dobrým příkladem organizace, která se přímo nepodílí na řízení incidentu.

Univerzita modeluje potenciální dopad zemětřesení na záchranné služby.

Univerzitu nezajímá každý incident řízený prostřednictvím ORDU.

Zajímají ji konkrétně incidenty spojené s přírodními katastrofami, u nichž se obecná lokalita incidentu nachází v definované vzdálenosti od zaznamenaného zemětřesení.

Tím vzniká velmi specifický informační vztah.

Univerzita potřebuje dostatek informací, aby zjistila:

„Existuje incident relevantní pro náš model zemětřesení?“

Nepotřebuje se ptát:

„Co se v rámci tohoto incidentu děje?“

Tento rozdíl určuje podobu výměny informací.

Sdílejte jen tolik, kolik stačí k určení relevance

ORDU Console je chráněné provozní prostředí, v němž oprávněné týmy koordinují incident.

ORDU Connect poskytuje řízenou hranici mezi tímto prostředím a externími systémy.

Pro případ zemětřesení univerzita nepotřebuje časovou osu incidentu, provozní rozhodnutí, informace o personálu, plány, zprávy ani další citlivé informace uložené v Console.

Potřebuje pouze omezené informace nezbytné k určení, zda incident spadá do jejího okruhu zájmu.

V tomto případě by to mohlo zahrnovat faktory jako klasifikaci incidentu a dostatečně zobecněnou lokalitu.

SV3P může tyto omezené informace porovnat s vlastními daty:

Incident přírodní katastrofy → obecná lokalita → zaznamenané zemětřesení → prahová vzdálenost → možná shoda

Pokud tyto podmínky nejsou splněny, nemusí se dít nic dalšího.

Poskytovatel obdržel jen minimum informací nutné k tomu, aby zjistil, že incident pro něj není relevantní.

Pokud jsou podmínky splněny, může externí systém provést svou specializovanou práci.

Nechte specialisty specialisty

Jakmile je relevantní incident identifikován, univerzita může spustit svůj model dopadu zemětřesení za použití vlastních systémů, datových sad a specializovaných odborných znalostí.

ORDU nepotřebuje tuto schopnost duplikovat.

Jde o další důležitý architektonický princip stojící za ORDU Connect.

Systém pro řízení incidentů se nemusí stát meteorologickým systémem, platformou pro modelování zemětřesení, platformou pro monitorování infrastruktury, zdravotnickým systémem, policejním systémem ani žádným jiným specializovaným systémem, který by mohl k incidentu přispět.

Tyto schopnosti už existují.

Cílem by mělo být umožnit, aby jejich relevantní výstupy přispívaly do operačního obrazu, kdykoli je to potřeba.

Podrobné modelování zemětřesení proto zůstává v prostředí univerzity.

Jakmile je analýza dokončena, univerzita se může rozhodnout bezpečně předat relevantní výsledky ORDU Connect.

Proměna externích poznatků na provozní informace

Informace přijaté ORDU Connect nejsou jednoduše vloženy do incidentu bez dalšího zpracování.

Connect může podání zpracovat a převést je na strukturovanou zprávu, které ORDU Console rozumí.

Tato zpráva pak může být zobrazena na dashboardu Console pro příslušný incident.

Tým řešící incident nemusí rozumět podkladovému systému univerzity, jejím datovým strukturám ani modelovací platformě.

Informace obdrží v prostředí, kde už koordinuje zásah.

Tok se stává:

ORDU Connect → omezená informace o relevanci → SV3P

a případně následně:

SV3P → specializovaná analýza → ORDU Connect → strukturovaná zpráva → ORDU Console

Externí organizace zůstává mimo prostředí řízení incidentu, zatímco její relevantní poznatky se stávají součástí operačního obrazu.

Zpřístupnění podrobného zdroje

Někdy bude strukturovaná informace zobrazená v ORDU Console dostačující.

Někdy budou lidé rozhodující o dalším postupu potřebovat podrobnější zkoumání.

SV3P proto může také přidat zabezpečené odkazy zpět na informace uložené ve svých vlastních systémech.

V příkladu se zemětřesením by univerzita mohla udržovat specializovaný dashboard obsahující výrazně podrobnější modelování, vizualizace, datové sady nebo podpůrné informace.

ORDU může zobrazit odkaz na tento zdroj vedle informací přijatých prostřednictvím Connect.

Je důležité, že se ORDU nepokouší obejít bezpečnostní kontroly externího poskytovatele.

Většina členů týmu řešícího incident nemusí mít oprávnění k přístupu na tento univerzitní dashboard.

To se očekává.

Ti, kdo mají příslušné přihlašovací údaje, mohou odkaz otevřít a ověřit se u poskytovatele pomocí přístupových kontrol, které daný systém již chrání.

To je obzvláště cenné během schůzek, diskusí a operativního rozhodování.

Namísto toho, aby si někdo musel vzpomenout, že existuje další specializovaný systém, najít správnou aplikaci, dohledat správnou analýzu a zjistit, zda k ní má přístup, může být zdroj okamžitě dostupný přímo z provozní informace, která diskusi vyvolala.

ORDU poskytuje kontext. Externí organizace si ponechává kontrolu nad podrobnými informacemi.

Případ použití 2: Propojení operačních středisek

Stejná architektura řeší velmi odlišný problém, když je SV3P sám tím, kdo na incident reaguje.

Představte si velký incident zahrnující policii, záchrannou službu a hasiče.

Každá služba může mít vlastní operační středisko, systémy, postupy, bezpečnostní hranice a provozní odpovědnosti.

Mohou už mít vlastní vyspělé schopnosti řízení incidentů.

ORDU Studio by nemělo vyžadovat, aby tyto organizace opustily své systémy, ani nutit všechny zúčastněné ve vícerezortním incidentu, aby pracovali v jedné obrovské aplikaci.

Požadavek je jiný.

Vícerezortní koordinační tým potřebuje od těchto organizací relevantní informace.

A tyto organizace potřebují bezpečný, spolehlivý mechanismus, kterým se mohou rozhodnout je poskytnout.

Problém telefonu

Bez digitální integrace může výměna informací mezi operačními středisky stále silně záviset na telefonních hovorech.

Operátor v jednom operačním středisku přečte informace ze svého systému.

Sdělí je ústně někomu v jiném operačním středisku.

Osoba přijímající hovor jej vyslechne a zaznamená do jiného systému nebo deníku incidentu.

Informace tak fakticky prošla tímto řetězcem:

Systém → člověk → telefon → člověk → systém

Zamyslete se, co se s daty stalo.

Začala digitálně.

Byla interpretována člověkem.

Byla převedena do řeči.

Prošla telefonem.

Byla vyslechnuta a interpretována jiným člověkem.

Poté byla ručním zadáním do jiného systému opět převedena na digitální informaci.

Každá z těchto fází přináší příležitost k tomu, aby informace byla nesprávně pochopena, zkrácena, chybně přepsána, špatně zapsána nebo zbavena užitečné struktury a kontextu.

Mluvčí může opomenout něco, o čem si neuvědomuje, že je to důležité.

Naslouchající může špatně zaslechnout číslo.

Lokace může být chybně přepsána.

Čas může ztratit svůj kontext.

Terminologie používaná jednou organizací může být jinou organizací vyložena odlišně.

A jakmile je tato informace zapsána do centrálního deníku incidentu, nesprávně přepsaná verze může začít působit jako autoritativní, prostě proto, že je nyní zapsaná v systému.

Během velkého incidentu, kdy se informace mohou rychle měnit a provozní rozhodnutí mohou záviset na malých detailech, na tom záleží.

Digitální informace by měla zůstat digitální

ORDU Connect nabízí jinou cestu.

Tam, kde se systémy mohou digitálně integrovat, lze strukturované informace bezpečně přenášet z vlastního prostředí organizace do vícerezortního incidentu.

Místo:

Operační středisko A → operátor → telefon → operátor → vícerezortní deník incidentu

může informace putovat takto:

Operační středisko A → ORDU Connect → strukturovaná zpráva → vícerezortní incident

Informace, která opouští zdrojovou organizaci, je totožná s tou, která dorazí.

Data zůstávají daty.

Časy zůstávají časy.

Lokace zůstávají lokacemi.

Souřadnice zůstávají souřadnicemi.

Reference zůstávají referencemi.

Identifikátory zůstávají identifikátory.

Strukturovaná pole zůstávají strukturovanými poli.

Informace nemusí být převedena do mluveného popisu a poté ručně rekonstruována na druhém konci.

To lidi z řízení incidentů nevylučuje.

Právě naopak.

Umožňuje lidem věnovat více času pochopení informací, diskusi o jejich významu a rozhodování, místo aby fungovali jako lidská rozhraní pro přepis dat mezi počítačovými systémy.

Zachovejte to, co bylo skutečně řečeno

Strukturovaná digitální komunikace přináší ještě jednu důležitou výhodu.

Původní podání lze uchovat.

To znamená, že lze rozlišit mezi:

tím, co zdrojová organizace skutečně odeslala

a:

tím, jak je tato informace následně prezentována, interpretována nebo jak se podle ní jedná.

To je obzvláště důležité v deníku incidentu.

Pokud je informace sdělena ústně a ručně zapsána do deníku, může deník obsahovat něčí přepis nebo interpretaci původní informace.

U strukturované digitální komunikace může zůstat součástí auditní stopy původní zpráva.

To vytváří silnější prokazatelnost původu a mnohem jasnější záznam o tom, jak se informace dostala do vícerezortního operačního obrazu.

SV3P si volí, co sdílí

Nic z toho neznamená, že by integrované operační středisko policie, záchranné služby, hasičů nebo jiné organizace mělo automaticky streamovat všechny své informace o incidentu do ORDU.

To by popřelo jeden z hlavních bezpečnostních principů, na kterých Connect stojí.

SV3P rozhoduje, co sdílí.

SV3P rozhoduje, kdy to sdílí.

Policie může mít informace, které jsou nevhodné pro širší distribuci.

Záchranná služba může mít důvěrné informace, které nemají místo v širším vícerezortním operačním obraze.

Hasičský a záchranný sbor může mít podrobné interní provozní informace, které nepotřebují opustit jeho vlastní řídicí prostředí.

Univerzita může mít rozsáhlá výzkumná data, přičemž pro incident je relevantní jen malá část její analýzy.

Propojení těchto organizací s ORDU nevytváří neomezenou viditelnost napříč organizačními hranicemi.

Vytváří řízený mechanismus, jehož prostřednictvím může zdrojová organizace říct:

„Tato informace je relevantní pro vícerezortní zásah a rozhodli jsme se ji sdílet.“

Tato informace pak může bezpečně projít přes ORDU Connect.

Všechno ostatní zůstává v rámci vlastní bezpečnostní hranice organizace.

Integrace neznamená vzdát se kontroly nad svými daty.

Důvěřujte zdroji, ne každé jednotlivé informaci

Existuje ještě jeden důležitý rozdíl.

Ověřený zdroj neznamená, že by každá informace, kterou odešle, měla být automaticky považována za provozní fakt.

ORDU Connect může ověřit, že podání pochází od uznaného SV3P.

To poskytuje prokazatelnost původu.

Prokazatelnost původu a provozní ověření jsou ale odlišné věci.

Model zůstává modelem.

Předpověď zůstává předpovědí.

Provozní hlášení může být později nahrazeno novějším.

Informace může být neúplná nebo v rozporu s informací přijatou z jiného zdroje.

Udržet toto rozlišení je obzvláště důležité při složitých incidentech zapojujících více organizací.

Systém by proto měl umět odpovědět na otázky, jako jsou:

• Kdo tuto informaci poskytl?
• Kdy byla odeslána?
• Která ověřená integrace ji odeslala?
• S jakým incidentem byla spojena?
• Jaká informace byla původně přijata?
• Jak byla tato informace prezentována v Console?
• Existuje zdrojový systém obsahující další podrobnosti?
• Byly od té doby přijaty novější informace?

Tím vzniká auditovatelný informační řetězec, aniž by externí poskytovatel musel vstoupit do provozního prostředí.

Princip minimálně nutného zpřístupnění

Architektura vychází z jednoduchého bezpečnostního principu:

Odhalovat pouze to, co jiná organizace potřebuje k plnění své role.

U univerzitního modelu zemětřesení to může znamenat vědět, že v konkrétní obecné oblasti existuje incident spojený s přírodní katastrofou.

Nevyžaduje to vědět, který personál zasahuje, jaké zdroje byly nasazeny, jaká rozhodnutí byla učiněna nebo co nahlásily jiné agentury.

Pro záchrannou službu to může znamenat sdílet strukturovanou provozní aktualizaci s vícerezortním týmem a přitom si ponechat citlivé interní informace ve vlastních systémech.

Pro centrální tým řešící incident to může znamenat obdržet výstup specializovaného modelu, aniž by získal přístup k celé platformě poskytovatele.

Každá organizace zůstává odpovědná za ochranu svých vlastních informací.

ORDU Connect poskytuje řízenou výměnu informací mezi nimi.

Bezpečná komunikace bez otevření sítě

To je nakonec to, k čemu je ORDU Connect navržen:

bezpečná komunikační hranice, nikoli otevřená integrační hranice.

Cílem není vytvářet stále hlubší a hlubší přístup mezi organizacemi.

Cílem není vytvořit centrální systém schopný dosáhnout do každé připojené organizace.

A cílem není ani vyžadovat, aby se každá organizace přispívající informacemi stala uživatelem ORDU Console.

Cílem je vytvořit důvěryhodnou cestu, jejímž prostřednictvím si organizace mohou vyměňovat přesně ty informace, které jsou potřeba ke koordinaci incidentu.

Vzpomeňte si znovu na oněch troje dveře.

Za prvními je externí organizace a informace, které chrání.

Za třetími je prostředí incidentu ORDU a citlivý operační obraz, který chrání.

Mezi nimi je ORDU Connect.

Prostřední dveře existují proto, aby žádné z ostatních dvou nemusely být otevřeny.

ORDU Connect se stává strážcem mezi jinak oddělenými provozními prostředími.

Ví, kdo komunikuje.

Řídí cestu do ORDU.

Umí ověřit, co přijímá.

Zachovává strukturu a prokazatelnost původu vyměňovaných informací.

Přiřazuje tyto informace k příslušnému incidentu.

A co je klíčové, umožňuje, aby provozní prostředí na obou stranách zůstala chráněna.

Nemusíte otevírat své systémy, abyste se mohli podílet na digitální koordinaci incidentu. Stačí, když informace, které se rozhodnete sdílet, provedete řízenými prostředními dveřmi.

Od integrace systémů ke koordinaci informací

To mění způsob, jakým přemýšlíme o interoperabilitě při řízení incidentů.

Cílem není vložit každou organizaci do jednoho obrovského systému.

Cílem není dát všem přístup k datům všech ostatních.

A cílem není ani prostě propojit co nejvíce API.

Cílem je umožnit, aby ta správná informace bezpečně proudila mezi organizacemi ve strukturované podobě ve chvíli, kdy se stává provozně užitečnou.

Někdy to znamená přinést specializované poznatky univerzity nebo výzkumné organizace do operačního obrazu.

Někdy to znamená umožnit policii, záchranné službě, hasičům nebo jiné zasahující organizaci odeslat strukturovanou provozní aktualizaci přímo z vlastního operačního střediska do vícerezortního incidentu.

Někdy to znamená poskytnout oprávněným členům týmu řešícího incident bezpečnou cestu zpět k podrobnějším informacím uloženým ve specializovaném externím systému.

Ve všech případech zůstává princip stejný.

Zdrojová organizace si ponechává kontrolu nad tím, co a kdy sdílí.

Přijímající organizace nepotřebuje neomezený přístup ke zdrojovému systému.

Externí organizace nepotřebuje neomezený přístup do centrálního incidentu.

Informace zůstává digitální a strukturovaná, místo aby byla zbytečně převáděna ze systému do řeči a zpět do jiného systému.

A ORDU Connect stojí mezi těmito prostředími jako řízené prostřední dveře.

ORDU Console zůstává chráněným prostředím, v němž je koordinován vícerezortní incident.

ORDU Connect poskytuje řízený most, jehož prostřednictvím mohou důvěryhodné organizace a systémy přispívat do tohoto operačního obrazu.

Protože efektivní vícerezortní koordinace závisí na sdílení informací.

Nemělo by to vyžadovat otevření vašich digitálních dveří.

A pokud informace už existuje digitálně, nemělo by se spoléhat na to, že ji přečtete po telefonu a budete doufat, že si ji na druhém konci správně zapíší.