Андрей Нуйкин, ЕВРАЗ: Контроль ИТ-подрядчиков. Инструменты непрерывной защиты

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

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

Для тех, кто не знаком с деятельностью ЕВРАЗ, поясню: это крупная металлургическая компания, производитель строительного и рельсового проката. Наша сталь в том или ином виде присутствует на множестве объектов по всей стране. У нас три крупные локации – Москва, Сибирь, Урал. Реализуется много проектов, задействовано значительное число сотрудников и ИТ-специалистов.

Новый ландшафт угроз

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

Наша внутренняя статистика за 2023, 2024 и 2025 годы демонстрирует стабильный рост инцидентов на периметре и внутри сетей. Постоянно фиксируются попытки несанкционированных действий. Особенно заметная активизация началась 25 февраля, когда украинская сторона заявила о «подавлении всей промышленности России», при этом ошибочно отождествив промышленность с сайтами-визитками. С того момента атаки не прекращались, а их количество продолжает расти.

Обратимся к общепризнанной базе знаний MITRE ATT&CK, где собираются актуальные техники и методы хакерских атак. Там выделена целая ветка, посвящённая компрометации цепочки поставок – когда взламывают подрядчика и через него проникают к целевой организации. Самый показательный и широко известный случай – вирус-шифровальщик NotPetya в 2017 году, который нанёс ущерб множеству компаний по всему миру. Цепочка началась со взлома украинского разработчика приложения для отправки налоговой отчётности в налоговую службу. Злоумышленники внедрились в цикл разработки, и с очередным легитимным обновлением вирус был распространён среди всех клиентов, а затем продолжил своё шествие по глобальным сетям.

Почему стандартных проверок недостаточно

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

При этом важно различать типы доступа. Если подрядчик работает через веб-интерфейс – например, заходит в личный кабинет торговой или закупочной площадки, в систему динамического дисконтирования, – мы не предъявляем ему описанных ниже жёстких требований. Безопасность в таких случаях обеспечивается на уровне архитектуры самого личного кабинета. Наши требования распространяются именно на тех подрядчиков, которые подключаются непосредственно к нашей внутренней сети через VPN, то есть получают прямой туннель.

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

Отмечу также, что мы последовательно развиваем собственные компетенции: в компании около двух с половиной тысяч ИТ-специалистов, из которых более половины занимаются разработкой. Ежегодно реализуется 150–200 проектов цифровизации. В тех случаях, где проекты носят долгосрочный характер и требуют постоянной поддержки, мы стремимся выполнять работы собственными силами.

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

Шаг первый: разработка реалистичных требований по ИБ

Первым делом мы выпустили требования по информационной безопасности для подрядчиков. Первоначальная версия (по сути, первый черновик) насчитывала 27–28 страниц. Когда мы совместно проанализировали документ, то пришли к выводу, что с такими требованиями у нас не останется ни одного подрядчика. Им могли бы соответствовать разве что крупнейшие компании вроде Газпрома, Сбера или Росатома, но не обычные организации.

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

Особую значимость мы придали двум пунктам.

Первый – информирование об инцидентах. Если у подрядчика происходит инцидент, он должен сообщить нам в сжатые сроки, а не через месяц. У нас были ситуации, когда о происшествиях мы узнавали из новостей или Telegram-каналов. Связываемся с подрядчиком: «У вас всё в порядке?» – «Ну, у нас тут не совсем». А между тем требовалось срочно отключить доступ, заблокировать учётные записи и проверить свою сеть.

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

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

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

Сейчас мы движемся в сторону инструментального контроля – compliance check, при котором VPN-клиент проверяет окружение на соответствие нашим требованиям. К сожалению, российских решений пока немного, мы ведём поиск. Для серьёзных проектов мы запрашиваем результаты аудитов или проводим собственные экспресс-аудиты. Если же мы сейчас расширим базовый перечень в полном соответствии со всеми регуляторными требованиями, боюсь, мы потеряем слишком много подрядчиков. Но даже наличие базового чек-листа заставляет их обращать внимание на информационную безопасность: мы видим, что некоторые приходят повторно, и в чек-листе появляются новые отметки о выполнении требований.

Важный принцип: доступ даётся только к тем серверам и системам, которые действительно необходимы для выполнения работ. Ранее подключившийся сотрудник получал широкие права, аналогичные тем, что есть у него при работе из офиса. Теперь всё иначе: подрядчик указывает: «Мы будем разрабатывать систему №1 на сервере №2», – и мы предоставляем доступ ровно к этому серверу и больше ни к чему.

