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

Меня зовут Андрей Нуйкин, я руковожу отделом информационной безопасности ЕВРАЗа. Зона ответственности моей команды — это больше тысячи разработчиков, десятки тысяч пользователей, промышленная инфраструктура, а ещё множество ИТ-подрядчиков. И теперь ещё одна из актуальных болей — сотрудники, которые всё чаще пытаются навайбкодить себе сервисы с ИИ.

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

Сейчас в ЕВРАЗе довольно строгие регламенты по части информационной безопасности — всё, как принято в корпоративном секторе. Наш отдел сопровождает разработку программы или сервиса на каждом этапе: от постановки технического задания и проектирования архитектуры до ввода в промышленную эксплуатацию. Как я уже упоминал, по этим правилам работают и сотрудники компании, и наши подрядчики, когда разрабатывают для нас решения.

Когда я выступаю на ИТ-конференциях и рассказываю про работу с разработчиками и подрядчиками, мне часто задают один и тот же вопрос: «Как вам удалось заставить их выполнять эти правила?» На самом деле мне не близка такая постановка вопроса. Мы всегда за то, чтобы договариваться, идти на компромиссы, подробно объяснять, почему мы ввели то или иное требование. Обычно я рассказываю, что мы ничего не насаждали огнём и мечом. К нашей системе мы шли постепенно и с длинными переходными периодами. Сначала проверяли только часть проектов и работали лишь с критическими уязвимостями. Потом добавили уязвимости среднего уровня. Постепенно руководители попросили нас отсматривать все проекты компании. И мы организовали ту систему, о которой я расскажу подробно чуть дальше.

К тому же изначально в ЕВРАЗе никто не сомневался в том, что информационная безопасность должна быть усилена. Я пришёл в компанию в 2014 году. Первые три года я был единственным сотрудником в отделе ИБ (другие специалисты ИТ, конечно, тоже отвечали за мероприятия ИБ, но этого было мало). А в 2017 году нашу компанию, как и многие другие крупные бизнесы, затронул вирус Petya. Последствия атаки ощутили на себе многие сотрудники.

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

Но для начала давайте посмотрим, как у нас всё организовано.

Как устроен изнутри ИБ-отдел в ЕВРАЗе

Оргштатная структура очень простая. Есть вице-президент по ИТ. Ему подчиняется отдел обеспечения безопасности информационных систем. 

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

Как мы участвуем в разработке и согласовании ИТ-решений? 

Для начала мы разработали и утвердили инструкцию, которая содержит требования к внедряемым информационным системам. Она доступна всем руководителям проектов и ИТ-специалистам. Как начинается любая разработка? Бизнес запрашивает новую систему — то есть попросту говорит: «Нам нужен сервис, где всё происходит вот так». Это ещё не техзадание, а функциональные требования. Далее ИТ-специалисты формируют предложение на реализацию проекта (ПРП), где фиксируется, что надо сделать сервис с конкретным функционалом, на определённом стеке. Затем в комитете по информационным технологиям согласовывается проект, бюджет и так далее.

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

Работы ведут либо внутренняя разработка — специалисты «ЕвразТехники», либо внешний подрядчик. С внешним подрядчиком заключается договор, выдаются и учитываются доступы. В договоре есть пункт о присоединении к стандарту по ИБ ЕВРАЗа для подрядчиков. 

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

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

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

Когда разработка завершена, команда заявляет о необходимости перевода системы в опытную эксплуатацию. В системе управления проектами на моменте перевода на следующий этап предусмотрена галочка от ИБ-отдела. Коллеги приходят к нам с результатами анализатора кода, что и как сделано. Мы проверяем, что первоначальные договорённости не изменились и всё соответствует требованиям, и, если уязвимостей нет, мы ставим галочку о прохождении проверки. После этого проект можно переводить в опытную эксплуатацию.

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

Паспорт заполняет руководитель проекта. Затем все подразделения, участвующие в эксплуатации системы, ставят свою «визу», что с их стороны вопросов нет. Когда паспорт согласован, система переводится в промышленную эксплуатацию.

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

Как мы работаем с кейсами разработчиков

Возвращаясь к вопросу, который мне задают на ИТ-конференциях: «Как вы заставили их так работать?». К сожалению, ИБ-команды часто видят бюрократов, которые приходят и заставляют всех выполнять кучу требований, часто не имеющих под собой достаточно оснований. Что же, давайте посмотрим, какие минимальные последствия влечёт за собой отключение чего-то «не очень нужного».

У нас недавно был случай. Сейчас идёт цифровизация, много сервисов делается, в том числе публичных. У нас есть жёсткие требования по архитектуре: общение с интернетом только через DMZ, наличие средств защиты — WAF (Web Application Firewall), анти-DDoS, антивирус — всё по классическим канонам. Разработчики долго не хотели приводить систему в соответствие с требованиями ИБ. Они уже что-то сделали, но без DMZ и т. д. Говорили, что у них всё хорошо. Но после того, как объяснили и показали возникающие риски, в конце концов они согласились и привели систему в соответствие с требованиями ИБ. Потом они долго на нас ворчали: «Из-за вашего WAF время реакции сервиса слишком большое». Просили выключить WAF: «Он нам не нужен, у нас и так всё безопасно». Но здесь мы были непреклонны. 

И тут случился момент, когда мы переключали WAF на другую платформу. И его временно отключили с этого сервиса на время миграции. 

Каково же было удивление, когда через три недели те же самые разработчики приходят к нам и говорят: «Слушайте, включите обратно». Мы спрашиваем: «А что так? Вы же говорили, что он мешает, всё замедляет». А они: «За эти три недели к нам пришло столько ботов, столько всего налезло… Верните обратно. Мы поняли, зачем вы это делали».

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

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

В целом я не поддерживаю подход, где мы просто запрещаем использовать что-либо. Сегодня искусственный интеллект внедряется везде — с этим ничего не сделаешь, но нужно вырабатывать новые правила и подходы. В частности, как контролировать информацию, которую люди передают в ИИ, и как быть с тем же вайбкодингом. Как это всё происходит, какие права давать? Грубо говоря, нам нужно те процессы, которые раньше мы выстраивали для полутора тысяч разработчиков, теперь масштабировать на всех пользователей. И как-то контролировать то, что сотрудники накодили в рамках своей работы с помощью ИИ.

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

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