Цифровая природа современной экономики делает компании критически зависимыми от технологий. Коммуникации с контрагентами, все виды отчетности, поиск сотрудников, продвижение сервисов, заказ материалов и компонентов — в буквальном смысле все аспекты бизнеса завязаны на внешние сервисы, подрядчиков, API-интеграции, госпорталы, облачные платформы. И в этой связке корпоративная кибербезопасность больше не ограничивается периметром одной компании. Пора это признать.
Сколько бы усилий вы ни вкладывали в собственную защиту — устанавливали активные средства защиты, сегментировали инфраструктуру, настраивали автоматизацию реагирования на инциденты — этого уже недостаточно. Потому что решающим может оказаться не ваш уровень зрелости, а ошибка у партнёра. Которую рынок, клиенты, регуляторы и конкуренты запишут на ваш счёт.
Когда доверие становится уязвимостью
Компании годами строили защиту. И, надо сказать, небезуспешно. Прямые атаки на периметр корпораций иногда обходятся хакерам непомерно дорого, занимают много времени и сопряжены с риском своевременной реакции со стороны защиты. Поэтому злоумышленники выбирают путь проще: атаковать доверие. Это не новый тренд, но очевидный сдвиг парадигмы — заметный, устойчивый, неудобный. В центре — те самые атаки на цепочку поставок. Термин, скажем честно, далек от изящества, просто калька с английского supply chain attacks. Но пока ему замены нет. А вот проблема — есть.
Суть проста. Атака идёт не на вас напрямую, а на тех, кому вы доверяете.
Подрядчики. Библиотеки. Облачные сервисы. Компоненты open-source. Всё, что встроено в ваш продукт или инфраструктуру. Всё, что кажется «внутренней кухней», но таковой не является.
Есть два базовых сценария. Первый — точечная атака. Цель — конкретная компания. Атака идёт через слабое звено в окружении. Например, чтобы пробраться в банк, хакеры взламывают подрядчика, разрабатывающего для него мобильное приложение. Второй — массовая атака. Целей сразу тысячи. Внедрение вредоносного кода в популярную библиотеку — и с ним обновления получают все, кто её использует.
Как это выглядит на практике? Разработчик ИБ-софта SolarWinds пропустил внедрение вредоноса в систему обновлений. Дальше нехороший код сам пошёл по клиентам — от госорганов США до крупнейших корпораций. Хотя со стороны всё выглядело как обычный патч.
xz — один из самых тревожных кейсов последних лет. Группа злоумышленников методично втиралась в доверие к программистам, которые поддерживают библиотеку xz, используемую в том числе в OpenSSH. Они коммитили патчи, участвовали в обсуждениях, вели себя как обычные разрабы open-source. И почти добились своего. Вредоносный код мог попасть в официальный релиз — и всё бы сработало. Если бы не разработчик-«старовер», который на интуитивном уровне почувствовал: что-то не так. Так что просто повезло. Протокола безопасности не было. Сработал инстинкт.
Во всех этих случаях пользователи ничего не нарушали. Они просто доверились.
Риск без контроля
Почему это так опасно? Потому что вы не контролируете точку входа.
Вы можете построить сколько угодно уровней защиты у себя — но не знаете, насколько хорошо защищен ваш подрядчик. Тот самый, что занимается бухгалтерией, логистикой, email-маркетингом или разработкой мобильного приложения. Вы не видите их ИТ-инфраструктуру. Не знаете, кто у них админ. Не проверяете, где они хранят ваши ключи доступа.
Самое неприятное: если у них случается компрометация, вы оказываетесь в эпицентре чужой ошибки. Только отвечаете за нее вы. Юридически — потому что данные ваших клиентов были под вашей ответственностью. Репутационно — потому что в заголовках СМИ будет ваш бренд. Своими бизнес-показателями — потому что именно вы теряете клиентов и деньги.
Такие атаки сложно распознать, потому что они не выглядят как атаки. Скорее, как малозаметный баг. Сервис, который вдруг тормозит. Обновление, после которого что-то пошло не так. Подозрительная, но допустимая активность из внешнего IP. Доступ в логах, который вроде как был разрешен. Зловредная суть часто проявляется только через часы, дни или даже недели, когда уже поздно. В момент атаки всё выглядит допустимо. Вы видите не нарушение, а отклонение от нормы — настолько тонкое, что ни SIEM, ни XDR, ни даже SOC-аналитик с паранойей в крови не поднимут красный флаг. Ведь всё осталось «в пределах допуска».
А за пределами — уже последствия.
В контексте, когда любой новый контрагент может стать слабым звеном, самая очевидная идея — работать с проверенными партнерами. Но здесь стоит задать себе неприятный вопрос: а на чём основано это «проверено»? Аргументы обычно выглядят так:
- «Мы с ними давно работаем».
- «У них серьёзные клиенты».
- «Да вроде надёжные ребята».
- «Ну что с ними может случиться?»
Фактически статус доверенного партнера основывается на вере на слово. И здесь даже давнишний контрагент, история взаимодействия с которым насчитывает несколько лет, не сильно отличается от нового. А если так, то разницы никакой.
ИБ-критерий при выборе подрядчика
Подход «мы классные, поверьте на слово» пока продолжает работать. Но — делает это на местечковом уровне, при достаточно скромных ценах контрактов и умеренной степени ответственности за результат. В ситуации, когда перед амбициозным исполнителем стоит задача перехода на новую ступень через начало работы с действительно крупным клиентом, ИБ становится неофициальным, но вполне весомым и определяющим фактором в принятии решений.
Реально крупный заказчик максимально прагматичен. Для него каждый подрядчик — вероятный источник риска. Вот почему к привычным критериям вроде компетенций, сроков и цены проекта примешивается фактор безопасности: а не станете ли конкретно вы источником проблем для уважаемой фирмы?
Даже если ваши перспективы работы с крупным клиентом определяет не закупочный комитет, а свой человек внутри корпорации, он все равно исследует: насколько у вас как у исполнителя значителен технический долг в ИБ в сравнении с его родной компанией?
Само собой, странно ожидать, что небольшой разработчик, создающий несколько микросервисов для банковского супераппа, будет неприступной крепостью, как сам банк. Но он должен видеть собственные слабые места в обеспечении информационной безопасности, и предпринять минимальные меры, чтобы их закрыть. Ведь даже свой человек внутри заказчика не станет рисковать карьерой и приглашать на проект подрядчика с заведомо слабой ИБ-составляющей.
Как может выглядеть минимальный набор пожеланий любого «корпората» к исполнителю?
- Нормальный контроль доступа. Для взаимодействия с инфраструктурой клиента и для доступа в его периметр работают личные аккаунты для каждого сотрудника (без универсальных «admin/admin»). Ведется журнал ключевых операций — чтобы всегда было понятно, кто и что делал. Доступ выдается строго по необходимости и только на время выполнения конкретной задачи, безо всяких исключений.
- Работа на тестовом стенде и с обезличенными данными. Есть хорошая практика не давать подрядчику реальные данные и не пускать к боевой системе. Для этого разворачивают тестовую среду, на которую подрядчик накатывает обновления своего ПО и проводит тесты. В этой среде нет реальных данных — всё обезличено. И из этой среды нельзя попасть в реальную инфраструктуру. Это песочница.
- Двухфакторная аутентификация (2FA), особенно для систем разработки, облачных сервисов, CI/CD и админских панелей. Над двухфакторкой клиент такого разработчика может легко раскрыть зонтик средств мониторинга, чтобы вовремя отлавливать подозрительные активности и тем самым снизить риск атаки на цепочку поставок.
- Безопасные хранение и передача данных. Все данные, полученные от заказчика, должны храниться зашифрованными. Передача информации — только через защищенные каналы (VPN, SFTP, HTTPS). Никаких коммитов в клиентский репозиторий и тем более в прод из домашней сети Wi-Fi или из кафе, аэропортов, отелей. Файлам, пересылаемым через мессенджеры без шифрования — даже хотфиксам! — отказать.
- Минимальные аудит и самооценка. Проведение внутреннего аудита хотя бы раз в год. Наличие отчета проверки и выполненных работ по итогам теста: что проверялось и какие улучшения были внесены. Лучший вариант — пройти внешний аудит.
- Документация по безопасности. Краткая политика ИБ (даже если это всего одна страница). Назначенный ответственный за информационную безопасность в команде. Процедуры реагирования на инциденты (например, что делать, если скомпрометирован ключ).
- Наличие дорожной карты по ликвидации ИБ-техдолга. Может показаться, что это выглядит как признание существующих проблем. Но трезвая оценка собственных слабостей и план по их постепенному устранению воспринимаются гораздо лучше, чем проваленная попытка скрыть недочеты.
Пентест доверия
Крупные компании отличаются от небольших в первую очередь ценой ошибок. И если раньше информационная безопасность учитывалась в ходе переговоров далеко не как первостепенный фактор, то сегодня она всё чаще попадает в фокус внимания. Особенно после новых регуляторных требований вроде
В этом контексте регулярный пентест — это про демонстрацию зрелости: мы знаем, что у нас внутри, мы не закрываем глаза на проблемы, мы работаем с ними. Это уже больше технологический маркетинг, где поставщик услуг показывает себя покупателю сервисов не через оптику количества релизов и скорости разработки, а по критерию управления рисками. И если вы такой подрядчик, разумно показать: мы провели пентест, знаем свой техдолг и планируем его гасить. Таковы новые правила игры.
Спокойствие оптом и в розницу
Атаки supply chain — это повседневная реальность, в которую мы въехали на полном ходу. Злоумышленники давно поняли: проще атаковать не напрямую, а через окружение. Регуляторы сокращают пространство для ошибок. Законодательные новации выглядят так, чтобы призвать к ответу не того, кто реально виноват в утечке, а того, кто этому виновному доверился.
Перспектива для корпорации понести наказание за то, в чем она не виновата, меняет процесс выбора поставщика готовых услуг или сервисов по разработке ПО. Ландшафт этого рынка снова трансформируется: компетенции исполнителя и его готовность делать больше за те же деньги больше не его, исполнителя, конкурентное преимущество. Даже существенные скидки на человеко-час разработчика на фоне вероятных объемов взысканий выглядят, мягко скажем, несерьезно.
Так что защищенность подрядчика превращается в осязаемое конкурентное преимущество. Похоже, настали времена, когда спокойствие и уверенность клиента в исполнителе имеет гораздо большую ценность, чем всё остальное.