Кроме того, все выданные доступы строго фиксируются в реестре. Для чего? В случае инцидента мы не действуем в спешке, а открываем реестр и видим, к каким серверам имеет доступ конкретный подрядчик. После этого серверы отключаются, учётные записи блокируются, и организуется реагирование.

Требования к разрабатываемым системам

Отдельное направление – требования по ИБ к самим системам, которые разрабатываются подрядчиками. Как известно, разработчики и бизнес заинтересованы в одном: быстрее создать систему, ввести её в эксплуатацию и начать получать прибыль. Безопасность при таком подходе обычно оказывается в конце списка приоритетов, а иногда отсутствует вовсе. У разных сторон разные ключевые показатели эффективности.

Поэтому мы сформулировали обязательные требования к информационным системам и разослали их всем руководителям проектов. В документе описано, что обязательно должно быть реализовано: процедуры аутентификации и авторизации, ведение журналов событий, использование шифрованных протоколов и так далее. Теперь многие руководители проектов просто копируют наши требования в техническое задание. Подрядчики сразу понимают, что нужно делать, и учитывают это в своей работе. Раньше же нередко возникали ситуации, когда система предъявлялась к сдаче, а её защита оказывалась несостоятельной. Мы говорим: «У вас всё плохо». Ответ: «Проект завершён, бюджет исчерпан, примите систему в таком виде». Чтобы избежать подобного, мы озвучиваем требования на старте.

Мониторинг поверхности атаки подрядчика

Помимо этого, мы подключили сервис мониторинга поверхности атак (Attack Surface Management, ASM) – сейчас существует много отечественных решений, ранее были только зарубежные.

Что делают эти сервисы? Они сканируют периметр подрядчика, проверяют публичные репозитории вроде GitHub и GitLab. Разработчики – люди, они любят демонстрировать свои достижения и выкладывают исходный код, показывая, каких результатов достигли. Нередко в этом коде содержатся логины, пароли, имена серверов и другая ценная информация, которая помогает злоумышленникам подготовиться к атаке. Сервис также проверяет фишинговые феномены – возможно, против подрядчика уже готовится атака, а он об этом не знает. И, конечно, отслеживает утечки в даркнете: был ли взломан сам подрядчик или его субподрядчики, получены ли данные, которые могут быть использованы.

Разграничение ответственности

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

Чтобы исключить такие ситуации, мы всегда подчёркиваем: вы разрабатываете для нас систему и сдаёте её. Система должна быть безопасной. Каким образом вы её строите – ваша задача. Именно для этого вы и наняты. Это, естественно, накладывает дополнительные требования к процессу разработки: одно дело сделать наспех, без должной проработки, другое – обеспечить надлежащее качество.

И второй момент: кто отвечает за обновление? Необходимо чётко распределить ответственность за инфраструктурную часть сервера и за саму систему. Чтобы потом не получилось, что никто не выполняет обновления, уязвимости остаются, и злоумышленники успешно их эксплуатируют.

Управление использованием открытого ПО и внешних сервисов

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

Периодически возникают ситуации, когда сотрудники, стремясь работать быстрее и эффективнее, не обращаются в компанию, а самостоятельно находят в интернете какой-либо сервис, например, Google Docs, и начинают использовать его для работы. У нас такие внешние сервисы заблокированы. Когда о подобных фактах становится известно, мы разъясняем: так делать нельзя, существуют внутренние защищённые ресурсы. Таким образом, самовольная установка невозможна. Приходит заявка в ИТ-службу – мы проверяем, и служба поддержки либо устанавливает ПО, либо отклоняет запрос.

Работа с искусственным интеллектом

Отдельного внимания заслуживает тема искусственного интеллекта. От ИИ никуда не деться, он уже присутствует в нашей деятельности, и его роль возрастает с каждым днём. Когда только появились первые запросы на использование ИИ, мы издали распоряжение: в технологической сети производства запрещено пользоваться внешними моделями – никаких ChatGPT, Claude и аналогичных, только внутренние. Наши специалисты развернули внутреннюю модель evraz.gpt. Она заметно уступает ChatGPT по своим возможностям, но для начальных задач этого достаточно. В корпоративной сети можно пользоваться любыми внешними интеллектуальными сервисами, но категорически запрещено загружать туда ценную информацию.

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

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

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

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

Базовый минимум, который доказал свою эффективность

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

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

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

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

Андрей Нуйкин, начальник отдела обеспечения безопасности информационных систем, ЕВРАЗ