ГК Softline: атака на компанию может начаться с ноутбука подрядчика

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

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

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

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

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

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

Украденная переписка помогает обойти регламент

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

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

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

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

Средства защиты не распознали атаку в момент предоставления прав: письмо пришло от известного сотрудника, стиль общения не вызвал подозрений, а доступ открыл легитимный администратор. Уязвимость возникла из-за отступления от регламента ради удобства коллеги.

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

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

Формальная парольная политика не защищает украденную учетную запись

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

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

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

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

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

Личный компьютер становится частью корпоративной инфраструктуры

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

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

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

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

Риск зависит от цели атаки, а не только от отрасли

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

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

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

История инцидентов должна менять правила

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

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

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

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

Контролировать нужно всю цепочку доступа

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

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

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

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

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

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