Кризис доверия: как работать с подрядчиками безопасно

Коллекция заблуждений

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

Как по сценарию

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

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

По наблюдению экспертов компании «Инфосистемы Джет», приблизительно в 40% случаев подобная информация (логины, пароли, токены, SSH-ключи) в организациях хранится в незашифрованном виде и ее с легкостью можно найти в файловых хранилищах, системах управления проектами (таких как Jira, Confluence и т. д.) или в конфигурационных файлах.

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

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

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

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

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

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

Примеры инцидентов

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

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

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

Далее в ход идет инструкция по подключению к корпоративному VPN, которую злоумышленники заранее скачивают с конфлюенса подрядчика. Они проверяют наличие второго фактора и убеждаются в том, что его нет. Дело сделано: киберпреступники проникают в инфраструктуру заказчика.
Поскольку подрядчик занимается разработкой и поддержкой программного обеспечения, у него имеются права локального администратора сразу на нескольких серверах, где развернуты его решения. Используя их, хакеры проводят сетевую разведку с помощью сетевого сканера и видят структуру Active Directory (какие группы и пользователи в ней присутствуют и какие сервисы используются).

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

В результате этих действий в руках злоумышленников оказалась привилегированная учетная запись в домене заказчика. Далее последовала атака на контроллер домена, нацеленная на получение базы его пользователей (NTDS.dit). А через множественные подключения по RDP к различным серверам был проведен поиск важной информации. В частности, на сервере баз данных хакеры нашли скрипты, в которых в открытом виде хранятся логины и пароли сервисных учетных записей.

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

Обнаружение нелегитимной активности произошло в момент создания дампа NTDS.dit и множественных подключений по RDP. После этого специалисты предприняли ответные действия:

• блокировка IP-адресов;
• сброс VPN-сессий;
• блокировка учетных записей;
• смена паролей в Active Directory;
• исследование скомпрометированных узлов;
• настройка двухфакторной аутентификации.

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

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

От слепого доверия к взаимодействию ИБ-служб

В ситуации повышенных угроз со стороны подрядчиков перед компаниями неизбежно встает вопрос построения эффективной защиты.

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

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

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

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

• создать сценарии возможного реагирования — например, закрыть доступ всем сотрудникам подрядчика к ИТ-инфраструктуре либо частично блокировать их действия и одновременно начать поиск следов компрометации, которые должны различаться в зависимости от вида инцидента (компрометация учетной записи, утечка информации и т. д.);
• составить перечень сотрудников, которых необходимо уведомить об инциденте;
• назначить ответственного за принятие решений о дальнейшем реагировании на действия хакеров;
• заранее подготовить PR-стратегию для взаимодействия со СМИ в кризисных ситуациях;
• определиться с критериями, согласно которым инцидент ИБ можно считать разрешенным.

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

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

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

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

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

• перечень защитных мер, которые принимаются компанией на каждом этапе взаимодействия с подрядчиком (от выбора компании до завершения работ);
• критерии выбора подрядчика: какие задачи он должен решать и каким требованиям отвечать (полный перечень);
• порядок учета подрядчиков и предоставленного им доступа к инфраструктуре компании (к каким ИТ-активам возможно подключение, насколько они критичные, какой тип доступа используется и т. д.);
• требования по обеспечению ИБ, которые необходимо соблюдать подрядчику при совместной работе;
• порядок управления доступом третьих лиц к корпоративным ресурсам.

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

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

Следует зафиксировать план реагирования на инцидент ИБ подрядчика со своей стороны (как минимум сценарии компрометации его учетной записи и утечки переданных ему конфиденциальных данных).

Решения для контроля

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

• Решение класса NAC или ZTNA — для контроля устройств подрядчиков, с которых они подключаются к сети. В частности, специализированный агент не даст подключиться, если на устройстве не реализованы требования ИБ — например, нет антивируса.
• VPN и 2FA — для обеспечения безопасного удаленного доступа к ИТ-инфраструктуре.
• NGFW — для сегментации сети, контроля трафика и ограничения подрядчиков в рамках выделенных подсетей.
• Решения класса PIM/PAM — ядро архитектуры, которое обеспечивает регулярный мониторинг и контроль привилегированных учетных записей подрядчика.
• VDI — для создания изолированной среды работы каждого подключаемого пользователя с гранулированным доступом к необходимым целевым системам.
• VDR — для повышения уровня защищенности при обмене файлами между подрядчиком и внутренней инфраструктурой заказчика.

Участвуют все

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

Если в качестве формата учений был выбран пентест / red team / purple team, в них будут участвовать команды реагирования (при их наличии), а также представители ИБ/ИТ-подразделений. Если же учения проходят по модели настольного тестирования (tabletop), то в зависимости от их сценария, помимо задействования этих департаментов, рекомендуется участие представителей бизнеса, юридического отдела и отдела маркетинга, то есть фактически всей вертикали сотрудников, обеспечивающей непрерывность бизнеса.

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

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

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