Безпечне підключення третіх сторін до активного інциденту без розкриття інциденту

Масштабні інциденти рідко обмежуються інформаційними межами однієї організації.

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

Водночас цінна інформація може надходити від організацій, які взагалі не беруть участі в керуванні інцидентом.

Університети, дослідницькі організації, системи екологічного моніторингу, постачальники інфраструктури та спеціалізовані сервіси моделювання можуть володіти інформацією, яка суттєво покращить ситуаційну обізнаність.

Це дуже різні відносини, але вони створюють спільну проблему:

Як дозволити довіреним третім сторонам надавати інформацію щодо активного багатовідомчого інциденту, не надаючи їм зайвого доступу до центральної системи управління інцидентами і не вимагаючи від них у відповідь відкривати власні системи?

Це одна з проблем, яку ми вирішуємо за допомогою 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 забезпечує контрольований міст, через який довірені організації та системи можуть долучатися до цієї оперативної картини.

Адже ефективна багатовідомча координація залежить від обміну інформацією.

Це не повинно вимагати відкриття ваших цифрових дверей.

А якщо інформація вже існує в цифровому вигляді, вона не повинна залежати від того, чи прочитають її по телефону і чи правильно її запишуть на іншому кінці.