Бяспечнае падключэнне трэціх бакоў да актыўнага інцыдэнту без раскрыцця самога інцыдэнту

Буйныя інцыдэнты рэдка існуюць у інфармацыйных межах адной арганізацыі.

Паліцыя, хуткая дапамога і пажарная служба могуць кожная кіраваць сваім рэагаваннем праз уласныя дыспетчарскія цэнтры і сістэмы кіравання інцыдэнтамі. Мясцовыя ўлады, бальніцы, аператары інфраструктуры і іншыя ведамствы могуць рабіць тое ж самае.

У той жа час каштоўная інфармацыя можа паступаць ад арганізацый, якія наогул не ўдзельнічаюць у кіраванні інцыдэнтам.

Універсітэты, даследчыя арганізацыі, сістэмы экалагічнага маніторынгу, пастаўшчыкі інфраструктуры і спецыялізаваныя службы мадэлявання могуць валодаць інфармацыяй, якая здольная істотна палепшыць разуменне сітуацыі.

Гэта вельмі розныя ўзаемаадносіны, але яны стварае агульную праблему:

Як дазволіць давераным трэцім бакам дадаваць інфармацыю ў актыўны міжведамасны інцыдэнт, не даючы ім лішняга доступу да цэнтральнай сістэмы кіравання інцыдэнтамі і не патрабуючы ад іх адкрываць свае ўласныя сістэмы ў адказ?

Гэта адна з праблем, якую мы вырашаем з дапамогай ORDU Studio і, у прыватнасці, ORDU Connect.

Абмен інфармацыяй не патрабуе агульнага доступу

Спакуслівае думаць пра міжведамасны абмен інфармацыяй як пра праблему дазволаў.

Дадаць кожную ўдзельную арганізацыю як карыстальніка. Даць ім уліковыя запісы. Абмежаваць тое, што яны могуць бачыць.

Або падысці да праблемы з процілеглага боку і падключыцца непасрэдна да сістэм кожнай арганізацыі, даўшы цэнтральнай платформе дазвол атрымліваць неабходную ёй інфармацыю.

Абодва падыходы патэнцыйна пашыраюць мяжу бяспекі.

Актыўны інцыдэнт можа змяшчаць вельмі адчувальную аператыўную інфармацыю: унутраныя рашэнні, дадзеныя аб персанале, месцазнаходжанні, слабыя месцы, камунікацыі, планы рэагавання і інфармацыю, прадстаўленую іншымі арганізацыямі.

Гэтак жа сістэмы, якімі кіруюць паліцыя, хуткая дапамога, пажарная служба, бальніцы, пастаўшчыкі інфраструктуры, універсітэты і іншыя арганізацыі, могуць змяшчаць інфармацыю, якая наогул не мае прычын быць раскрытай цэнтральнай міжведамаснай платформе.

Патрэба падзяліцца адной часткай інфармацыі не павінна ператварацца ў патрэбу раскрыць усю сістэму.

Таму ORDU разглядае прадастаўленне інфармацыі, атрыманне інфармацыі і доступ да сістэм іншай арганізацыі як асобныя паняцці.

Арганізацыя можа дадаваць уклад у міжведамасную аператыўную карціну, не становячыся карыстальнікам ORDU Console.

ORDU можа атрымліваць інфармацыю ад арганізацыі, не атрымліваючы доступу да ўнутраных сістэм гэтай арганізацыі.

Гэта размежаванне з'яўляецца фундаментальным для архітэктуры ORDU Connect.

Абароненыя правераныя пастаўшчыкі трэціх бакоў

У межах ORDU Studio мы называем давераных знешніх пастаўшчыкоў інфармацыі Абароненымі правераными пастаўшчыкамі трэціх бакоў, або SV3P.

SV3P можа быць аператыўнай арганізацыяй, такой як паліцыя, хуткая дапамога або пажарная служба, якая кіруе ўласным дыспетчарскім цэнтрам інцыдэнту.

