Bezpieczne łączenie stron trzecich z aktywnym incydentem bez ujawniania incydentu

Poważne incydenty rzadko mieszczą się w granicach informacyjnych jednej organizacji.

Policja, pogotowie ratunkowe i straż pożarna mogą każde zarządzać własną reakcją za pomocą własnych centrów dowodzenia i systemów zarządzania incydentami. Władze lokalne, szpitale, operatorzy infrastruktury i inne agencje mogą robić to samo.

Jednocześnie cenne informacje mogą pochodzić od organizacji, które w ogóle nie są zaangażowane w prowadzenie incydentu.

Uniwersytety, organizacje badawcze, systemy monitoringu środowiskowego, dostawcy infrastruktury i wyspecjalizowane usługi modelowania mogą posiadać informacje, które mogłyby istotnie poprawić świadomość sytuacyjną.

To bardzo różne relacje, ale tworzą one wspólny problem:

Jak umożliwić zaufanym stronom trzecim wnoszenie informacji do aktywnego, wieloagencyjnego incydentu bez udzielania im niepotrzebnego dostępu do centralnego systemu zarządzania incydentami i bez wymagania od nich otwarcia własnych systemów w zamian?

To jeden z problemów, które rozwiązujemy za pomocą ORDU Studio, a konkretnie ORDU Connect.

Udostępnianie informacji nie wymaga wspólnego dostępu

Kusi, by myśleć o wieloagencyjnym udostępnianiu informacji jako o problemie uprawnień.

Dodać każdą uczestniczącą organizację jako użytkownika. Nadać konta. Ograniczyć to, co mogą zobaczyć.

Albo podejść do problemu z przeciwnej strony i połączyć się bezpośrednio z systemami każdej organizacji, dając centralnej platformie uprawnienia do pobierania potrzebnych informacji.

Oba podejścia potencjalnie rozszerzają granicę bezpieczeństwa.

Aktywny incydent może zawierać wysoce wrażliwe informacje operacyjne: wewnętrzne decyzje, dane personelu, lokalizacje, słabe punkty, komunikację, plany reagowania oraz informacje dostarczone przez inne organizacje.

Podobnie systemy obsługiwane przez policję, pogotowie, straż pożarną, szpitale, dostawców infrastruktury, uniwersytety i inne organizacje mogą zawierać informacje, które nie mają absolutnie żadnego powodu, by być ujawniane centralnej platformie wieloagencyjnej.

Konieczność udostępnienia jednej informacji nie powinna stawać się koniecznością ujawnienia całego systemu.

ORDU traktuje zatem wnoszenie informacji, otrzymywanie informacji oraz dostęp do systemów innej organizacji jako odrębne pojęcia.

Organizacja może wnosić swój wkład do wieloagencyjnego obrazu operacyjnego, nie stając się użytkownikiem ORDU Console.

ORDU może otrzymywać informacje od organizacji bez uzyskiwania dostępu do jej wewnętrznych systemów.

Ten podział jest fundamentalny dla architektury ORDU Connect.

Zabezpieczeni zweryfikowani dostawcy zewnętrzni

W ramach ORDU Studio zaufanych zewnętrznych dostawców informacji określamy jako Secured Verified Third-Party Providers, czyli SV3P.

SV3P może być organizacją operacyjną, taką jak policja, pogotowie lub straż pożarna, prowadzącą własne centrum dowodzenia incydentem.

Może to być szpital, władza lokalna, spółka użyteczności publicznej lub operator infrastruktury.

Równie dobrze może to być organizacja niemająca żadnej roli w koordynacji incydentu, ale obsługująca wyspecjalizowany system, zbiór danych lub zdolność analityczną, która staje się istotna w określonych okolicznościach.

Dobrym przykładem jest uniwersytet prowadzący model wpływu trzęsień ziemi.

Te organizacje mają bardzo różne relacje z incydentem, więc ORDU Connect nie może zakładać, że każdy SV3P powinien mieć taki sam poziom dostępu lub wymieniać takie same informacje.

