Saugus trečiųjų šalių prijungimas prie vykstančio incidento neatskleidžiant paties incidento

Dideli incidentai retai kada telpa vienos organizacijos informacinėse ribose.

Policija, greitoji medicinos pagalba ir priešgaisrinė tarnyba gali kiekviena valdyti savo reagavimą per savo pačių valdymo centrus ir incidentų valdymo sistemas. Savivaldybės, ligoninės, infrastruktūros operatoriai ir kitos agentūros gali daryti tą patį.

Tuo pačiu metu vertinga informacija gali ateiti iš organizacijų, kurios apskritai nedalyvauja valdant incidentą.

Universitetai, mokslinių tyrimų organizacijos, aplinkos stebėjimo sistemos, infrastruktūros paslaugų teikėjai ir specializuotos modeliavimo paslaugos gali turėti informacijos, kuri galėtų iš esmės pagerinti situacijos suvokimą.

Tai labai skirtingi santykiai, tačiau jie sukuria bendrą problemą:

Kaip leisti patikimoms trečiosioms šalims teikti informaciją apie vykstantį daugiaagentūrinį incidentą nesuteikiant joms nereikalingos prieigos prie centrinės incidentų valdymo sistemos ir nereikalaujant, kad jos mainais atvertų savo pačių sistemas?

Tai viena iš problemų, kurias sprendžiame naudodami ORDU Studio ir, konkrečiai, ORDU Connect.

Dalijimasis informacija nereikalauja bendros prieigos

Kyla pagunda į daugiaagentūrinį dalijimąsi informacija žiūrėti kaip į leidimų problemą.

Pridėti kiekvieną dalyvaujančią organizaciją kaip vartotoją. Suteikti jiems paskyras. Apriboti, ką jie gali matyti.

Arba spręsti problemą iš priešingos pusės ir tiesiogiai prisijungti prie kiekvienos organizacijos sistemų, suteikiant centrinei platformai leidimą gauti reikiamą informaciją.

Abu metodai potencialiai išplečia saugumo ribą.

Aktyviame incidente gali būti itin jautrios operacinės informacijos: vidiniai sprendimai, personalo duomenys, vietos, pažeidžiamumai, ryšiai, reagavimo planai ir kitų organizacijų pateikta informacija.

Lygiai taip pat policijos, greitosios medicinos pagalbos, priešgaisrinės tarnybos, ligoninių, infrastruktūros paslaugų teikėjų, universitetų ir kitų organizacijų valdomose sistemose gali būti informacijos, kuri neturi jokio pagrindo būti atskleista centrinei daugiaagentūrinei platformai.

Reikalavimas pasidalyti viena informacijos dalimi neturėtų virsti reikalavimu atskleisti visą sistemą.

Todėl ORDU informacijos teikimą, informacijos gavimą ir prieigą prie kitos organizacijos sistemų traiktuoja kaip atskiras sąvokas.

Organizacija gali prisidėti prie bendro daugiaagentūrinio operacinio vaizdo netapdama ORDU Console vartotoja.

ORDU gali gauti informaciją iš organizacijos negaudama prieigos prie tos organizacijos vidinių sistemų.

Šis atskyrimas yra pamatinis ORDU Connect architektūros elementas.

Patikimi verifikuoti trečiųjų šalių tiekėjai

ORDU Studio viduje patikimus išorinius informacijos tiekėjus vadiname Secured Verified Third-Party Providers, arba SV3P.

SV3P gali būti operacinė organizacija, pavyzdžiui, policija, greitoji medicinos pagalba ar priešgaisrinė tarnyba, valdanti savo pačios incidentų valdymo centrą.

Tai gali būti ligoninė, savivaldybė, komunalinių paslaugų įmonė ar infrastruktūros operatorius.

Tai gali būti ir organizacija, visiškai nedalyvaujanti koordinuojant incidentą, tačiau valdanti specializuotą sistemą, duomenų rinkinį ar analitinį pajėgumą, kuris tam tikromis aplinkybėmis tampa aktualus.

