Работаю на стороне корпоративных закупок. Почти все инциденты безопасности за последние два года были связаны не с нашими системами, а с поставщиками.
Взломали систему одного из наших поставщиков; напрямую к нашим данным не добрались, но перехватили нашу переписку с ним, а потом нам прислали поддельный счет.
Расскажу, как мы встроили это в процессы закупок и где возникли сложности, дополнения приветствуются.
Очень верное наблюдение. Риски со стороны поставщиков определяют самое слабое звено независимо от уровня зрелости самих компаний.
Предложу применимый фреймворк, который можно встроить в процессы закупок.
Для начала разделите поставщиков по уровню критичности. Те, кто имеет доступ к нашим данным, подключается к нашей системе, и те, кто просто выставляет счета, не могут проходить одинаковый аудит. Рассылка всем одного и того же чек-листа из ста пунктов порождает бюрократию, которую никто толком не заполняет.
Для критически важных поставщиков рекомендую включить в договор следующие пункты: уведомление о инцидентах безопасности в течение определенного срока, раскрытие информации об использовании субподрядчиков, уничтожение наших данных по окончании договора с документальным подтверждением, доступ только через именные учетные записи.
Случай с поддельным счетом — это отдельная тема: здесь проблема не в технике, а в процессах. Изменения платежных реквизитов нельзя принимать только по переписке, их нужно подтверждать по второму каналу через известный номер телефона. Это одно правило предотвращает самый частый вид финансовых потерь.
Со стороны финансов очень поддерживаю этот последний пункт, у нас была почти такая же ситуация.
У нас действует такое правило: если приходит запрос на смену расчетного счета, мы не отвечаем через тот же канал. Звоним по старому номеру из нашей базы. Никогда не звоним по номеру, указанному в письме, потому что он тоже может быть поддельным.
Также ввели порог по сумме: первые платежи свыше определенной суммы проходят с двумя подписями. Да, это замедлило процесс. Но один раз это спасло нас, и этот один раз окупил все усилия.
Со стороны менеджера по работе с клиентами, посмотрю на это с позиции поставщика, потому что такие аудиты приходят и к нам.
Хочу отметить: хорошо подготовленное приложение по безопасности полезно и для поставщика, так как четко обозначает ожидания. А сложность в том, что каждый клиент присылает чек-листы в разном формате и с разным охватом. Одну и ту же информацию мы заполняем по десять раз в году в разных шаблонах.
В качестве предложения: если у вас есть принятые независимые сертификации, скажите об этом сразу. Для поставщиков с сертификатами используйте короткую форму, для остальных — длинную. Это снизит нагрузку и на вас, и на нас.
Дополнение от отдела комплаенса: цепочка субподрядчиков часто упускается из виду при оценке.
Вы проверяете своего поставщика, он передает часть работы другой компании, и ваши данные попадают к ней. Если в договоре нет условия о предварительном уведомлении об использовании субподрядчиков и распространении на них тех же обязательств, значит, вы вообще не видите второе звено цепи.
Есть один момент, который меня интересует. Время обнаружения проблемы напрямую определяет ее стоимость.
Появились три разных мнения они дополняют друг друга. Если путь уведомления длинный уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.
Больше всего времени у нас уходило на то, что было непонятно кто принимает решения. кстати надеюсь это будет полезно.
Редко встретишь текст с такой ясностью изложения. Меры, принятые без инвентаризации, оставляют открытыми двери, о которых вы не знаете.
Начните с небольшого эксперимента, не привязывайте всё сразу. Если напишете результат здесь, это поможет и другим.
Сведу тему в кучу так как ответов было несколько разных. Автоматический отчет о сканировании и пентест — это не одно и то же.
Исправьте если я ошибаюсь.
Сведу тему в кучу так как ответов было несколько разных. Чем сложнее отменить решение, тем медленнее его принимайте.
Надеюсь, это будет полезно.
Не упустите: Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.
Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете что именно улучшать. Исправьте, если я ошибаюсь.
Давайте немного раскрою техническую сторону. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.
Большинство инцидентов начинается не с уязвимости, а с украденного пароля. Исправьте, если я ошибаюсь.
Я тоже так считаю. в общем ответ сильно зависит от отрасли универсального правила нет.
Если напишете результат здесь это поможет и другим.
сведу тему в кучу так как ответов было несколько разных. при принятии решений записывайте и худший сценарий а не только лучший.
я бы поошел этим путем.
Сведу тему в кучу, так как ответов было несколько разных. Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.
На этом всё, извините если затянул.
Doki · Интерфейсный дизайн · 2026
Да, по теме цепочка поставок ситуация именно такая. Пытаться сделать это в одиночку — самый дорогой путь.
Конечно, если ваша ситуация отличается, всё меняется.
Прочитал этот ответ и выдохнул: значит, проблема не только у меня. Чем сложнее отменить решение, тем медленнее его принимайте.
Спешка в решениях оборачивается исправлениями через полгода. Удачи.