Гэта можа быць бальніца, мясцовыя ўлады, камунальная кампанія або аператар інфраструктуры.

Гэта таксама можа быць арганізацыя, якая наогул не мае ніякай ролі ў каардынацыі інцыдэнту, але якая эксплуатуе спецыялізаваную сістэму, набор дадзеных або аналітычную здольнасць, што становіцца актуальным пры пэўных абставінах.

Універсітэт, які запускае мадэль уплыву землятрусу, — добры прыклад.

Гэтыя арганізацыі маюць вельмі розныя ўзаемаадносіны з інцыдэнтам, таму ORDU Connect не можа мяркуе, што кожны SV3P павінен мець аднолькавы ўзровень доступу або абменьвацца аднолькавай інфармацыяй.

Найбольш важна:

SV3P кантралюе, якой інфармацыяй ён дзеліцца і калі ён гэта робіць.

Падключэнне арганізацыі да ORDU не азначае адкрыцця сістэм гэтай арганізацыі для ORDU.

Гэта таксама не азначае прадастаўлення гэтай арганізацыі неабмежаванага доступу да інфармацыі, якая захоўваецца ў ORDU.

ORDU Connect забяспечвае кантраляваны лічбавы канал паміж інакш раздзеленымі асяроддзямі.

Тры дзверы, з ORDU Connect пасярэдзіне

Існуе важная архітэктурная розніца паміж інтэграцыяй і доступам.

Традыцыйная інтэграцыя можа патрабаваць, каб адна арганізацыя адкрыла лічбавыя дзверы ў свае сістэмы, каб іншая сістэма магла пранікнуць унутр і атрымаць неабходную ёй інфармацыю.

Для кіравання інцыдэнтамі, асабліва праз арганізацыйныя межы, гэта стварае непрыемнае пытанне бяспекі:

Наколькі шмат вашага лічбавага асяроддзя вам трэба раскрыць, каб хтосьці іншы мог атрымаць невялікую колькасць інфармацыі, якая яму сапраўды патрэбна?

ORDU Connect выкарыстоўвае іншы падыход.

Уявіце архітэктуру як трое дзвярэй у калідоры.

Першыя дзверы абараняюць аператыўнае асяроддзе знешняй арганізацыі.

Трэція дзверы абараняюць асяроддзе інцыдэнту ORDU.

А паміж імі знаходзяцца другія дзверы:

ORDU Connect.

Знешняя арганізацыя не дае ORDU ключ ад сваіх дзвярэй.

ORDU не дае знешняй арганізацыі ключ ад інцыдэнту.

Замест гэтага абодва бакі мяркуюцца праз кантраляваныя сярэднія дзверы.

ORDU Connect — гэта вартаўнік.

Арганізацыя-крыніца вырашае, якую інфармацыю яна хоча дазволіць пакінуць сваё асяроддзе і калі яна хоча ёй падзяліцца.

Гэтая інфармацыя наўмысна прадстаўляецца праз сярэднія дзверы.

ORDU Connect аўтэнтыфікуе крыніцу, правярае і апрацоўвае прадастаўленыя дадзеныя, звязвае іх з адпаведным інцыдэнтам і робіць структураваную інфармацыю даступнай для ORDU Console.

Камунікацыя становіцца:

Арганізацыя → ORDU Connect → ORDU Console

а не:

ORDU → адкрыццё знешняй сістэмы → пошук інфармацыі → атрыманне дадзеных

Гэтая розніца мае значэнне.

ORDU не патрабуецца дазвол блукаць па сістэмах іншай арганізацыі ў пошуках інфармацыі.

Трэцяму боку не патрабуецца доступ да ORDU Console, каб перадаць інфармацыю.

Дзверы, якія абараняюць абодва аператыўныя асяроддзі, застаюцца зачыненымі.

ORDU Connect забяспечвае кантраляваныя сярэднія дзверы, праз якія можа праходзіць зацверджаная інфармацыя.