Geras pavyzdys – universitetas, valdantis žemės drebėjimų poveikio modelį.

Šios organizacijos turi labai skirtingus santykius su incidentu, todėl ORDU Connect negali daryti prielaidos, kad kiekvienas SV3P turėtų turėti tą patį prieigos lygį ar keistis ta pačia informacija.

Svarbiausia:

SV3P pats kontroliuoja, kokią informaciją jis dalijasi ir kada ją dalijasi.

Organizacijos prijungimas prie ORDU nereiškia tos organizacijos sistemų atvėrimo ORDU.

Tai taip pat nereiškia neribotos prieigos prie ORDU laikomos informacijos suteikimo tai organizacijai.

ORDU Connect suteikia kontroliuojamą skaitmeninį kanalą tarp kitu atveju atskirų aplinkų.

Trys durys, o ORDU Connect – per vidurį

Yra svarbus architektūrinis skirtumas tarp integracijos ir prieigos.

Tradicinė integracija gali reikalauti, kad viena organizacija atvertų skaitmenines duris į savo sistemas, kad kita sistema galėtų prasiskverbti vidun ir pasiimti reikiamą informaciją.

Incidentų valdyme, ypač tarp skirtingų organizacijų, tai kelia nemalonų saugumo klausimą:

Kiek savo skaitmeninės aplinkos reikia atskleisti, kad kažkas kitas galėtų gauti nedidelį informacijos kiekį, kurio jam iš tikrųjų reikia?

ORDU Connect renkasi kitokį požiūrį.

Įsivaizduokite architektūrą kaip trejas duris koridoriuje.

Pirmosios durys saugo išorinės organizacijos operacinę aplinką.

Trečiosios durys saugo ORDU incidento aplinką.

O tarp jų yra antrosios durys:

ORDU Connect.

Išorinė organizacija neduoda ORDU savo durų rakto.

ORDU neduoda išorinei organizacijai incidento rakto.

Vietoj to abi pusės bendrauja per kontroliuojamas vidurines duris.

ORDU Connect yra vartininkas.

Informaciją teikianti organizacija sprendžia, kokią informaciją nori išleisti iš savo aplinkos ir kada nori ja pasidalyti.

Ta informacija sąmoningai pateikiama per vidurines duris.

ORDU Connect autentifikuoja šaltinį, patvirtina ir apdoroja pateiktą informaciją, susieja ją su atitinkamu incidentu ir padaro struktūrizuotą informaciją prieinamą ORDU Console.

Bendravimas tampa toks:

Organizacija → ORDU Connect → ORDU Console

o ne toks:

ORDU → atverta išorinė sistema → informacijos paieška → duomenų gavimas

Šis skirtumas yra svarbus.

ORDU nereikia leidimo klaidžioti po kitos organizacijos sistemas ieškant informacijos.

Trečiajai šaliai nereikia prieigos prie ORDU Console, kad ji galėtų pateikti informaciją.

Abi operacines aplinkas saugančios durys lieka uždarytos.

ORDU Connect suteikia kontroliuojamas vidurines duris, per kurias gali praeiti patvirtinta informacija.

Siuntėjas kontroliuoja savo duris

Tai pakeičia, kas kontroliuoja dalijimosi informacija santykius.

Sistemoje, sukurtoje informacijai traukti iš kitos organizacijos, gaunančioji sistema iš esmės klausia:

„Ką man leidžiama gauti?"

Naudojant ORDU Connect, informaciją teikianti organizacija pati sprendžia:

„Ką aš noriu pasidalyti?"

ir:

„Kada aš noriu tuo pasidalyti?"

Tai ypač svarbu jungiant operacines organizacijas, tokias kaip policija, greitoji medicinos pagalba ir priešgaisrinė tarnyba.

Jų sistemose gali būti daug informacijos, kuri niekada neturėtų būti atskleista už jų pačių saugumo ribų.

Prijungimas prie ORDU neturėtų reikšti, kad ORDU suteikiama prieiga prie tų sistemų.

