Корпоративная безопасность, как бизнес-процесс

Управление рисками безопасности

По мере накопления информации в Базе данных инцидентов безопасности, появляется возможность ее анализировать, выявлять наиболее проблемные бизнес-процессы, операции и подразделения, то есть идентифицировать риски. А увидев проблему, мы сможем и предложить ее решение – управлять рисками.

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

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

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

Например, при покупке (поглощении) одной компании другой, реципиент принимает риски, связанные с возможными проблемами интеграции оборудования или бизнес-процессов донора, так как это с лихвой компенсируется суммарным выигрышем от сделки.

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

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

Так, некоторые западные корпорации покинули российский рынок, потеряв прибыть и обнулив достигнутые успехи по захвату его доли, опасаясь санкций США, применение которых могло привести к остановке всего бизнеса (риски функционирования).

Или компания может отказаться от осуществления коммерческой деятельности в стране, где это невозможно делать без передачи взяток местным чиновникам (этические и комплаенс-риски).

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

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

Невозможность дальнейшей деятельности

Несоблюдение требований регуляторов и/или законодательства

Финансовые потери

Сбои в оказании услуг (Value Added Services – VAS)

Отток клиентов (customer lifetime value – CLV)

Иные последствия

Для определения степени влияния выявленных угроз на бизнес, а также возможности митигации, все выявленные угрозы анализируются:

На основании полученных результатов формируется Карта рисков:

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

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

Для этого, выделяем угрозы, которые на наш субъективный взгляд могут возникнуть и также предположительно присваиваем им признаки вероятности и определяем степень влияния на бизнес.

На примере food-retail сети, такая модель может иметь такой вид:

На ее основании, формируем тепловую карту рисков:

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

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

Например, так:

Где,

Трансформация функции безопасности

Сравнив текущее состояние функции безопасности (As Is) и образ желаемого (To Be), пришло время понять, как из одной фазы перейти в другую (How).

Организационно-штатная структура

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

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

В качестве иллюстрации мы будем по-прежнему использовать Дирекцию безопасности гипотетического ООО холдингового типа «Рога и копыта», которая организационно включает в себя:

Дирекцию безопасности Центрального офиса (ДБ ЦО);

Дирекцию безопасности производственного кластера (ДБ ПК);

Дирекцию безопасности региональной сети (ДБ РС).

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

Получаем следующую картину:

Сокращения:

ОДС – оперативно-дежурная служба (ситуационный центр, куда поступает вся информация об инцидентах);

ПБ – пожарная безопасность;

ОТ – охрана труда;

СВН – система видеонаблюдения;

СКУД – система контроля и управления доступом;

ТСО и ПБ —технические средства охраны и пожарной безопасности.

Для большей наглядности, повторяем это упражнение снова, но уже в разрезе подразделений.

На примере ДБ Центрального офиса (штаб-квартира):

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

В завершенном виде, организационно-штатная структура Дирекции безопасности ООО «Рога и копыта» может приобрести такой вид:

Функционал и зоны ответственности:

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

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

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

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

Начальник Отдела безопасности Центрального офиса – отвечает за физическую и экономическую безопасность головного подразделения холдинга. Подчиняется Директору по безопасности холдинга.

Директор по безопасности региональной сети/производственного контура отвечает физическую и экономическую безопасность объектов Компании в зоне ответственности, подчиняется Директору по безопасности холдинга.

При этом, полномочия между подразделениями распределяются следующим образом:

Для более зрелых Компаний, можно предложить такую структуру:

В данном варианте региональные подразделения безопасности подчинены руководителю направления ЭБ, так как основное содержание их работы – проведение расследований, а за этот процесс отвечает именно он. Но на практике чаще региональные (объектовые) подразделения замыкаются непосредственно на руководителя функции.

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

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

На уровне макрорегиона (объекта) структура может быть такой:

Инцидент-менеджмент

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

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

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

Наиболее сложные, имеющие признаки системных рисков, передаются в подразделение (специалистам) экономической безопасности для проведения корпоративного расследования. В филиалах или на объектах, где сотрудник СБ выступает в единственном лице и отвечает за все линии работы, он же проводит и корпоративные расследования, а профильные менеджеры по ЭБ оказывают ему методическую и при необходимости практическую помощь.

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

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

Оперативно-дежурная служба

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

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

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

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

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

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

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

Ситуационный центр

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

Задачи СЦ:

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

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

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

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

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

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

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

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

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

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

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

Состав системы:

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

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

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

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

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

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

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

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

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

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

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

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

Платформа для учета инцидентов безопасности

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

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

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

Описание процесса

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

Кратко описывая суть происшествия:

место события и риск – из выпадающих списков,

фабула – свободное изложение с ограниченным количеством знаков;

Инциденту присваиваются:

порядковый номер;

владелец (инициатор);

контрольный срок решения;

О регистрации нового инцидента система автоматически генерирует оповещения руководителя владельца (согласно прописанному маршруту);

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

Программа автоматически запрашивает у руководителя владельца подтверждение, если отчет принят, инцидент закрывается;

Варианты решений руководителя:

отчет принят

на доработку (с комментарием)

провести расследование.

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

Если инцидент не закрыт после истечения контрольного срока владельцу и его руководителю направляется оповещение.

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

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

Пользователи могут вносить новые и просматривать старые записи (в том числе созданные другими сотрудниками), но без права редактирования или удаления.

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

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

Можно, конечно, вести учет инцидентов и вручную, сформировав Excel-таблицу, но такой подход представляется устаревшим.

Тем не менее, в этом случае набор граф может быть таким:

Желательно подключить набор справочников (списки сотрудников, адреса объектов, классификатор рисков). Это упростит работу и позволит избежать технических ошибок при вводе данных.

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

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

Решение инцидентов безопасности

Решение любого инцидента включает два уровня митигирующих действий:

Локальный уровень реагирования – не допустить утрату информации (или доступа к ней), имущества или других активов, включая такие действия как:

Для ИБ: блокировка канала, шлюза, IP-адреса, учетной записи, рабочей станции и т.п.

Для ФБ: задержание нарушителя, недопущение несанкционированного выноса (вывоза) имущества

Для ЭБ: запрет на взаимодействие с рисковым контрагентом или прием на работу неблагонадежного кандидата.

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

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

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

Системный уровень реагирования требует рассмотрения локального (простого) инцидента в контексте бизнес-процесса для выявления уязвимостей в нем (системный риск) и выработки предложений по их закрытию.

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

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

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

Регистрация инцидента.