Адпраўнік кантралюе свае дзверы

Гэта змяняе, хто кантралюе адносіны абмену інфармацыяй.

У сістэме, разлічанай на выманне інфармацыі з іншай арганізацыі, прымаючая сістэма фактычна пытаецца:

«Што мне дазволена атрымаць?»

З ORDU Connect арганізацыя-крыніца замест гэтага вырашае:

«Чым я хачу падзяліцца?»

і:

«Калі я хачу гэтым падзяліцца?»

Гэта асабліва важна пры падключэнні аператыўных арганізацый, такіх як паліцыя, хуткая дапамога і пажарная служба.

Іх сістэмы могуць змяшчаць вялікую колькасць інфармацыі, якая ніколі не павінна быць раскрыта за межамі іх уласнай мяжы бяспекі.

Падключэнне да ORDU не павінна азначаць прадастаўленне ORDU доступу да гэтых сістэм.

Замест гэтага, калі арганізацыя вызначае, што пэўнае аператыўнае абнаўленне павінна стаць часткай міжведамаснай карціны, яна можа апублікаваць гэтую канкрэтную інфармацыю праз сярэднія дзверы, прадастаўленыя ORDU Connect.

Усё астатняе застаецца за ўласнымі дзвярыма арганізацыі-крыніцы.

Сцэнарый выкарыстання адзін: спецыялізаваныя звесткі без доступу да інцыдэнту

Наша першая інтэграцыя SV3P дае добры прыклад арганізацыі, якая не ўдзельнічае непасрэдна ў кіраванні інцыдэнтам.

Універсітэт мадэлюе патэнцыйны ўплыў землятрусаў на экстранныя службы.

Універсітэт не зацікаўлены ў кожным інцыдэнце, які кіруецца праз ORDU.

Ён зацікаўлены канкрэтна ў інцыдэнтах, звязаных са стыхійнымі бедствамі, дзе агульнае месцазнаходжанне інцыдэнту знаходзіцца ў межах вызначанай адлегласці ад выяўленага землятрусу.

Гэта стварае вельмі спецыфічныя інфармацыйныя адносіны.

Універсітэту патрэбна дастаткова інфармацыі, каб устанавіць:

«Ці ёсць інцыдэнт, актуальны для нашай мадэлі землятрусу?»

Яму не трэба пытацца:

«Што адбываецца ўнутры гэтага інцыдэнту?»

Гэтая розніца кіруе абменам інфармацыяй.

Дзяліцеся толькі тым, чаго дастаткова для ўстанаўлення актуальнасці

ORDU Console — гэта абароненае аператыўнае асяроддзе, дзе ўпаўнаважаныя каманды каардынуюць інцыдэнт.

ORDU Connect забяспечвае кантраляваную мяжу паміж гэтым асяроддзем і знешнімі сістэмамі.

Для сцэнарыя з землятрусам універсітэту не патрэбны храналогія інцыдэнту, аператыўныя рашэнні, інфармацыя аб персанале, планы, паведамленні або іншая адчувальная інфармацыя, якая захоўваецца ў Console.

Яму патрэбна толькі абмежаваная інфармацыя, неабходная для вызначэння, ці адносіцца інцыдэнт да яго вобласці цікавасці.

У гэтым выпадку гэта можа ўключаць такія фактары, як класіфікацыя інцыдэнту і дастаткова абагуленае месцазнаходжанне.

SV3P можа параўнаць гэтую абмежаваную інфармацыю з уласнымі дадзенымі:

Інцыдэнт стыхійнага бедства → агульнае месцазнаходжанне → выяўлены землятрус → парог адлегласці → патэнцыйнае супадзенне

Калі гэтыя ўмовы не выконваюцца, нічога далейшага адбывацца не павінна.

Пастаўшчык атрымаў толькі мінімум інфармацыі, неабходны, каб устанавіць, што інцыдэнт для яго не актуальны.