Vietoj to, kai organizacija nusprendžia, kad konkretus operacinis atnaujinimas turėtų tapti daugiaagentūrinio vaizdo dalimi, ji gali paskelbti šią konkrečią informaciją per vidurines duris, kurias suteikia ORDU Connect.

Visa kita lieka už informaciją teikiančios organizacijos pačios durų.

Pirmasis panaudojimo atvejis: specializuota žvalgyba be prieigos prie incidento

Mūsų pirmoji SV3P integracija yra geras pavyzdys organizacijos, kuri tiesiogiai nedalyvauja valdant incidentą.

Universitetas modeliuoja galimą žemės drebėjimų poveikį gelbėjimo tarnyboms.

Universitetui nerūpi kiekvienas per ORDU valdomas incidentas.

Jam rūpi konkrečiai incidentai, susiję su gamtinėmis nelaimėmis, kai bendra incidento vieta yra apibrėžtu atstumu nuo užfiksuoto žemės drebėjimo.

Tai sukuria labai konkretų informacinį santykį.

Universitetui reikia pakankamai informacijos, kad nustatytų:

„Ar yra incidentas, aktualus mūsų žemės drebėjimų modeliui?"

Jam nereikia klausti:

„Kas vyksta to incidento viduje?"

Šis skirtumas ir lemia informacijos apsikeitimą.

Dalytis tik tiek, kiek reikia aktualumui nustatyti

ORDU Console yra saugoma operacinė aplinka, kurioje įgalioti komandų nariai koordinuoja incidentą.

ORDU Connect suteikia kontroliuojamą ribą tarp tos aplinkos ir išorinių sistemų.

Žemės drebėjimo atveju universitetui nereikia incidento laiko juostos, operacinių sprendimų, personalo informacijos, planų, žinučių ar kitos Console laikomos jautrios informacijos.

Jam reikia tik ribotos informacijos, būtinos nustatyti, ar incidentas patenka į jo aktualumo sritį.

Šiuo atveju tai galėtų apimti tokius veiksnius kaip incidento klasifikacija ir pakankamai apibendrinta vieta.

SV3P gali palyginti šią ribotą informaciją su savo duomenimis:

Gamtinės nelaimės incidentas → bendra vieta → užfiksuotas žemės drebėjimas → atstumo riba → galimas atitikimas

Jei šios sąlygos netenkinamos, daugiau nieko daryti nereikia.

Tiekėjas gavo tik minimalią informaciją, būtiną nustatyti, kad incidentas jam neaktualus.

Tačiau jei sąlygos tenkinamos, išorinė sistema gali atlikti savo specializuotą darbą.

Leiskite specialistams likti specialistais

Nustačius aktualų incidentą, universitetas gali paleisti savo žemės drebėjimų poveikio modelį naudodamas savo pačio sistemas, duomenų rinkinius ir specializuotą kompetenciją.

ORDU neprivalo dubliuoti šio pajėgumo.

Tai dar vienas svarbus architektūrinis principas, kuriuo grindžiamas ORDU Connect.

Incidentų valdymo sistemai nereikia tapti meteorologijos sistema, žemės drebėjimų modeliavimo platforma, infrastruktūros stebėjimo platforma, medicinos sistema, policijos sistema ir kiekviena kita specializuota sistema, galinčia potencialiai prisidėti prie incidento.

Šie pajėgumai jau egzistuoja.

Tikslas turėtų būti leisti jų aktualiems rezultatams prisidėti prie operacinio vaizdo tada, kai to reikia.

Todėl detalus žemės drebėjimų modeliavimas išlieka universiteto aplinkoje.

Užbaigus analizę, universitetas gali nuspręsti saugiai pateikti aktualius rezultatus ORDU Connect.

Išorinės žvalgybos pavertimas operacine informacija

ORDU Connect gauta informacija nėra tiesiog sumetama į incidentą.

Connect gali apdoroti pateiktą informaciją ir paversti ją struktūrizuota žinute, kurią supranta ORDU Console.

Ta žinutė tada gali būti pateikta atitinkamo incidento Console prietaisų skydelyje.

