Привет, друзья! Меня зовут Дмитрий, и я инженер отдела Compliance и безопасности данных в Ozon. Моя работа сфокусирована на разработке, введении и при необходимости модернизации требований ИБ к контрагентам, выстраивании процессов взаимодействия с партнёрами. Давайте сделаем наше общение сегодня проще, т.е. избежим технических терминов и строчек кода и поговорим о более важном — о том, где хакерские атаки порой выглядят как отточенные сцены из лучших криминальных драм. Реальные атаки на цепочку поставок могут подкосить даже самую успешную компанию. И с этим можно/нужно что-то сделать.

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

Представьте: вы — крупная компания (и неважно, маркетплейс или производственное предприятие). Вокруг вас кружится хоровод из поставщиков, разработчиков ПО и прочих партнёров. Казалось бы, живи и радуйся — бизнес процветает! Но не тут-то было.

Помните, как раньше хакеры работали? Напрямую, без затей — нашёл уязвимость, воспользовался. И ведь работало (сейчас такое тоже имеет место быть)! Но времена изменились. Крупные организации поднаторели в информационной безопасности: наняли больше специалистов, внедрили новые процессы, укрепили защиту.

И что в итоге? Атаковать напрямую стало делом почти нереальным. Теперь для этого нужны не одиночки-хакеры, а целые организованные группировки. Но это уже другая история…

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

В названии статьи присутствует аббревиатура KYC. Раскроем значение термина — «Знай своего клиента» (англ. know your customer, сокращённо KYC). 

Ещё нам будет встречаться такой термин как SDLC (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения. Это структурированный подход к созданию программных продуктов, охватывающий все этапы от зарождения идеи до вывода готового продукта на рынок и его дальнейшей поддержки.

Основные риски и угрозы при взаимодействии с внешними исполнителями

«А что тут может быть опасного?» — спросите вы. Действительно, всё выглядит так просто: компания заказывает услугу, оплачивает счета, получает результат — и все счастливы. Проект закрыт, все довольны. 

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

Например, такая ситуация: ваша компания решает подключиться к электронному документообороту (ЭДО). Вроде бы ничего страшного, но что, если в компании-разработчике ЭДО не реализованы базовые процессы информационной безопасности? А может быть, нарушены фундаментальные принципы безопасной разработки (SDLC)?

На первый взгляд всё может казаться спокойным. Никаких явных проблем не возникает. Но это лишь затишье перед бурей. Дальше события могут развиваться по нескольким сценариям взлома:

• через закладки в поставляемом ПО;

• через полученные подрядчиком доступы к инфраструктуре заказчика; 

• через уязвимости в системах интеграции.

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

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

Помните: безопасность — это не просто модный тренд, а необходимость. И начинать нужно именно с контроля взаимодействия с внешними исполнителями.

1. Нормативно-правовая база

А как же нормативное регулирование, законы и требования? 

Знаете, как бывает — в других сферах ИБ уже всё зарегулировали на максимум (или почти): ФЗ-152, ФЗ-187, ГОСТ 57580 — и это только начало списка! А вот с состоянием ИБ у подрядчиков всё как-то неточно и размыто.

По сути, точечных нормативных документов немного. Из всего многообразия можно выделить только два более-менее вменяемых стандарта: ISO 27036 и кусочек из CIS Controls (секции 15.1-15.7). С изучения этих документов, пожалуй, можно начать свой путь, чтобы хоть как-то понять, что к чему. 

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

• Для подкрепления этой проделанной работы обратимся к CIS Controls. Как одна из лучших практик, в этом документе описаны требования к самым разным процессам в компании и наложены на их масштаб. Нас же тут интересует только выделенный фрагмент по контрагентам в разделах 15.1-15.7. Деталей, как это выполнить в фреймворке, не приводится, указано только кратко. 

Если вы доплыли до этого момента, могу смело сказать, что разминка выполнена очень хорошо :-). А вот что с этим прекрасным делать дальше — об этом в следующих главах.

Реальность vs Документация

Честно говоря, когда я погрузился в эту тему, начитался разных стандартов и документов, то понял — чёткого понимания, что делать, там нет. Всё как-то размыто и неконкретно.