Калі ж умовы выконваюцца, знешняя сістэма можа выканаць сваю спецыялізаваную працу.

Дазвольце спецыялістам заставацца спецыялістамі

Пасля таго як актуальны інцыдэнт вызначаны, універсітэт можа запусціць сваю мадэль уплыву землятрусу, выкарыстоўваючы ўласныя сістэмы, наборы дадзеных і спецыялізаваную экспертызу.

ORDU не патрэбна паўтараць гэтую здольнасць.

Гэта яшчэ адзін важны архітэктурны прынцып ORDU Connect.

Сістэма кіравання інцыдэнтамі не павінна ператварацца ў метэаралагічную сістэму, платформу мадэлявання землятрусаў, платформу маніторынгу інфраструктуры, медыцынскую сістэму, паліцэйскую сістэму і любую іншую спецыялізаваную сістэму, якая патэнцыйна магла б дадаваць уклад у інцыдэнт.

Гэтыя здольнасці ўжо існуюць.

Мэтай павінна быць дазволіць іх адпаведным вынікам дадаваць уклад у аператыўную карціну, калі гэта неабходна.

Такім чынам, дэталёвае мадэляванне землятрусу застаецца ў асяроддзі універсітэта.

Пасля завяршэння аналізу універсітэт можа выбраць бяспечнае прадстаўленне адпаведных вынікаў ORDU Connect.

Ператварэнне знешніх звестак у аператыўную інфармацыю

Інфармацыя, атрыманая ORDU Connect, проста не «скідваецца» ў інцыдэнт.

Connect можа апрацаваць прадстаўленыя дадзеныя і пераўтварыць іх у структураванае паведамленне, якое разумее ORDU Console.

Гэта паведамленне затым можа быць адлюстравана на панэлі кіравання Console для адпаведнага інцыдэнту.

Камандзе інцыдэнту не трэба разумець базавую сістэму, структуры дадзеных або платформу мадэлявання ўніверсітэта.

Яны атрымліваюць інфармацыю ў тым асяроддзі, дзе яны ўжо каардынуюць рэагаванне.

Паток становіцца:

ORDU Connect → абмежаваная інфармацыя пра актуальнасць → SV3P

затым, дзе гэта актуальна:

SV3P → спецыялізаваны аналіз → ORDU Connect → структураванае паведамленне → ORDU Console

Знешняя арганізацыя застаецца па-за асяроддзем кіравання інцыдэнтамі, у той час як яе актуальныя звесткі становяцца часткай аператыўнай карціны.

Наблізіць дэталёвую крыніцу

Часам структураванай інфармацыі, прадстаўленай у ORDU Console, будзе дастаткова.

Часам людзям, якія прымаюць рашэнне, спатрэбіцца дадаткова расследаваць.

Таму SV3P можа таксама ўключаць бяспечныя спасылкі назад на інфармацыю, якая захоўваецца ва ўласных сістэмах.

У прыкладзе з землятрусам універсітэт можа падтрымліваць спецыялізаваную панэль кіравання, якая змяшчае значна больш дэталёвае мадэляванне, візуалізацыі, наборы дадзеных або дадатковую інфармацыю.

ORDU можа паказаць спасылку на гэты рэсурс побач з інфармацыяй, атрыманай праз Connect.

Важна, што ORDU не спрабуе абыйсці сродкі бяспекі знешняга пастаўшчыка.

Большасць членаў каманды інцыдэнту можа не мець дазволу на доступ да гэтай універсітэцкай панэлі кіравання.

Гэта чакана.

Тыя, у каго ёсць адпаведныя ўліковыя дадзеныя, могуць перайсці па спасылцы і аўтэнтыфікавацца ў пастаўшчыка, выкарыстоўваючы сродкі кантролю доступу, якія ўжо абараняюць гэтую сістэму.

Гэта становіцца асабліва каштоўным падчас нарад, абмеркаванняў і прыняцця аператыўных рашэнняў.