Co najważniejsze:

To SV3P kontroluje, jakie informacje udostępnia i kiedy je udostępnia.

Połączenie organizacji z ORDU nie oznacza otwarcia systemów tej organizacji dla ORDU.

Nie oznacza też przyznania tej organizacji nieograniczonego dostępu do informacji przechowywanych w ORDU.

ORDU Connect zapewnia kontrolowany kanał cyfrowy między odrębnymi środowiskami.

Trzy drzwi, a pośrodku ORDU Connect

Istnieje ważna różnica architektoniczna między integracją a dostępem.

Tradycyjna integracja może wymagać, aby jedna organizacja otworzyła cyfrowe drzwi do swoich systemów, tak aby inny system mógł do nich sięgnąć i pobrać potrzebne informacje.

W przypadku zarządzania incydentami, szczególnie ponad granicami organizacyjnymi, rodzi to niewygodne pytanie o bezpieczeństwo:

Jak dużą część swojego środowiska cyfrowego musisz ujawnić, aby ktoś inny mógł uzyskać niewielką ilość informacji, których faktycznie potrzebuje?

ORDU Connect przyjmuje inne podejście.

Wyobraźmy sobie architekturę jako troje drzwi w korytarzu.

Pierwsze drzwi chronią środowisko operacyjne organizacji zewnętrznej.

Trzecie drzwi chronią środowisko incydentu ORDU.

A pomiędzy nimi znajdują się drugie drzwi:

ORDU Connect.

Organizacja zewnętrzna nie daje ORDU klucza do swoich drzwi.

ORDU nie daje organizacji zewnętrznej klucza do incydentu.

Zamiast tego obie strony komunikują się poprzez kontrolowane drzwi środkowe.

ORDU Connect jest strażnikiem.

Organizacja źródłowa decyduje, jakie informacje chce wypuścić ze swojego środowiska i kiedy chce je udostępnić.

Informacje te są celowo przesyłane przez drzwi środkowe.

ORDU Connect uwierzytelnia źródło, waliduje i przetwarza zgłoszenie, przypisuje je do odpowiedniego incydentu oraz udostępnia ustrukturyzowaną informację w ORDU Console.

Komunikacja przebiega następująco:

Organizacja → ORDU Connect → ORDU Console

a nie:

ORDU → otwarty system zewnętrzny → wyszukiwanie informacji → pobranie danych

Ta różnica ma znaczenie.

ORDU nie potrzebuje pozwolenia na przeszukiwanie systemów innej organizacji w poszukiwaniu informacji.

Strona trzecia nie potrzebuje dostępu do ORDU Console, aby dostarczyć informacje.

Drzwi chroniące oba środowiska operacyjne pozostają zamknięte.

ORDU Connect zapewnia kontrolowane drzwi środkowe, przez które mogą przechodzić zatwierdzone informacje.

Nadawca kontroluje swoje drzwi

To zmienia to, kto kontroluje relację udostępniania informacji.

W systemie zaprojektowanym wokół pobierania informacji od innej organizacji system odbierający zasadniczo pyta:

„Co wolno mi pobrać?”

W przypadku ORDU Connect to organizacja źródłowa decyduje:

„Czym chcę się podzielić?”

oraz:

„Kiedy chcę się tym podzielić?”

Jest to szczególnie istotne przy łączeniu organizacji operacyjnych, takich jak policja, pogotowie i straż pożarna.

Ich systemy mogą zawierać duże ilości informacji, które nigdy nie powinny zostać ujawnione poza ich własną granicą bezpieczeństwa.

Połączenie z ORDU nie powinno oznaczać przyznania ORDU dostępu do tych systemów.

Zamiast tego, gdy organizacja uzna, że konkretna aktualizacja operacyjna powinna stać się częścią obrazu wieloagencyjnego, może opublikować tę konkretną informację przez drzwi środkowe zapewniane przez ORDU Connect.

Wszystko inne pozostaje za własnymi drzwiami organizacji źródłowej.