Incidento komandai nereikia suprasti universiteto pagrindinės sistemos, duomenų struktūrų ar modeliavimo platformos.

Jie gauna informaciją toje aplinkoje, kurioje jau koordinuoja reagavimą.

Srautas tampa toks:

ORDU Connect → ribota aktualumo informacija → SV3P

o po to, kai aktualu, seka:

SV3P → specializuota analizė → ORDU Connect → struktūrizuota žinutė → ORDU Console

Išorinė organizacija lieka už incidentų valdymo aplinkos ribų, o jos aktuali žvalgyba tampa operacinio vaizdo dalimi.

Detalaus šaltinio priartinimas

Kartais ORDU Console pateiktos struktūrizuotos informacijos pakaks.

Kartais sprendimus priimantiems žmonėms reikės tirti giliau.

Todėl SV3P gali taip pat pateikti saugias nuorodas atgal į informaciją, laikomą jo pačio sistemose.

Žemės drebėjimo pavyzdyje universitetas gali turėti specializuotą prietaisų skydelį su gerokai detalesniu modeliavimu, vizualizacijomis, duomenų rinkiniais ar papildoma informacija.

ORDU gali parodyti nuorodą į šį resursą šalia per Connect gautos informacijos.

Svarbu tai, kad ORDU nebando apeiti išorinio tiekėjo saugumo kontrolės priemonių.

Dauguma incidento komandos narių gali neturėti leidimo pasiekti tą universiteto prietaisų skydelį.

To ir tikimasi.

Tie, kurie turi atitinkamus prisijungimo duomenis, gali sekti nuorodą ir autentifikuotis pas tiekėją naudodami tą sistemą jau saugančias prieigos kontrolės priemones.

Tai tampa ypač vertinga posėdžių, diskusijų ir operacinių sprendimų priėmimo metu.

Užuot kam nors turėjus prisiminti, kad egzistuoja kita specializuota sistema, susirasti tinkamą programą, rasti teisingą analizę ir išsiaiškinti, ar jie turi prieigą, šaltinis gali būti iškart pasiekiamas iš operacinės informacijos, kuri paskatino diskusiją.

ORDU suteikia kontekstą. Išorinė organizacija išsaugo detalios informacijos kontrolę.

Antrasis panaudojimo atvejis: operacinių valdymo centrų sujungimas

Ta pati architektūra sprendžia visai kitokią problemą, kai SV3P pats reaguoja į incidentą.

Įsivaizduokite didelį incidentą, kuriame dalyvauja policija, greitoji medicinos pagalba ir priešgaisrinė tarnyba.

Kiekviena tarnyba gali turėti savo valdymo centrą, sistemas, procedūras, saugumo ribas ir operacinius įsipareigojimus.

Jos gali jau turėti brandžius savo pačių incidentų valdymo pajėgumus.

ORDU Studio neturėtų reikalauti, kad šios organizacijos atsisakytų savo sistemų, ar priversti visus, dalyvaujančius daugiaagentūriniame incidente, dirbti per vieną milžinišką programą.

Reikalavimas yra kitoks.

Daugiaagentūrinio koordinavimo komandai reikia aktualios informacijos iš tų organizacijų.

O toms organizacijoms reikia saugaus, patikimo mechanizmo, per kurį jos galėtų pasirinkti ją teikti.

Telefono problema

Be skaitmeninės integracijos, informacijos apsikeitimas tarp valdymo centrų vis dar gali stipriai priklausyti nuo telefono skambučių.

Vieno valdymo centro operatorius perskaito informaciją iš savo sistemos.

Jis žodžiu perduoda ją kažkam kitame valdymo centre.

Skambutį priimantis asmuo išklauso ją ir įrašo kitoje sistemoje ar incidento žurnale.

Informacija iš esmės nukeliavo šia grandine:

Sistema → žmogus → telefonas → žmogus → sistema

Pagalvokite, kas atsitiko su duomenimis.

Jie prasidėjo skaitmeniniai.

Juos interpretavo žmogus.

Jie buvo paversti kalba.

Jie nukeliavo telefonu.