Замест таго каб камусьці прыгадваць, што існуе іншая спецыялізаваная сістэма, знаходзіць адпаведнае прыкладанне, шукаць правільны аналіз і высвятляць, ці ёсць у яго доступ, крыніца можа быць неадкладна даступная з той аператыўнай інфармацыі, якая выклікала абмеркаванне.

ORDU дае кантэкст. Знешняя арганізацыя захоўвае кантроль над дэталёвай інфармацыяй.

Сцэнарый выкарыстання два: падключэнне аператыўных дыспетчарскіх цэнтраў

Тая ж архітэктура вырашае вельмі іншую праблему, калі сам SV3P рэагуе на інцыдэнт.

Разгледзім буйны інцыдэнт, у якім задзейнічаны паліцыя, хуткая дапамога і пажарная служба.

Кожная служба можа мець уласны дыспетчарскі цэнтр, сістэмы, працэдуры, межы бяспекі і аператыўныя абавязкі.

Яны могуць ужо мець развітыя ўласныя здольнасці кіравання інцыдэнтамі.

ORDU Studio не павінна патрабаваць ад гэтых арганізацый адмовы ад сваіх сістэм або прымушаць усіх, хто ўдзельнічае ў міжведамасным інцыдэнце, працаваць праз адзін велізарны праграмны прадукт.

Патрэба тут іншая.

Каманда міжведамаснай каардынацыі мае патрэбу ў актуальнай інфармацыі ад гэтых арганізацый.

А гэтым арганізацыям патрэбны бяспечны, надзейны механізм, праз які яны могуць выбраць прадастаўленне гэтай інфармацыі.

Праблема тэлефона

Без лічбавай інтэграцыі абмен інфармацыяй паміж дыспетчарскімі цэнтрамі ўсё яшчэ можа моцна залежаць ад тэлефонных званкоў.

Аператар аднаго дыспетчарскага цэнтра счытвае інфармацыю са сваёй сістэмы.

Ён вусна перадае яе камусьці ў іншым дыспетчарскім цэнтры.

Чалавек, які прымае званок, слухае яго і фіксуе ў іншай сістэме або журнале інцыдэнту.

Інфармацыя фактычна прайшла праз наступны ланцужок:

Сістэма → чалавек → тэлефон → чалавек → сістэма

Задумайцеся, што адбылося з дадзенымі.

Яны пачыналіся ў лічбавым выглядзе.

Яны былі інтэрпрэтаваны чалавекам.

Яны былі пераўтвораны ў гутарковую мову.

Яны прайшлі праз тэлефонную сувязь.

Яны былі пачутыя і інтэрпрэтаваныя іншым чалавекам.

Затым яны зноў былі пераўтвораны ў лічбавую інфармацыю шляхам ручнога ўводу ў іншую сістэму.

Кожны з гэтых этапаў стварае магчымасць для таго, каб інфармацыя была няправільна зразумета, скарочана, няправільна расшыфравана, набрана з памылкай або пазбаўлена карыснай структуры і кантэксту.

Чалавек, які гаворыць, можа прапусціць нешта, значнасці чаго ён не ўсведамляе.

Чалавек, які слухае, можа няправільна пачуць лічбу.

Месцазнаходжанне можа быць няправільна запісана.

Час можа страціць свой кантэкст.

Тэрміналогія, якую выкарыстоўвае адна арганізацыя, можа быць інтэрпрэтавана па-іншаму іншай.

І як толькі гэтая інфармацыя занесена ў цэнтральны журнал інцыдэнту, няправільна расшыфраваная версія можа пачаць выглядаць аўтарытэтнай проста таму, што яна цяпер запісана ў сістэме.

Падчас буйнога інцыдэнту, калі інфармацыя можа хутка змяняцца, а аператыўныя рашэнні могуць залежаць ад дробных дэталяў, гэта мае значэнне.

Лічбавая інфармацыя павінна заставацца лічбавай

ORDU Connect прапануе іншы шлях.