Przypadek użycia pierwszy: wyspecjalizowane informacje bez dostępu do incydentu

Nasza pierwsza integracja SV3P stanowi dobry przykład organizacji, która nie jest bezpośrednio zaangażowana w zarządzanie incydentem.

Uniwersytet modeluje potencjalny wpływ trzęsień ziemi na służby ratunkowe.

Uniwersytet nie jest zainteresowany każdym incydentem zarządzanym przez ORDU.

Interesują go konkretnie incydenty związane z klęskami żywiołowymi, w których ogólna lokalizacja incydentu znajduje się w określonej odległości od wykrytego trzęsienia ziemi.

To tworzy bardzo konkretną relację informacyjną.

Uniwersytet potrzebuje wystarczających informacji, by ustalić:

„Czy istnieje incydent istotny dla naszego modelu trzęsień ziemi?”

Nie musi pytać:

„Co dzieje się wewnątrz tego incydentu?”

Ta różnica napędza wymianę informacji.

Udostępniaj tylko tyle, ile potrzeba, by ustalić istotność

ORDU Console to chronione środowisko operacyjne, w którym upoważnione zespoły koordynują incydent.

ORDU Connect zapewnia kontrolowaną granicę między tym środowiskiem a systemami zewnętrznymi.

W przypadku scenariusza trzęsienia ziemi uniwersytet nie potrzebuje osi czasu incydentu, decyzji operacyjnych, informacji o personelu, planów, wiadomości ani innych wrażliwych informacji przechowywanych w Console.

Potrzebuje jedynie ograniczonych informacji niezbędnych do ustalenia, czy incydent mieści się w jego obszarze zainteresowania.

W tym przypadku mogą to być takie czynniki jak klasyfikacja incydentu oraz wystarczająco uogólniona lokalizacja.

SV3P może porównać te ograniczone informacje z własnymi danymi:

Incydent klęski żywiołowej → ogólna lokalizacja → wykryte trzęsienie ziemi → próg odległości → potencjalne dopasowanie

Jeśli te warunki nie są spełnione, nic więcej nie musi się wydarzyć.

Dostawca otrzymał jedynie minimalną ilość informacji potrzebną do ustalenia, że incydent nie jest dla niego istotny.

Jeśli jednak warunki są spełnione, system zewnętrzny może wykonać swoją specjalistyczną pracę.

Niech specjaliści pozostaną specjalistami

Po zidentyfikowaniu istotnego incydentu uniwersytet może uruchomić swój model wpływu trzęsienia ziemi, korzystając z własnych systemów, zbiorów danych i specjalistycznej wiedzy.

ORDU nie musi powielać tej zdolności.

To kolejna ważna zasada architektoniczna stojąca za ORDU Connect.

System zarządzania incydentami nie musi stawać się systemem meteorologicznym, platformą modelowania trzęsień ziemi, platformą monitoringu infrastruktury, systemem medycznym, systemem policyjnym ani żadnym innym wyspecjalizowanym systemem, który potencjalnie mógłby wnieść wkład do incydentu.

Te zdolności już istnieją.

Celem powinno być umożliwienie ich istotnym wynikom wniesienia wkładu do obrazu operacyjnego, gdy jest to potrzebne.

Szczegółowe modelowanie trzęsienia ziemi pozostaje zatem w środowisku uniwersytetu.

Po zakończeniu analizy uniwersytet może zdecydować się na bezpieczne przesłanie odpowiednich wyników do ORDU Connect.

Zamiana informacji zewnętrznych w informacje operacyjne

Informacje otrzymane przez ORDU Connect nie są po prostu wrzucane do incydentu.

Connect może przetworzyć zgłoszenie i przekształcić je w ustrukturyzowaną wiadomość zrozumiałą dla ORDU Console.

Ta wiadomość może zostać następnie wyświetlona w panelu Console dla odpowiedniego incydentu.

Zespół obsługujący incydent nie musi rozumieć bazowego systemu uniwersytetu, struktur danych ani platformy modelowania.

Otrzymują informacje w środowisku, w którym już koordynują reakcję.