Juos išgirdo ir interpretavo kitas žmogus.

Tada jie buvo vėl paversti skaitmenine informacija, rankiniu būdu įvedant į kitą sistemą.

Kiekvienas iš šių etapų sukuria galimybę informacijai būti neteisingai suprastai, sutrumpintai, klaidingai perrašytai, neteisingai įvestai ar netekti naudingos struktūros ir konteksto.

Kalbantysis gali praleisti kažką, ko jis nesuvokia esant svarbu.

Klausantysis gali neteisingai išgirsti skaičių.

Vieta gali būti neteisingai perrašyta.

Laikas gali prarasti savo kontekstą.

Vienos organizacijos naudojama terminologija kitos gali būti interpretuota kitaip.

Ir kai ta informacija jau įvesta į centrinį incidento žurnalą, neteisingai perrašyta versija gali imti atrodyti autoritetinga vien todėl, kad dabar ji užrašyta sistemoje.

Didelio incidento metu, kai informacija gali sparčiai keistis, o operaciniai sprendimai gali priklausyti nuo smulkių detalių, tai turi reikšmės.

Skaitmeninė informacija turėtų likti skaitmeninė

ORDU Connect suteikia kitą kelią.

Ten, kur sistemos gali integruotis skaitmeniniu būdu, struktūrizuota informacija gali būti saugiai perduota iš organizacijos pačios aplinkos į daugiaagentūrinį incidentą.

Vietoj:

Valdymo centras A → operatorius → telefonas → operatorius → daugiaagentūrinis incidento žurnalas

informacija gali keliauti taip:

Valdymo centras A → ORDU Connect → struktūrizuota žinutė → daugiaagentūrinis incidentas

Informacija, kuri palieka teikiančią organizaciją, yra ta pati informacija, kuri atkeliauja.

Datos lieka datomis.

Laikai lieka laikais.

Vietos lieka vietomis.

Koordinatės lieka koordinatėmis.

Nuorodos lieka nuorodomis.

Identifikatoriai lieka identifikatoriais.

Struktūrizuoti laukai lieka struktūrizuoti laukai.

Informacijos nereikia paversti į sakytinį aprašymą, o tada rankiniu būdu atkurti kitame gale.

Tai nepašalina žmonių iš incidentų valdymo.

Kaip tik priešingai.

Tai leidžia žmonėms daugiau laiko skirti informacijos supratimui, jos svarbos aptarimui ir sprendimų priėmimui, o ne veikti kaip žmogiškosios duomenų perrašymo sąsajos tarp kompiuterinių sistemų.

Išsaugoti tai, kas iš tikrųjų buvo pasakyta

Yra dar vienas svarbus struktūrizuoto skaitmeninio bendravimo privalumas.

Originalus pateikimas gali būti išsaugotas.

Tai reiškia, kad galima atskirti:

ką informaciją teikianti organizacija iš tikrųjų atsiuntė

ir:

kaip ta informacija vėliau pateikiama, interpretuojama ar kaip pagal ją veikiama.

Tai ypač svarbu incidento žurnale.

Jei informacija perduodama žodžiu ir rankiniu būdu įvedama į žurnalą, žurnale gali atsidurti kažkieno originalios informacijos perrašymas ar interpretacija.

Naudojant struktūrizuotą skaitmeninį bendravimą, originali žinutė gali likti audito pėdsako dalimi.

Tai sukuria stipresnę kilmės atsekamumą ir suteikia daug aiškesnį įrašą apie tai, kaip informacija pateko į daugiaagentūrinį operacinį vaizdą.

SV3P patys renkasi, kuo dalytis

Niekas iš to nereiškia, kad integruotas policijos, greitosios medicinos pagalbos, priešgaisrinės tarnybos ar kitas valdymo centras turėtų automatiškai siųsti visą savo incidento informaciją į ORDU.

Tai sugriautų vieną iš pagrindinių Connect saugumo principų.

SV3P sprendžia, kuo jis dalijasi.

SV3P sprendžia, kada jis tuo dalijasi.

