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

В этой статье я предлагаю поразмышлять над тем, в каких ситуациях CISO не виноват и какие правильные выводы стоит сделать в этих случаях. Собственно, а почему возникла эта тема? Просматривая различные материалы о том, какую ответственность несли руководители ИБ в случае возникновения инцидентов, приходишь к выводу, что бизнес хочет, чтобы не было «не единого разрыва взлома». В связи с этим получается, что работа CISO достаточно нервная, и, как утверждает Алексей Лукацкий в своем выступлении пятилетней давности, руководители ИБ из‑за излишне нервной работы нередко злоупотребляют некоторыми веществами и напитками. Но давайте все‑таки попробуем понять, в каких ситуациях руководитель ИБ действительно виноват, а когда нет.

Условия задачи

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

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

Здесь то, кто в итоге будет наказан, ИТ или ИБ, определяется многими факторами: близость к руководству компании, красноречие, напористость, умение убеждать и другие soft skills. И кстати, очень часто всех подобная ситуация устраивает, хотя это в корне неверный подход.

Но возвращаясь к нашей теме: если у вас в компании нет разделения между ИТ и ИБ, то начинать нужно с четкого определения — какие обязанности выполняют сисадмины, а какие безопасники. Например, хорошей формулой считается следующая: у администраторов есть все права, необходимые для выполнения рабочих задач на серверах и сетевом оборудовании, но они не могут изменять настройки аудита и чистить логи. То есть они, конечно, могут выполнить эти действия, но в журналах событий систем будут созданы соответствующие записи. ИБ в свою очередь не имеют административных прав в системах, но у них есть права на просмотр логов в любой из систем (AD, сетевое оборудование, БД и другие). В результате ИБшники не могут нанести какой‑либо ущерб действующим ИТ-системам, но могут вести мониторинг всех событий. А ИТшники могут выполнять любые действия в своих системах, но их действия будут находиться под постоянным наблюдением.

Когда есть не все

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

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

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

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

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

Другой вариант: все необходимые системы уже развернуты. У нас есть межсетевое экранирование, обнаружение атак, антивирусы, EDR и т. д. Но при этом мало внимания уделено так называемой бумажной безопасности. На этом пункте стоит остановиться особо. Многие практикующие безопасники плохо относятся к необходимости соблюдать требования нормативных актов, например, того же ФЗ № 152 или ФЗ № 187, считая, что так называемая «бумажная безопасность» не нужна. Но на практике, во‑первых, у нас есть регуляторы, например ФСТЭК, которые контролируют выполнение этих требований и любая организация, будучи оператором персональных данных, обязана выполнять соответствующие требования. Это тоже зона ответственности CISO.

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

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

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

Все есть, но никто не смотрит

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

Так, когда я работал в интеграции, мы установили у одного заказчика SIEM. Причем не просто установили, но и подключили источники, настроили правила корреляции, провели испытания и обучили их специалистов. Через какое‑то время они попросили нас посмотреть, как работает их SIEM. В процессе анализа созданных инцидентов выяснилось, что их взломали… Наш SIEM честно обнаруживал подозрительные активности, создавал соответствующие инциденты, отправлял уведомления, но никто из ИБ-заказчика не смотрел эти уведомления, не заглядывал в консоль SIEM и в итоге несмотря на то, что продукт, как и другие средства защиты корректно работал, взлом все равно произошел.

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

А если все есть

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

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

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

Заключение

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

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

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

А тем, кто настроен на серьезное системное обучение, рекомендуем рассмотреть Подписку — выбираете курсы под свои задачи, экономите на обучении, получаете профессиональный рост. Узнать подробнее