Там, дзе сістэмы могуць інтэгравацца лічбава, структураваная інфармацыя можа бяспечна перадавацца з уласнага асяроддзя арганізацыі ў міжведамасны інцыдэнт.

Замест:

Дыспетчарскі цэнтр A → аператар → тэлефон → аператар → журнал міжведамаснага інцыдэнту

інфармацыя можа перамяшчацца:

Дыспетчарскі цэнтр A → ORDU Connect → структураванае паведамленне → міжведамасны інцыдэнт

Інфармацыя, якая пакідае арганізацыю-крыніцу, — гэта тая ж інфармацыя, якая прыбывае.

Даты застаюцца датамі.

Час застаецца часам.

Месцазнаходжанні застаюцца месцазнаходжаннямі.

Каардынаты застаюцца каардынатамі.

Спасылкі застаюцца спасылкамі.

Ідэнтыфікатары застаюцца ідэнтыфікатарамі.

Структураваныя палі застаюцца структураванымі палямі.

Інфармацыі не трэба пераўтварацца ў вуснае апісанне, а затым уручную аднаўляцца на другім канцы.

Гэта не выключае людзей з кіравання інцыдэнтамі.

Наадварот.

Гэта дазваляе людзям больш часу прысвячаць разуменню інфармацыі, абмеркаванню яе значнасці і прыняццю рашэнняў, а не выконваць ролю чалавечых інтэрфейсаў перадачы дадзеных паміж камп'ютарнымі сістэмамі.

Захоўваць тое, што сапраўды было сказана

Ёсць яшчэ адна важная перавага структураванай лічбавай камунікацыі.

Арыгінальнае прадстаўленне можа захоўвацца.

Гэта азначае, што можа існаваць розніца паміж:

тым, што арганізацыя-крыніца сапраўды адправіла

і:

тым, як гэтая інфармацыя пазней прадстаўляецца, інтэрпрэтуецца або выкарыстоўваецца.

Гэта асабліва важна ў журнале інцыдэнту.

Калі інфармацыя перадаецца вусна і ўручную ўносіцца ў журнал, гэты журнал можа змяшчаць чыюсьці расшыфроўку або інтэрпрэтацыю зыходнай інфармацыі.

Пры структураванай лічбавай камунікацыі арыгінальнае паведамленне можа заставацца часткай аўдытарскага следу.

Гэта стварае больш трывалае паходжанне дадзеных і забяспечвае значна больш выразны запіс таго, як інфармацыя трапіла ў міжведамасную аператыўную карціну.

SV3P выбіраюць, чым дзяліцца

Нішто з гэтага не азначае, што інтэграваны дыспетчарскі цэнтр паліцыі, хуткай дапамогі, пажарнай службы або іншы павінен аўтаматычна транслюяваць усю сваю інфармацыю пра інцыдэнт у ORDU.

Гэта звяло б на нішто адзін з ключавых прынцыпаў бяспекі, на якіх пабудаваны Connect.

SV3P вырашае, чым ён дзеліцца.

SV3P вырашае, калі ён гэтым дзеліцца.

Паліцыя можа валодаць інфармацыяй, якая не падыходзіць для шырокага распаўсюджвання.

Служба хуткай дапамогі можа валодаць канфідэнцыйнай інфармацыяй, якой няма месца ў шырэйшай міжведамаснай аператыўнай карціне.

Пажарна-выратавальныя службы могуць мець дэталёвую ўнутраную аператыўную інфармацыю, якая не павінна пакідаць іх уласнае кантрольнае асяроддзе.

Універсітэт можа мець вялікі аб'ём даследчых дадзеных, тады як толькі невялікая частка яго аналізу актуальная для інцыдэнту.

Падключэнне гэтых арганізацый да ORDU не стварае неабмежаванай бачнасці праз арганізацыйныя межы.

Яно стварае кантраляваны механізм, праз які арганізацыя-крыніца можа сказаць:

