Найти в Дзене
СБ Про Бизнес

Управление безопасностью.

В предыдущей статье мы рассмотрели концепцию обеспечения безопасности, в соответствии с которой в ее основе лежит некое событие – инцидент. Инциденты безопасности условно классифицируются на простые (локальные), причины которых очевидны и могут быть устранены здесь и сейчас и сложные (системные) – их решение требует внесения изменения в бизнес-процессы и внутренние нормативные документы Компании. При этом, под инцидентом мы понимаем событие (в т.ч. возможное), связанное с нарушением требований внутренних нормативных документов, и/или риск/факт коррупции, внутреннего фрода, информация о котором поступила в подразделение безопасности, требующая уточнения в ходе проверки. То есть, в качестве инцидента можно рассматривать не только уже случившееся событие, но и то, которое может произойти в будущем так как к этому имеются предпосылки, то есть гипотеза. Далее, инциденты безопасности регистрируются на специальном ресурсе и отрабатываются (устанавливаются причины и условия, приведшие к событи

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

Инциденты безопасности условно классифицируются на простые (локальные), причины которых очевидны и могут быть устранены здесь и сейчас и сложные (системные) – их решение требует внесения изменения в бизнес-процессы и внутренние нормативные документы Компании.

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

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

Таким образом, подразделения Дирекции безопасности, в рамках текущих активностей осуществляют контроли зон ответственности и выявляют отклонения (инциденты), которые необходимо учитывать, расследовать, накапливать и анализировать.

Ниже приведена возможная схема взаимодействия между структурными подразделениями Дирекции безопасности.

-2

Поскольку часть контролей осуществляется в круглосуточном режиме и может потребоваться реагирования в нерабочее время, представляется целесообразным создание «единого окна» для сбора такой информации, принятия мер по локализации происшествий и информирования о нем ответственных сотрудников и руководство организации. Обычно этот функционал возлагается на Оперативного дежурного Компании (Далее – ОДК) – старшего смены охраны, несущего службу круглосуточно в головном офисе.

При территориально-распределенном расположении объектов, полезно разработать единый формат представления информации о происшествиях и организовать автоматизированный сбор этих данных на дашборд ОДК.

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

Оперативный дежурный (старший охраны) каждого объекта ежедневно заполняет свою таблицу, а значения автоматически подтягиваются ОДК и суммируются за холдинг. Подробности и описание происшествий добавляется в виде примечания.

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

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

Примерный перечень контролей ОДК:

-3

В больших организациях, excel-формата может оказаться недостаточно, поэтому для осуществления мониторинга, контроля ситуаций, анализа данных, информирования и принятия управленческих решений создается Ситуационный центр (Далее - СЦ).
Вот примеры работы СЦ описанные на этом канале (
пример 1; пример 2; пример 3.)

Задачи СЦ:

· обеспечить централизованный круглосуточный мониторинг состояния инфраструктуры объектов;

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

· обеспечить руководство наиболее полной информацией для качественного принятия решений;

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

· оперативно реагировать и устранять проблемы, возникающие в процессе эксплуатации оборудования и систем;

· сократить сроки реагирования на инциденты.

В зависимости от специфики предприятия и особенностей организационно-штатной структуры, он может быть, как единым, так и разделенным, когда инциденты информационной (ИБ) и экономической безопасности (ЭБ) регистрируются и отрабатывается отдельно. Такое дублирование не выглядит критично, так как мониторинг киберугроз, возможно, уже осуществляется круглосуточно силами SOC[1], а инциденты ЭБ могут быть зарегистрированы и на следующий день без потери актуальности. Немедленного реагирования, как правило, требуют инциденты физической безопасности (кража, разбой) или происшествия техногенного характера (аварии на инженерных сетях и т.п.).

Если Ситуационный центр общий, то в целях обеспечения конфиденциальности, права доступа определяются ролями пользователей, а Оперативному дежурному Компании, поступает информация в формализованном виде. Например, «Инцидент ИБ 2 категории, планируемый срок решения 05.11 сегодня, ответственный Иванов О.П.».

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

Отдельно определяется перечень происшествий, доклад о которых руководству производится незамедлительно, а также тех, где оповещаются ответственные за проблемный участок. Формы информационных сообщений лучше шаблонизировать, что с одной стороны обеспечит полноту доклада, а с другой его связность (не все ОДК способны в критической обстановке внятно сформулировать суть возникшей проблемы).

Работа СЦ может быть автоматизирована на основе конструктора сценариев реагирования в зависимости от вида объекта, инцидента и ответственных лиц, участвующих устранении инцидента. В этом идеальном случае система сама направит информационные сообщения по заранее определенному маршруту.

Возможные состав системы СЦ:

· комплекс информационно-аналитических систем (система отображения, сбора и обработки информации, система поддержки принятия решений, система мониторинга)

· система видеонаблюдения

· система контроля и управления доступом

· система охранной сигнализации

· система охранно-пожарной безопасности

· система оперативной связи и оповещения

· рабочие места ОДК и его помощника

· дополнительные системы, принятые на мониторинг.

В этом случае внутренние процессы Ситуационного центра могут иметь такой вид:

-4

… а принципиальная схема построения СЦ такой:

-5

В перспективе, на контроль Ситуационного центра могут быть поставлены и другие параметры (вход/выход и геолокация корпоративного автотранспорта, температурный режим в холодильных камерах и т.п.). При автоматизированной системе реагирования, это не приведет к перегрузке функционала ОДК и снижению эффективности управления инцидентами безопасности.

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

В этой статье сознательно не упоминаются программные продукты на основе которых может быть создан СЦ, так как в каждой компании исторически сформирован набор ПО и сложились определенные предпочтения по используемым платформам. Кроме того, существуют ограничения по возможности интеграции разных информационных систем. За помощью в выборе лучше обратиться к профильным специалистам из Дирекции ИТ.

Учет происшествий в каком-то виде ведется во всех Компаниях. Эта статистика накапливается, сравнивается год к году (Да, да! Тот самый АППГ), на основе изменений в большую или меньшую сторону, делаются выводы о необходимости «усИлить», «углУбить» и/или запросить дополнительные ресурсы – человеческие или материальные. Однако, причины инцидентов (не виновные, а именно, причины) не уславливаются, предпосылки к их повторению не устраняются.

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

Подробно по предпосылках к изменениям в СБ, стратегии и тактике обеспечения комплексной безопасности, управлении рисками, рассказано в книге «Корпоративная безопасность, как бизнес-процесс».

Статья написана специально для канала СБПроБизнес.

[1]
SOC (Security Operations Center) - Центр мониторинга информационной безопасности — структурное подразделение организации, отвечающее за оперативный мониторинг IT-среды и предотвращение киберинцидентов. Специалисты SOC собирают и анализируют данные с различных объектов инфраструктуры организации и при обнаружении подозрительной активности принимают меры для предотвращения атаки.

-6

Выражаем признательность автору статьи Алексею Швецкому!