Policija gali turėti informacijos, kuri netinkama platesniam platinimui.

Greitosios medicinos pagalbos tarnybos gali turėti konfidencialios informacijos, kuriai nėra vietos platesniame daugiaagentūriniame operaciniame vaizde.

Priešgaisrinės ir gelbėjimo tarnybos gali turėti detalios vidinės operacinės informacijos, kuriai nereikia palikti jų pačių valdymo aplinkos.

Universitetas gali turėti didelius mokslinių tyrimų duomenis, kai tik nedidelė jo analizės dalis aktuali incidentui.

Šių organizacijų prijungimas prie ORDU nesukuria neribotos matomumo tarp organizacijų ribų.

Jis sukuria kontroliuojamą mechanizmą, per kurį teikianti organizacija gali pasakyti:

„Ši informacija aktuali daugiaagentūriniam atsakui, ir mes nusprendžiame ja pasidalyti."

Ta informacija tada gali saugiai praeiti per ORDU Connect.

Visa kita lieka organizacijos pačios saugumo ribose.

Integracija nereiškia savo duomenų kontrolės atidavimo.

Pasitikėkite šaltiniu, o ne kiekvienu informacijos vienetu

Yra dar vienas svarbus skirtumas.

Patikrintas šaltinis nereiškia, kad kiekvienas jo siunčiamas informacijos vienetas turėtų būti automatiškai laikomas operaciniu faktu.

ORDU Connect gali nustatyti, kad pateikta informacija kilo iš pripažinto SV3P.

Tai suteikia kilmės patvirtinimą.

Tačiau kilmės patvirtinimas ir operacinis patvirtinimas yra skirtingi dalykai.

Modelis lieka modeliu.

Prognozė lieka prognoze.

Operacinė ataskaita vėliau gali būti pakeista.

Informacija gali būti nepilna arba prieštarauti informacijai, gautai iš kito šaltinio.

Šio skirtumo išlaikymas ypač svarbus sudėtingų, kelias organizacijas apimančių incidentų metu.

Todėl sistema turėtų sugebėti atsakyti į tokius klausimus:

• Kas pateikė šią informaciją?
• Kada ji buvo pateikta?
• Kuri patikrinta integracija ją pateikė?
• Su kuriuo incidentu ji susijusi?
• Kokia informacija iš pradžių buvo gauta?
• Kaip ta informacija buvo pateikta Console?
• Ar yra šaltinio sistema, kurioje yra daugiau detalių?
• Ar vėliau buvo gauta naujesnės informacijos?

Tai sukuria audituojamą informacijos grandinę, nereikalaujant, kad išorinis tiekėjas patektų į operacinę aplinką.

Būtiniausio atskleidimo principas

Architektūra grindžiama paprastu saugumo principu:

Atskleisti tik tai, ko kitai organizacijai reikia savo vaidmeniui atlikti.

Universiteto žemės drebėjimų modelio atveju tai gali reikšti žinojimą, kad tam tikroje bendroje teritorijoje egzistuoja gamtinės nelaimės incidentas.

Tam nereikia žinoti, kurie darbuotojai reaguoja, kokie ištekliai buvo panaudoti, kokie sprendimai priimti ar ką pranešė kitos agentūros.

Gelbėjimo tarnybai tai gali reikšti struktūrizuoto operacinio atnaujinimo pateikimą daugiaagentūrinei komandai, kartu išsaugant jautrią vidinę informaciją savo pačios sistemose.

Centrinei incidento komandai tai gali reikšti specializuoto modelio rezultatų gavimą, negaunant prieigos prie visos tiekėjo platformos.

Kiekviena organizacija išlieka atsakinga už savo pačios informacijos apsaugą.

ORDU Connect suteikia kontroliuojamą informacijos mainų kanalą tarp jų.

Saugus bendravimas neatveriant tinklo

Būtent tai galiausiai ORDU Connect ir sukurta suteikti:

saugią bendravimo ribą, o ne atvirą integracijos ribą.

Tikslas nėra kurti vis gilesnę ir gilesnę prieigą tarp organizacijų.