Поэтому Ozon озадачился проблемой и решил действовать по-простому — отталкивались от трёх вещей:

• своего видения проблемы;

• тех инструментов, что были под рукой;

• информации, которой реально располагали.

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

В отличие от коллег из службы безопасности (в других компаниях это может быть подразделение экономической безопасности), мы не можем использовать инструменты и сервисы для проверки. 

И третья вещь — это длительность и затратность проверок партнёров для бизнеса. 

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

Категоризация подрядчиков

А много ли подрядчиков в ERP-системе? Мы тоже сначала были поражены огромным количеством. Попытались охватить всех — и быстро поняли, что это нереально. А главное — не нужно.

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

Категории, попавшие в «проверяем»:

• разработка ПО и сайтов;

• крупные 3PL;

• поставщики ПО;

• АКЦ;

• тревел и командировки;

• страховые и прочие бенефиты;

• прочие (список категорий сокращён для статьи).

Категории, попавшие в «не смотрим»:

• партнёры по офертам;

• закупка железа;

• закупка proxy-адресов;

• закупка предметов АХО (в т.ч. плёнка, упаковка и схожие группы товаров) / сервисы обслуживания;

• заказ рекламы (ТВ, наружка и т.д.); 

• поставка ГСМ (в т.ч. ремонт ТС);

• прочее (список категорий сокращён для статьи).

И знаете что? Живут эти категории уже больше года, и всё нормально! Виды оказываемых услуг и сервисов подрядчиков формируем и пересматриваем постоянно, но сильно дробить не стали — используем общеизвестные названия: ЦОДы, разработка ПО и сайтов, ЭДО и другие. 

2. Предварительная проверка

«А зачем нам эти категории?» — спросите вы. Всё просто — чтобы понимать, кто интересен в первую очередь, а кого не будем изучать и проверять.

Коллеги по экономической безопасности работают с минимумом данных — ИНН компании и всё. Они успешно могут найти подробную информацию о собственниках, судах и банкротствах. А у нас в ИБ всё не так радужно — проверять в системах особо негде. Ну что делать? Т.к. единых баз по контрагентам с оценками ИБ или, как сейчас говорят, кибербезопасности пока нет, значит нужно самостоятельно проводить оценку.

3. Анализ мер ИБ контрагента

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

Начнём с самого начала — с базовой Анкеты ИБ. Эту штуку мы просим заполнить всех, кто попал в категорию «проверяем». Сейчас эти данные живут в нашей собственной ERP-системе, но к этому мы шли долго и тяжело…

Что собираем в базовой анкете? Да ничего особенного:

• корректные данные компании (название, ИНН);

• реквизиты сайта;

• ссылки на Политику конфиденциальности;

• контакты ответственного за ИБ;

• суть и формат взаимодействия.

Дальше что?

А дальше начинается самое интересное! Для более глубокого понимания процессов ИБ контрагента мы разработали ещё две анкеты:

• расширенная анкета ИБ — когда нужно глубже «копнуть» во внутренние процессы;

• анкета поставщика/разработка ПО — для изучения процессов SDLC.

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

Анкета поставщика/разработчика ПО сужает наш интерес до понимания процессов безопасной разработки, таких как пентесты, проверка ошибок, сканирования на наличие уязвимостей, обучение разработчиков и другие.

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

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

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

3. Учёт данных

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

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

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

Ключевые достижения в развитии системы учёта:

• внедрение системы меток для категоризации контрагентов;

• возможность выделять партнёров по следующим критериям:

  — наличие заполненной анкеты;
  — статус партнёра с обменом критичной информацией;
  — разработчики и/или поставщики ПО;

• фиксация информации о выданных учётных записях;

• отметка об инциденте, связанном с контрагентом, и отсылка к его обсуждению;

• информационное поле для сопутствующей информации с чёткой разграниченной ролевой моделью (посторонние глаза тут не нужны).

Важный результат — полный переход от разрозненного хранения данных в вики-системе и отдельных хранилищах к централизованной учётной мастер-системе. Это позволило:

• обеспечить единый формат хранения информации;

• упростить процесс поиска и обработки данных;

