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

Крупные инциденты редко существуют в информационных границах одной организации.

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

При этом ценная информация может поступать от организаций, вообще не участвующих в управлении инцидентом.

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

Это совершенно разные типы отношений, но все они порождают одну и ту же проблему:

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

Именно эту задачу мы решаем с помощью ORDU Studio и, в частности, ORDU Connect.

Обмен информацией не требует общего доступа

Легко представить межведомственный обмен информацией как проблему прав доступа.

Добавить каждую участвующую организацию как пользователя. Выдать учётные записи. Ограничить, что они могут видеть.

Или подойти к задаче с противоположной стороны и подключиться напрямую к системам каждой организации, дав центральной платформе право получать нужные ей данные.

Оба подхода потенциально расширяют границу безопасности.

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

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

Необходимость поделиться одним фрагментом информации не должна превращаться в необходимость раскрыть всю систему целиком.

Поэтому ORDU рассматривает предоставление информации, получение информации и доступ к системам другой организации как отдельные понятия.

Организация может вносить вклад в общую оперативную картину, не становясь пользователем ORDU Console.

ORDU может получать информацию от организации, не получая доступа к её внутренним системам.

Это разделение лежит в основе архитектуры ORDU Connect.

Проверенные защищённые сторонние поставщики

В ORDU Studio доверенных внешних поставщиков информации мы называем Secured Verified Third-Party Providers, или 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 обеспечивает контролируемый мост, через который доверенные организации и системы могут вносить вклад в эту оперативную картину.

Потому что эффективная межведомственная координация зависит от обмена информацией.

Это не должно требовать открытия ваших цифровых дверей.

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