«Давайте потом»: Почему в вашей компании ИТ и безопасность не работают вместе и кто за это заплатит

Красивая бизнес-легенда гласит: где-то в больших корпорациях сидят IT-директор (CIO) и директор по безопасности (CISO). В рамках постоянного конструктивного диалога они ищут баланс между развитием ИТ-составляющей бизнеса и его защищенностью от киберугроз, а генеральный директор выступает мудрым арбитром.

Забудьте.

В среднем бизнесе все выглядит иначе. Никакого диалога или спора там нет. А есть одна тяжелая ситуация, которая звучит так: «Мы ничего не можем сделать, потому что постоянно если не одно, так другое».

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

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

ИТ-отдел выдает доступы к системам. И тут включается человеческий фактор. ИТ понимает: если хакеры (пусть и белые) найдут дыры, вопросы будут к тем, кто администрирует сервера. Значит, нужно подстелить соломки.

Что происходит на деле? Полного доступа с максимальными правами пентестерам не дают — только «на посмотреть». В канун проверки правила безопасности накручивают так, чтобы тест ничего не сломал и ничего не нашел. Процесс тестирования вежливо тормозят: «Ой, а давайте на следующей неделе, у нас обновление».

Итог? Компания платит деньги. Формально отчет есть. Но система сделала все, чтобы уязвимости остались незамеченными. Дыры остались, риски - те же. Просто теперь на руках документ, по которому все чисто и безопасно.

Пентест все-таки случился. Нашли критическую уязвимость - например, вход в базу клиентов без пароля. ИБ говорит: «Это критично, закрываем через час». ИТ отвечает: «У нас релиз / клиентский отчет / пятница, давай потом». CEO отмахивается: «Разберитесь сами, не отвлекайте меня».

Все. Решение растворилось. Риск есть, а работа на его исправление постоянно сдвигается вправо. На неделю. На месяц. На год.

В кибербезопасности слово «потом» всегда означает «после инцидента». Инцидент случается - начинается разбор полетов.

Произошла утечка. Или взлом. Или просто файлы зашифровали. Встал завод, перестал работать склад, клиенты не получают щедро оплаченные услуги. Начинаем искать крайнего. ИТ пожимает плечами: «Мы обеспечиваем доступность серверов. Чтобы мы еще и за кодом/правами следили? Не наша компетенция!». ИБ разводит руками: «Мы предупреждали. Вот переписка за октябрь. Нас не послушали». Гендир кипятится: «Почему я узнаю об этом сейчас, когда сервера лежат, а не тогда, когда можно было что-то решить?!»

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

ИБ говорит: «Так нельзя. Это небезопасно». ИТ говорит: «Нам нужно быстро. Бизнес требует». CEO не вмешивается.

Дальше два пути:

• ИТ обходит безопасность. Заводят сервер в обход всех правил, потому что «так быстрее». Безопасность просто не знает, что этот сервер существует.
• ИТ саботирует. Делает вид, что внедряет требования безопасности, но делает это «для галочки», спустя рукава. Потому что безопасность - это функция запрета, а ее хочется игнорировать.

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

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

При этом у руководителя стойкое ощущение: «У нас маленькая компания, никому мы не нужны. Все нормально».

Проблема в том, что самый дорогой риск - тот, о существовании которого вы даже не догадываетесь.

Во всех этих пяти историях нет злодеев. ИТ не вредители. Они просто защищают себя от ответственности. Если они дадут пентестерам доступ, а те найдут дыру, спросят с айтишников. Легче сделать так, чтобы проверка не состоялась, а то и вовсе «замотать» ее по срокам.

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

CEO не игнорирует. Он просто вне контекста. Ему говорят на двух разных языках - ИТ про сервера, а ИБ про риски. Как из этого принять решение, если ты не айтишник?

Конфликт возникает там, где нет правил игры.

Хорошие новости в том, что вам не нужно загонять ИТ и ИБ в их зоны ответственности уймой регламентов. Достаточно позаботиться о четырех простых вещах. Внедрите их, и 80% проблем исчезнут.

1. Назначьте того, кто принимает риск

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

Это неприятно. Это требует погружения. Но ваше «разбирайтесь сами» приведет к тому, что решение либо не будет принято, либо будет принято в пользу текущей задачи, а риски останутся незакрытыми и будут накапливаться. Когда CEO сам принимает решение «делаем быстро, но понимаем, что можем потерять данные», он кончиками пальцев чувствует, что его решение может значить для компании.

2. Любое пожелание «сделать быстро, а там посмотрим» фиксируем

Не в переписке в мессенджере. А в формате одностраничного документа:

• Какой конкретно риск мы берем?
• Что будет, если он сработает (последствия)?
• Кто именно согласовал этот риск?

Это отрезвляет. Когда нужно написать, что последствиями может стать утечка базы клиентов, и поставить под этим свое письменное согласие, количество «потом» резко снижается.

3. Разделите роли, не усложняя

Забудьте про сложные матрицы ответственности из учебников по менеджменту. Сделайте просто:

• ИТ реализует. Они строят, настраивают, обновляют, запускают проекты.
• ИБ говорит, где опасно. Они проводят оценки, ищут дыры, указывают на последствия.
• CEO решает. Рискуем или нет? Делаем быстро или делаем безопасно?

ИТ не должен решать за безопасность. Безопасность не должна тормозить ИТ своими запретами. У них нет на это права. Право сказать «стоп» или «вперед» есть только у гендира.

4. Нужны факты, чтобы не спорить

Как выглядит типичный спор:

- Это опасно!
- Нет, нормально.
- Да кто тебе сказал?
- Это лучшие практики! Я так вижу!
- Давай потом?..

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

• Что у нас вообще торчит наружу?
• Какие уязвимости реально есть?
• Кто имеет доступ к деньгам и данным?

Это называется «управление активами» и «регулярные сканирования внешнего периметра». Звучит сложно, но на практике это просто подписка на сервис, который раз в месяц присылает CEO понятный отчет: «Вот ваши красные флаги. Вот что делать ИТ. Вот цена вопроса».

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

В среднем бизнесе проблемы с безопасностью начинаются не с хакеров. Они начинаются с фразы «давайте потом».

Пока в компании нет простой модели принятия риска, любая техническая уязвимость - это не техническая проблема. Это управленческая дыра.

И именно эта дыра в итоге обходится дороже всего. Не потому, что хакеры стали хитрее. А потому, что внутри компании так и не решили, кто платит по счетам, если что-то пойдет не так.

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