Przepływ wygląda następująco:

ORDU Connect → ograniczone informacje o istotności → SV3P

a następnie, gdy jest to istotne:

SV3P → analiza specjalistyczna → ORDU Connect → ustrukturyzowana wiadomość → ORDU Console

Organizacja zewnętrzna pozostaje poza środowiskiem zarządzania incydentem, podczas gdy jej istotne informacje stają się częścią obrazu operacyjnego.

Przybliżenie szczegółowego źródła

Czasami ustrukturyzowane informacje przedstawione w ORDU Console wystarczą.

Czasami osoby podejmujące decyzję będą musiały zbadać sprawę dokładniej.

SV3P może zatem także dołączać bezpieczne odnośniki do informacji przechowywanych we własnych systemach.

W przykładzie z trzęsieniem ziemi uniwersytet może utrzymywać wyspecjalizowany panel zawierający znacznie bardziej szczegółowe modelowanie, wizualizacje, zbiory danych lub informacje pomocnicze.

ORDU może wyświetlić odnośnik do tego zasobu obok informacji otrzymanych za pośrednictwem Connect.

Co ważne, ORDU nie próbuje omijać mechanizmów bezpieczeństwa dostawcy zewnętrznego.

Większość członków zespołu obsługującego incydent może nie mieć uprawnień dostępu do tego uniwersyteckiego panelu.

Jest to oczekiwane.

Osoby posiadające odpowiednie uprawnienia mogą skorzystać z odnośnika i uwierzytelnić się u dostawcy za pomocą mechanizmów kontroli dostępu już chroniących ten system.

Staje się to szczególnie cenne podczas spotkań, dyskusji i podejmowania decyzji operacyjnych.

Zamiast tego, aby ktoś musiał pamiętać, że istnieje inny system specjalistyczny, znaleźć odpowiednią aplikację, zlokalizować właściwą analizę i ustalić, czy ma do niej dostęp, źródło może być natychmiast dostępne z poziomu informacji operacyjnej, która wywołała dyskusję.

ORDU dostarcza kontekst. Organizacja zewnętrzna zachowuje kontrolę nad szczegółowymi informacjami.

Przypadek użycia drugi: łączenie operacyjnych centrów dowodzenia

Ta sama architektura rozwiązuje zupełnie inny problem, gdy SV3P sam reaguje na incydent.

Rozważmy poważny incydent z udziałem policji, pogotowia ratunkowego i straży pożarnej.

Każda ze służb może mieć własne centrum dowodzenia, systemy, procedury, granice bezpieczeństwa i obowiązki operacyjne.

Mogą już posiadać własne, dojrzałe zdolności w zakresie zarządzania incydentami.

ORDU Studio nie powinno wymagać od tych organizacji porzucenia własnych systemów ani zmuszać wszystkich zaangażowanych w incydent wieloagencyjny do pracy w ramach jednej ogromnej aplikacji.

Wymóg jest inny.

Zespół koordynacji wieloagencyjnej potrzebuje istotnych informacji od tych organizacji.

A te organizacje potrzebują bezpiecznego, niezawodnego mechanizmu, dzięki któremu mogą zdecydować się na ich dostarczenie.

Problem telefonu

Bez integracji cyfrowej wymiana informacji między centrami dowodzenia może w dużej mierze opierać się na rozmowach telefonicznych.

Operator w jednym centrum dowodzenia odczytuje informacje ze swojego systemu.

Przekazuje je ustnie osobie w innym centrum dowodzenia.

Osoba odbierająca rozmowę słucha jej i zapisuje w innym systemie lub dzienniku incydentu.

Informacja skutecznie przeszła przez następujący łańcuch:

System → osoba → telefon → osoba → system

Zastanówmy się, co stało się z danymi.

Zaczęły jako cyfrowe.

Zostały zinterpretowane przez osobę.

Zostały przekształcone w mowę.

Przebyły drogę telefoniczną.

Zostały usłyszane i zinterpretowane przez inną osobę.