«Гэтая інфармацыя актуальная для міжведамаснага рэагавання, і мы вырашаем ёй падзяліцца».

Гэтая інфармацыя затым можа бяспечна прайсці праз ORDU Connect.

Усё астатняе застаецца ўнутры ўласнай мяжы бяспекі арганізацыі.

Інтэграцыя не азначае адмову ад кантролю над вашымі дадзенымі.

Даверце крыніцы, а не кожнай частцы інфармацыі

Ёсць яшчэ адна важная розніца.

Правераная крыніца не азначае, што кожная частка інфармацыі, якую яна адпраўляе, павінна аўтаматычна разглядацца як аператыўны факт.

ORDU Connect можа ўстанавіць, што прадстаўленыя дадзеныя паходзяць ад прызнанага SV3P.

Гэта забяспечвае паходжанне.

Але паходжанне і аператыўная праверка — розныя рэчы.

Мадэль застаецца мадэллю.

Прагноз застаецца прагнозам.

Аператыўная справаздача можа пазней быць заменена.

Інфармацыя можа быць няпоўнай або супярэчыць інфармацыі, атрыманай з іншай крыніцы.

Захаванне гэтага размежавання становіцца асабліва важным падчас складаных інцыдэнтаў з удзелам некалькіх арганізацый.

Такім чынам, сістэма павінна быць здольная адказваць на пытанні накшталт:

• Хто прадставіў гэтую інфармацыю?
• Калі яна была прадстаўлена?
• Якая правераная інтэграцыя яе прадставіла?
• З якім інцыдэнтам яна была звязана?
• Якая інфармацыя была першапачаткова атрымана?
• Як гэтая інфармацыя была прадстаўлена ў Console?
• Ці ёсць сістэма-крыніца, якая змяшчае больш дэталяў?
• Ці была атрымана больш новая інфармацыя пазней?

Гэта стварае магчымасць правядзення аўдыту ланцуга інфармацыі без неабходнасці для знешняга пастаўшчыка ўваходзіць у аператыўнае асяроддзе.

Прынцып мінімальна неабходнага раскрыцця

Архітэктура заснавана на простым прынцыпе бяспекі:

Раскрываць толькі тое, што патрэбна іншай арганізацыі для выканання яе ролі.

Для ўніверсітэцкай мадэлі землятрусу гэта можа азначаць веданне таго, што ў пэўнай агульнай вобласці існуе інцыдэнт стыхійнага бедства.

Гэта не патрабуе ведаць, які персанал рэагуе, якія рэсурсы задзейнічаны, якія рашэнні прыняты або пра што паведамілі іншыя ведамствы.

Для экстранай службы гэта можа азначаць абмен структураваным аператыўным абнаўленнем з міжведамаснай камандай пры захаванні адчувальнай унутранай інфармацыі ва ўласных сістэмах.

Для цэнтральнай каманды інцыдэнту гэта можа азначаць атрыманне выніку спецыялізаванай мадэлі без прадастаўлення доступу да ўсёй платформы пастаўшчыка.

Кожная арганізацыя застаецца адказнай за абарону ўласнай інфармацыі.

ORDU Connect забяспечвае кантраляваны абмен інфармацыяй паміж імі.

Бяспечная камунікацыя без адкрыцця сеткі

Урэшце гэта тое, для чаго прызначаны ORDU Connect:

бяспечная мяжа камунікацыі, а не адкрытая мяжа інтэграцыі.

Мэта не ў тым, каб ствараць усё больш глыбокі доступ паміж арганізацыямі.

Мэта не ў тым, каб стварыць цэнтральную сістэму, здольную дацягнуцца да кожнай падключанай арганізацыі.

І мэта не ў тым, каб патрабаваць ад кожнай арганізацыі, якая дадае інфармацыю, станавіцца карыстальнікам ORDU Console.

Мэта — стварыць давераны шлях, праз які арганізацыі могуць абменьвацца менавіта той інфармацыяй, якая неабходная для каардынацыі інцыдэнту.

