Кто отвечает за информационную безопасность на предприятии

Самые опасные уязвимости на производстве находятся не в коде, а в головах и в организационной структуре. Главный инженер считает, что безопасность — дело ИТ-отдела, ИТ-отдел уверен, что АСУ ТП — не его вотчина, а оператор станка понятия не имеет, как выглядит фишинг. В результате системы годами работают без обновлений, а инциденты замалчиваются, чтобы «не подставлять коллег».

Сегодня мы говорим с Игорем Краевым, генеральным директором компании «Стратегия РА», о том, как поделить ответственность, не разрушив производство, и почему профилактика с сотрудниками работает лучше любого сетевого экрана.

 Игорь, в прошлых статьях мы говорили про технику. Сегодня давайте про людей и про оргструктуру. Почему организационные риски часто страшнее вирусов?

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

В результате образуются «слепые зоны» — участки, за которые не отвечает никто. Например, контроллер станка. Технически это компьютер, но ИТ-шникам туда лезть нельзя («это технология»). Технологи говорят: «Мы запускаем станок, а за вирусы пусть айтишники отвечают». Идеальная среда для диверсии.

Давайте разберем эти «слепые зоны» предметно. Что конкретно угрожает предприятию и как выстраивать работу с людьми?

1. Нарушение границ ответственности (АСУ ТП — ИТ — ИБ)

Ситуация: на заводе автоматизированная система управления технологическим процессом (АСУ ТП) подчиняется главному инженеру. Он не подчиняется ИТ-директору и уж тем более — специалисту по информационной безопасности. ИТ-служба отвечает за «офис», но не имеет доступа к промышленным контроллерам. Когда на станке появляется вирус, главный инженер его скрывает, потому что боится, что ИТ-шники «положат» ему производство своими обновлениями. Вирус живет годами.

Практический совет: матрица RACI и «технологический спецназ». Нужно не делить зоны, а создавать смешанные команды с жесткой матрицей ответственности.

• Матрица RACI (или по русски РУКИ) для каждого актива: для каждого элемента АСУ ТП (контроллер, сервер сбора данных, рабочая станция оператора) необходимо письменно зафиксировать: кто отвечает за его работоспособность (Р), кто утверждает (У) изменения, кого консультируют (К) и кого просто информируют (И). Это снимает 90% конфликтов.
• Интегрированные бригады: раз в квартал создается совместная группа из ИТ-специалистов, технологов и приглашенного аудитора (партнера). Они ходят по цеху и смотрят на систему глазами друг друга. Технолог показывает, как работает станок, ИТ-шник показывает, где там сеть, аудитор задает неудобные вопросы. Это ломает барьеры.
• Единый центр компетенций: если внутри компании наладить взаимодействие не получается (а это бывает в 80% случаев), нужен внешний арбитр — партнер, который имеет мандат на проведение регулярного аудита безопасности АСУ ТП. Он не подчиняется ни главному инженеру, ни ИТ-директору, он подчиняется гендиректору и говорит правду.

2. Недостаточная квалификация персонала (операторы, технологи)

Ситуация: оператор станка — это классный специалист, который 20 лет работает с металлом. Он знает, как резать, точить и варить. Но он понятия не имеет, что такое фишинг. Ему приходит письмо: «Срочно перейдите по ссылке, чтобы получить премию». Он переходит, вводит пароль, и вирус попадает в сеть АСУ ТП. Или он видит, что станок работает странно, но думает: «старение металла», а не «заражение контроллера».

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

• Регулярные фишинг-симуляции: раз в месяц служба безопасности (или внешний партнер) запускает фишинговую рассылку по цеху. Письма маскируются под премии, приказы, смешные видео. Кто перешел по ссылке — получает не выговор, а приглашение на получасовой тренинг. Через год таких рейдов процент кликабельности падает с 30% до 2%.
• Стенды-тренажеры: в учебном классе или прямо в цеху ставится станок-симулятор, на котором моделируются различные сценарии: «экран погас», «температура скачет», «контроллер не отвечает». Задача оператора — не просто починить, а определить: это поломка или атака? И кому докладывать?
• Карточки действий: у каждого оператора под стеклом на пульте должна лежать ламинированная карточка: «Если система ведет себя странно — не выключай, позвони по этим трем номерам». Номера: дежурный инженер, ИТ-безопасность, внешний партнер. Это снимает панику и страх наказания.