Zostały następnie przekształcone z powrotem w informację cyfrową poprzez ręczne wprowadzenie do innego systemu.

Każdy z tych etapów stwarza okazję do niezrozumienia, skrócenia, błędnego zapisania, błędu literowego lub pozbawienia informacji użytecznej struktury i kontekstu.

Osoba mówiąca może pominąć coś, czego nie uważa za istotne.

Osoba słuchająca może błędnie usłyszeć liczbę.

Lokalizacja może zostać błędnie zapisana.

Czas może stracić swój kontekst.

Terminologia używana przez jedną organizację może być interpretowana inaczej przez drugą.

A gdy taka informacja zostanie już wprowadzona do centralnego dziennika incydentu, błędnie zapisana wersja może zacząć wyglądać na wiarygodną tylko dlatego, że jest teraz zapisana w systemie.

Podczas poważnego incydentu, gdy informacje mogą się szybko zmieniać, a decyzje operacyjne mogą zależeć od drobnych szczegółów, ma to znaczenie.

Informacja cyfrowa powinna pozostać cyfrowa

ORDU Connect zapewnia inną drogę.

Tam, gdzie systemy mogą integrować się cyfrowo, ustrukturyzowane informacje mogą być przesyłane bezpiecznie z własnego środowiska organizacji do incydentu wieloagencyjnego.

Zamiast:

Centrum dowodzenia A → operator → telefon → operator → dziennik incydentu wieloagencyjnego

informacja może przebyć drogę:

Centrum dowodzenia A → ORDU Connect → ustrukturyzowana wiadomość → incydent wieloagencyjny

Informacja, która opuszcza organizację źródłową, jest informacją, która dociera do celu.

Daty pozostają datami.

Godziny pozostają godzinami.

Lokalizacje pozostają lokalizacjami.

Współrzędne pozostają współrzędnymi.

Odniesienia pozostają odniesieniami.

Identyfikatory pozostają identyfikatorami.

Pola ustrukturyzowane pozostają polami ustrukturyzowanymi.

Informacja nie musi być przekształcana w opis słowny, a następnie ręcznie odtwarzana po drugiej stronie.

Nie oznacza to usunięcia ludzi z zarządzania incydentami.

Wręcz przeciwnie.

Pozwala ludziom spędzać więcej czasu na rozumieniu informacji, omawianiu ich znaczenia i podejmowaniu decyzji, zamiast pełnić rolę ludzkich interfejsów transkrypcji danych między systemami komputerowymi.

Zachowaj to, co faktycznie zostało powiedziane

Istnieje jeszcze jedna ważna zaleta ustrukturyzowanej komunikacji cyfrowej.

Oryginalne zgłoszenie może zostać zachowane.

Oznacza to, że można rozróżnić:

to, co organizacja źródłowa faktycznie wysłała

od:

tego, jak ta informacja jest następnie prezentowana, interpretowana lub na jej podstawie podejmowane są działania.

Jest to szczególnie istotne w dzienniku incydentu.

Jeśli informacja jest przekazywana ustnie, a następnie ręcznie wpisywana do dziennika, dziennik może zawierać czyjąś transkrypcję lub interpretację oryginalnej informacji.

Przy ustrukturyzowanej komunikacji cyfrowej oryginalna wiadomość może pozostać częścią śladu audytowego.

Tworzy to silniejszą proweniencję i zapewnia znacznie wyraźniejszy zapis tego, jak informacja weszła do wieloagencyjnego obrazu operacyjnego.

SV3P wybierają, czym się dzielą

Żadne z powyższych nie oznacza, że zintegrowane centrum dowodzenia policji, pogotowia, straży pożarnej lub innej służby powinno automatycznie przesyłać strumieniowo wszystkie swoje informacje o incydencie do ORDU.

Byłoby to sprzeczne z jedną z kluczowych zasad bezpieczeństwa stojących za Connect.

To SV3P decyduje, czym się dzieli.

To SV3P decyduje, kiedy się dzieli.

Policja może posiadać informacje nieodpowiednie do szerszej dystrybucji.