• создать основу для дальнейшего развития системы категоризации контрагентов;

• повысить эффективность работы с партнёрской базой.

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

4. Реагирование на инциденты

«А при чём тут инциденты?» — спросите вы. Ответ становится очевидным, если взглянуть на статистику 2024 года, когда компании столкнулись с резким ростом инцидентов именно при работе с контрагентами. Причины были разными, но суть проблемы всегда сводилась к одному — необходимости выявления причин и долгого поиска контактов у компании. 

Что требовалось выяснить в первую очередь:

• является ли компания нашим действующим контрагентом;

• действуют ли между нами договорные отношения;

• существуют ли учётные записи для данного партнёра;

• выданы ли ранее сетевые доступы.

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

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

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

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

5. Контрагент и его «хвосты»

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

• статус контрагента — подтверждение, что компания является нашим действующим партнёром;

• документальное обеспечение — наличие и статус договоров, а также других юридически значимых документов;

• учётные записи — информация о созданных учётках и их привязке к конкретной компании;

• сетевые доступы — данные о предоставленных сетевых привилегиях;

• доступы во внутренние системы — информация о разрешениях в системе управления идентификацией.

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

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

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

Для решения этой проблемы был реализован комплексный подход:

• внедрено обязательное согласование создания учётных записей с ИБ;

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

• реализована интеграция с мастер-системой контрагентов;

• внедрена предварительная проверка наличия подрядчика в системах.

Мастер-система учётных записей постоянно развивается и совершенствуется. Сейчас в 99.99% случаев создание партнёрской учётки происходит при наличии уже установленных договорных отношений. 

После нескольких месяцев работы мы достигли существенного прогресса в решении проблемы соответствия учётных записей компаниям-подрядчикам. Если ранее поиск достоверной информации, какая учётная запись принадлежит какой компании, занимал время и имел неточный уровень соответствия, то теперь это можно было установить точно, т.к. была реализована привязка «УЗ = компания». Однако работа продолжается — впереди новые этапы автоматизации и оптимизации процессов. 

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

6. Документационное обеспечение

Договоры и соглашения по информационной безопасности

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

Отдельно стоит отметить ТЗ с требованиями по ИБ — они разрабатываются индивидуально, особенно для сложных тендеров. Важно отметить, что процесс требует координации между различными подразделениями:

• информационной безопасностью;

• бизнес-подразделениями;

• закупками;

• юридической службой;

• другими заинтересованными подразделениями.

Политики безопасности и регламенты взаимодействия

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

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

• самоанализ — вы лучше осознаете собственные действия;

• методологическая база — процессы становятся фундаментом для развития;

• коммуникация — коллегам проще понять, что сделано и что предстоит.

Как верхнеуровневый документ рекомендуется использовать Политику безопасности контрагентов. Она может быть как отдельным документом, так и частью общей Политики ИБ. Главное — зафиксировать:

• цели и задачи;

• направления деятельности;

• укрупнённое описание планируемых действий.

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

Не менее важно:

• своевременно доводить информацию до коллег;

• собирать обратную связь;

• вовлекать новых участников в процесс;

• организовывать обсуждения и согласования.

Такой подход позволит создать эффективную систему документирования, которая будет способствовать развитию процессов информационной безопасности и их лучшему пониманию всеми участниками.

7. Заключение

Сделано довольно много, но ещё есть, куда расти и к чему стремиться.

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

Куда двигаться дальше

Признаться честно, нам есть что улучшать. В ближайших планах:

• разобраться в закупочных процедурах;

• взять под контроль все доступы и учётки, т.е. иметь полноценную информацию и оперативный доступ к ней;

• навести порядок в классификации подрядчиков;

• автоматизировать скоринг;

• собрать все знания в одном месте. Базу знаний наполнить и сделать её удобной в использовании. 

9. О будущем

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

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

Если честно, то завершая эту статью про KYC, мы начинаем писать новую — которой непременно поделимся, наработав объём и практику. Не самая простая тема, но важная как никогда. Тут без системного подхода и постоянного внимания никак не обойтись.

В общем, работы ещё прилично, но главное — мы уже в пути и движемся в правильном направлении. И это уже неплохо, согласитесь?