Успомніце зноў пра тыя тры дзверы.

За першымі знаходзіцца знешняя арганізацыя і інфармацыя, якую яна абараняе.

За трэцімі знаходзіцца асяроддзе інцыдэнту ORDU і адчувальная аператыўная карціна, якую яно абараняе.

Паміж імі знаходзіцца ORDU Connect.

Сярэднія дзверы існуюць для таго, каб ні адны з двух іншых не трэба было адчыняць.

ORDU Connect становіцца вартаўніком паміж інакш раздзеленымі аператыўнымі асяроддзямі.

Ён ведае, хто камунікуе.

Ён кантралюе шлях у ORDU.

Ён можа правяраць тое, што атрымана.

Ён захоўвае структуру і паходжанне інфармацыі, якой абменьваюцца.

Ён звязвае гэтую інфармацыю з адпаведным інцыдэнтам.

І, што вельмі важна, ён дазваляе аператыўным асяроддзям з абодвух бакоў заставацца абароненымі.

Вам не трэба адкрываць свае сістэмы, каб удзельнічаць у лічбавай каардынацыі інцыдэнту. Вам трэба толькі перадаць тую інфармацыю, якой вы вырашылі падзяліцца, праз кантраляваныя сярэднія дзверы.

Ад інтэграцыі сістэм да каардынацыі інфармацыі

Гэта змяняе тое, як мы думаем пра ўзаемадзеянне ў кіраванні інцыдэнтамі.

Мэта не ў тым, каб змясціць кожную арганізацыю ў адну велізарную сістэму.

Мэта не ў тым, каб даць усім доступ да дадзеных усіх астатніх.

І мэта не проста ў тым, каб падключыць як мага больш API.

Мэта — дазволіць правільнай інфармацыі бяспечна перамяшчацца паміж арганізацыямі, у структураванай форме, у той момант, калі яна становіцца аператыўна карыснай.

Часам гэта азначае прыцягненне спецыялізаваных звестак ад універсітэта або даследчай арганізацыі ў аператыўную карціну.

Часам гэта азначае, што паліцыя, хуткая дапамога, пажарная служба або іншая арганізацыя, якая рэагуе, атрымлівае магчымасць адправіць структураванае аператыўнае абнаўленне з уласнага дыспетчарскага цэнтра непасрэдна ў міжведамасны інцыдэнт.

Часам гэта азначае прадастаўленне ўпаўнаважаным членам каманды інцыдэнту бяспечнага шляху назад да больш дэталёвай інфармацыі, якая захоўваецца ў спецыялізаванай знешняй сістэме.

У кожным выпадку прынцып застаецца тым жа.

Арганізацыя-крыніца захоўвае кантроль над тым, чым і калі яна дзеліцца.

Прымаючай арганізацыі не патрэбны неабмежаваны доступ да сістэмы-крыніцы.

Знешняй арганізацыі не патрэбны неабмежаваны доступ да цэнтральнага інцыдэнту.

Інфармацыя застаецца лічбавай і структураванай, а не непатрэбна перакладаецца з сістэмы ў гутарковую мову, а затым назад у іншую сістэму.

А ORDU Connect знаходзіцца паміж гэтымі асяроддзямі як кантраляваныя сярэднія дзверы.

ORDU Console застаецца абароненым асяроддзем, у якім каардынуецца міжведамасны інцыдэнт.

ORDU Connect забяспечвае кантраляваны мост, праз які давераныя арганізацыі і сістэмы могуць дадаваць уклад у гэтую аператыўную карціну.

Таму што эфектыўная міжведамасная каардынацыя залежыць ад абмену інфармацыяй.

Гэта не павінна патрабаваць адкрыцця вашых лічбавых дзвярэй.

А калі інфармацыя ўжо існуе ў лічбавым выглядзе, гэта не павінна залежаць ад чытання яе па тэлефоне з надзеяй, што на другім канцы яе правільна запішуць.