Pogotowie ratunkowe może posiadać poufne informacje, które nie mają miejsca w szerszym, wieloagencyjnym obrazie operacyjnym.

Straż pożarna i ratownicza może posiadać szczegółowe wewnętrzne informacje operacyjne, które nie muszą opuszczać własnego środowiska dowodzenia.

Uniwersytet może posiadać obszerne dane badawcze, gdy tylko niewielka część jego analizy jest istotna dla incydentu.

Połączenie tych organizacji z ORDU nie tworzy nieograniczonej widoczności między granicami organizacyjnymi.

Tworzy kontrolowany mechanizm, dzięki któremu organizacja źródłowa może powiedzieć:

„Ta informacja jest istotna dla reakcji wieloagencyjnej i decydujemy się ją udostępnić.”

Ta informacja może następnie bezpiecznie przejść przez ORDU Connect.

Wszystko inne pozostaje wewnątrz własnej granicy bezpieczeństwa organizacji.

Integracja nie oznacza rezygnacji z kontroli nad własnymi danymi.

Ufaj źródłu, nie każdej informacji

Istnieje jeszcze jedno ważne rozróżnienie.

Zweryfikowane źródło nie oznacza, że każda informacja, którą wysyła, powinna być automatycznie traktowana jako fakt operacyjny.

ORDU Connect może ustalić, że zgłoszenie pochodzi od rozpoznanego SV3P.

Zapewnia to proweniencję.

Jednak proweniencja i walidacja operacyjna to różne rzeczy.

Model pozostaje modelem.

Prognoza pozostaje prognozą.

Raport operacyjny może zostać później zastąpiony nowszym.

Informacje mogą być niekompletne lub mogą być sprzeczne z informacjami otrzymanymi z innego źródła.

Zachowanie tego rozróżnienia staje się szczególnie istotne podczas złożonych incydentów z udziałem wielu organizacji.

System powinien zatem być w stanie odpowiedzieć na pytania takie jak:

• Kto dostarczył tę informację?
• Kiedy została przesłana?
• Która zweryfikowana integracja ją przesłała?
• Z jakim incydentem była powiązana?
• Jaka informacja została pierwotnie otrzymana?
• Jak ta informacja została przedstawiona w Console?
• Czy istnieje system źródłowy zawierający dalsze szczegóły?
• Czy otrzymano od tego czasu nowsze informacje?

Tworzy to podlegający audytowi łańcuch informacji bez konieczności wprowadzania dostawcy zewnętrznego do środowiska operacyjnego.

Zasada minimalnego niezbędnego ujawnienia

Architektura opiera się na prostej zasadzie bezpieczeństwa:

Ujawniaj tylko to, czego inna organizacja potrzebuje, aby wypełnić swoją rolę.

W przypadku uniwersyteckiego modelu trzęsień ziemi może to oznaczać wiedzę, że w określonym obszarze ogólnym wystąpił incydent związany z klęską żywiołową.

Nie wymaga to wiedzy, jaki personel reaguje, jakie zasoby zostały rozmieszczone, jakie decyzje zostały podjęte ani co zgłosiły inne agencje.

W przypadku służby ratunkowej może to oznaczać udostępnienie zespołowi wieloagencyjnemu ustrukturyzowanej aktualizacji operacyjnej przy jednoczesnym zachowaniu wrażliwych informacji wewnętrznych we własnych systemach.

W przypadku centralnego zespołu obsługującego incydent może to oznaczać otrzymanie wyniku specjalistycznego modelu bez uzyskiwania dostępu do całej platformy dostawcy.

Każda organizacja pozostaje odpowiedzialna za ochronę własnych informacji.

ORDU Connect zapewnia kontrolowaną wymianę informacji między nimi.

Bezpieczna komunikacja bez otwierania sieci

To ostatecznie ma zapewniać ORDU Connect:

bezpieczną granicę komunikacyjną, a nie otwartą granicę integracji.

Celem nie jest tworzenie coraz głębszego dostępu między organizacjami.