Tikslas nėra sukurti centrinę sistemą, galinčią patekti į kiekvieną prijungtą organizaciją.

Ir tikslas nėra reikalauti, kad kiekviena informaciją teikianti organizacija taptų ORDU Console vartotoja.

Tikslas yra sukurti patikimą kelią, per kurį organizacijos galėtų keistis būtent ta informacija, kurios reikia incidentui koordinuoti.

Vėl pagalvokite apie tas trejas duris.

Už pirmųjų – išorinė organizacija ir jos saugoma informacija.

Už trečiųjų – ORDU incidento aplinka ir jos saugomas jautrus operacinis vaizdas.

Tarp jų – ORDU Connect.

Vidurinės durys egzistuoja tam, kad nė vienos iš kitų dviejų nereikėtų atverti.

ORDU Connect tampa vartininku tarp kitu atveju atskirų operacinių aplinkų.

Jis žino, kas bendrauja.

Jis kontroliuoja kelią į ORDU.

Jis gali patvirtinti, kas gaunama.

Jis išsaugo apsikeičiamos informacijos struktūrą ir kilmę.

Jis susieja tą informaciją su atitinkamu incidentu.

Ir, svarbiausia, jis leidžia abiejose pusėse esančioms operacinėms aplinkoms likti apsaugotoms.

Jums nereikia atverti savo sistemų, kad dalyvautumėte skaitmeniniame incidento koordinavime. Jums tereikia perduoti informaciją, kuria nusprendėte pasidalyti, per kontroliuojamas vidurines duris.

Nuo sistemų integracijos prie informacijos koordinavimo

Tai keičia mūsų požiūrį į sąveikumą incidentų valdyme.

Tikslas nėra sudėti kiekvieną organizaciją į vieną milžinišką sistemą.

Tikslas nėra suteikti visiems prieigą prie visų kitų duomenų.

Ir tikslas nėra tiesiog prijungti kuo daugiau API.

Tikslas yra leisti tinkamai informacijai saugiai judėti tarp organizacijų, struktūrizuota forma, tuo metu, kai ji tampa operaciniu požiūriu naudinga.

Kartais tai reiškia specializuotos žvalgybos iš universiteto ar mokslinių tyrimų organizacijos perkėlimą į operacinį vaizdą.

Kartais tai reiškia leidimą policijai, greitajai medicinos pagalbai, priešgaisrinei tarnybai ar kitai reaguojančiai organizacijai siųsti struktūrizuotą operacinį atnaujinimą tiesiai iš savo valdymo centro į daugiaagentūrinį incidentą.

Kartais tai reiškia įgaliotiems incidento komandos nariams suteikiamą saugų kelią atgal į detalesnę informaciją, laikomą specializuotoje išorinėje sistemoje.

Kiekvienu atveju principas išlieka tas pats.

Informaciją teikianti organizacija išlaiko kontrolę, kuo ir kada ji dalijasi.

Informaciją gaunančiai organizacijai nereikia neribotos prieigos prie teikiančios sistemos.

Išorinei organizacijai nereikia neribotos prieigos prie centrinio incidento.

Informacija lieka skaitmeninė ir struktūrizuota, o ne nereikalingai verčiama iš sistemos į kalbą ir atgal į kitą sistemą.

Ir ORDU Connect įsikuria tarp šių aplinkų kaip kontroliuojamos vidurinės durys.

ORDU Console lieka saugoma aplinka, kurioje koordinuojamas daugiaagentūrinis incidentas.

ORDU Connect suteikia kontroliuojamą tiltą, per kurį patikimos organizacijos ir sistemos gali prisidėti prie to operacinio vaizdo.

Nes efektyvus daugiaagentūrinis koordinavimas priklauso nuo dalijimosi informacija.

Tam neturėtų reikėti atverti savo skaitmeninių durų.

O kai informacija jau egzistuoja skaitmeniniu pavidalu, tam neturėtų reikėti jos skaityti telefonu ir tikėtis, kad kitame gale ji bus teisingai užrašyta.