3. Сложность обновления и обслуживания (вендорский риск)

Ситуация: производитель оборудования (Siemens, Schneider Electric и др.) выпустил критическое обновление безопасности для контроллера. Но его установка требует остановки линии на 8 часов. Начальник цеха говорит: «У меня план горит, ставьте в следующий месяц». «Следующий месяц» длится годами. Вендор снимает оборудование с поддержки, но оно продолжает работать, накапливая критические уязвимости.

Практический совет: Управление жизненным циклом и «золотые образы». Здесь нужна не героическая установка всех обновлений, а системное планирование.

• Реестр устаревания: внешний партнер ведет реестр всего оборудования с датами окончания поддержки. За 6 месяцев до «смерти» железа начинается проектирование замены. Это не аврал, а плановая работа.
• Технологические окна: в годовом плане производства должны быть зарезервированы «технологические окна» — время, когда линия гарантированно стоит (профилактика, отпуска, Новый год). Эти окна закрепляются за обновлениями безопасности. Если окно наступило, а обновление не готово — это ЧП для службы главного инженера.
• Песочница для вендора: ни одно обновление от вендора не ставится на живую линию сразу. Сначала партнер разворачивает его в своей лаборатории (или в виртуальной копии заказчика), гоняет неделю, смотрит, не ломает ли оно техпроцесс. Только после этого — установка в технологическое окно с обязательным планом отката за 15 минут.

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

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

Партнер приходит со стороны и делает три вещи:

1. Аудит коммуникаций: партнер смотрит не на настройки сетевого экрана, а на то, кто кому и когда пишет письма. Есть ли регламент взаимодействия при инциденте? Знает ли оператор номер телефона дежурного ИБ-специалиста? Проверяется это просто: имитируется инцидент и засекается, через сколько минут технолог позвонит айтишнику. Норма — 3 минуты. Часто бывает 3 часа или «никогда».
2. Регулярные тренинги для всех уровней: чтение лекций в лектории — не самый лучший способ просвещения. Необходимо проводить «штабные игры». Собирайте в комнате главного инженера, ИТ-директора, начальника цеха, операторов. Давайте вводную: «Через час на вашем заводе остановится компрессорная станция из-за вируса. Ваши действия?». И смотрите, кто кому что говорит. Обычно выясняется, что у них нет даже общего чата.
3. Поддержание «активной фазы»: безопасность — это не проект, а процесс. Через месяц после такого тренинга все забывают, чему учились. Поэтому партнер берет на себя функцию «будильника». Раз в квартал — проверка знаний, раз в полгода — учения, раз в год — полный пересмотр матрицы ответственности. При таком подходе в организации никто не расслабляется.

То есть партнер нужен, чтобы напоминать о безопасности?

– Не только напоминать. Чтобы снимать конфликты. Когда внешний эксперт говорит главному инженеру: «Ваш оператор не отличает фишинг от премии, и это ваша зона ответственности, потому что вы его наняли», — это воспринимается спокойнее, чем если бы то же самое сказал внутренний ИБ-специалист. Партнер — это «третейский судья» и «носитель лучших практик» со стороны.

Как измерить, что организационные риски снижаются? Есть ли цифры для «человеческого фактора»?

Да, и они проще, чем кажется.

1. Время реакции на инцидент: от момента, когда оператор увидел странность, до момента, когда информация дошла до ответственного за ИБ. Норма — менее 15 минут. Измеряется учениями.
2. Процент прохождения фишинг-тренингов: количество сотрудников, которые перестали кликать на подозрительные ссылки, от общего числа обученных.
3. Количество скрытых инцидентов: если после введения системы анонимных сообщений (внешний партнер дает «горячую линию») количество заявок от цеха выросло, а количество аварий упало — значит, люди перестали бояться и начали сообщать. Это лучший показатель.
4. Время утверждения обновлений: срок между выходом патча от вендора и его установкой на производстве. В здоровой организации это дни или недели. В больной — годы.

Игорь, спасибо. И последнее: почему директора заводов до сих пор считают организационные риски второстепенными?

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

Но цена организационного хаоса — это не утечка данных, а остановленный завод. Когда из-за того, что технолог побоялся сказать про странный гул в серверной, сгорел трансформатор. Или когда из-за конфликта ИТ и АСУ ТП вирус полгода гулял по сети и в итоге убил контроллер.

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