Nie chodzi o stworzenie centralnego systemu zdolnego sięgać do każdej połączonej organizacji.

Nie chodzi też o wymaganie, aby każda organizacja wnosząca informacje stała się użytkownikiem ORDU Console.

Celem jest stworzenie zaufanej drogi, przez którą organizacje mogą wymieniać dokładnie te informacje, które są potrzebne do koordynacji incydentu.

Pomyślmy ponownie o tych trojgu drzwiach.

Za pierwszymi znajduje się organizacja zewnętrzna i informacje, które chroni.

Za trzecimi znajduje się środowisko incydentu ORDU i wrażliwy obraz operacyjny, który chroni.

Pomiędzy nimi znajduje się ORDU Connect.

Drzwi środkowe istnieją po to, aby żadne z pozostałych dwojga nie musiały zostać otwarte.

ORDU Connect staje się strażnikiem między odrębnymi środowiskami operacyjnymi.

Wie, kto się komunikuje.

Kontroluje drogę do ORDU.

Może zweryfikować to, co zostało otrzymane.

Zachowuje strukturę i proweniencję wymienianych informacji.

Przypisuje te informacje do odpowiedniego incydentu.

I, co kluczowe, pozwala środowiskom operacyjnym po obu stronach pozostać chronionymi.

Nie musisz otwierać swoich systemów, aby uczestniczyć w cyfrowej koordynacji incydentu. Musisz jedynie przekazać informacje, którymi zdecydujesz się podzielić, przez kontrolowane drzwi środkowe.

Od integracji systemów do koordynacji informacji

To zmienia sposób, w jaki myślimy o interoperacyjności w zarządzaniu incydentami.

Celem nie jest umieszczenie każdej organizacji w jednym ogromnym systemie.

Nie chodzi o danie wszystkim dostępu do danych wszystkich innych.

I nie chodzi po prostu o połączenie jak największej liczby interfejsów API.

Celem jest umożliwienie przepływu właściwej informacji bezpiecznie między organizacjami, w formie ustrukturyzowanej, w momencie, gdy staje się ona użyteczna operacyjnie.

Czasami oznacza to wniesienie wyspecjalizowanych informacji z uniwersytetu lub organizacji badawczej do obrazu operacyjnego.

Czasami oznacza to umożliwienie policji, pogotowiu, straży pożarnej lub innej reagującej organizacji przesłania ustrukturyzowanej aktualizacji operacyjnej z własnego centrum dowodzenia bezpośrednio do incydentu wieloagencyjnego.

Czasami oznacza to zapewnienie upoważnionym członkom zespołu obsługującego incydent bezpiecznej drogi powrotnej do bardziej szczegółowych informacji przechowywanych w wyspecjalizowanym systemie zewnętrznym.

W każdym przypadku zasada pozostaje ta sama.

Organizacja źródłowa zachowuje kontrolę nad tym, czym i kiedy się dzieli.

Organizacja odbierająca nie potrzebuje nieograniczonego dostępu do systemu źródłowego.

Organizacja zewnętrzna nie potrzebuje nieograniczonego dostępu do centralnego incydentu.

Informacja pozostaje cyfrowa i ustrukturyzowana, zamiast być niepotrzebnie tłumaczona z systemu na mowę i z powrotem na inny system.

A ORDU Connect znajduje się pomiędzy tymi środowiskami jako kontrolowane drzwi środkowe.

ORDU Console pozostaje chronionym środowiskiem, w którym koordynowany jest incydent wieloagencyjny.

ORDU Connect zapewnia kontrolowany most, przez który zaufane organizacje i systemy mogą wnosić wkład do tego obrazu operacyjnego.

Ponieważ skuteczna koordynacja wieloagencyjna zależy od udostępniania informacji.

Nie powinno to wymagać otwierania swoich cyfrowych drzwi.

A gdy informacja już istnieje cyfrowo, nie powinno to zależeć od odczytywania jej przez telefon i liczenia na to, że po drugiej stronie zostanie poprawnie zapisana.