Маскировка киберпреступников под личиной партнеров ИБ/ИТ-вендоров

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

Есть гораздо более вероятные сценарии. Например, на днях прошла  новость  о якобы обнаруженной новой угрозе, которую уже успели окрестить емким термином "Chip-in-the-Middle" ("чип посередине"), суть которой заключается в установке в мобильные устройства чипов (например, во время ремонта) с вредоносной функциональностью. На самом деле это угроза не нова и вполне предсказуема при правильном моделировании угроз в управлении цепочками поставок. Вот хорошая иллюстрация из презентации, которую я делал еще 3 года назад.



В ней описанный сценарий "chip-in-the-middle" описан наряду с другими точками приложения сил злоумышленниками. В сегодняшней заметке я бы хотел коснуться немного другого участка цепочки поставок, о котором многие специалисты по ИБ не думают, но именно через него возможно нанесение ущерба для предприятия. Речь пойдет о процессе, который на иллюстраии отмечен словом "партнеры". Да-да, именно те компании, которые и поставляют львиную долю всех ИБ-решений потребителям, и являются одной из угроз.

Реализуется эта угроза достаточно просто - злоумышленнику нужно проделать всего несколько шагов:

  1. Зарегистрироваться в качестве партнера у интересующего производителя решений по ИБ (на самом деле это касается не только ИБ-производителей, но и любого поставщика, например, ИТ). Выдавать себя лучше за регионального партнера - их проверяют (если вообще проверяют) не очень пристально.
  2. Податься на конкурс по поставке средств защиты, организованному предприятием-жертвой.
  3. Установить минимальную цену своего предложения (можно ничего не заработать, а можно даже и в минус уйти). Нередко (а у госорганов в соответствие с 44-ФЗ так почти всегда) основным критерием выбора продукта является цена (что вызывает неудовольство разных сторон, и продавцов, и покупателей) - кто дешевле, тот и выиграл.
  4. Выиграть конкурс, который, по тому же 44-ФЗ, практически невозможно отменить.
  5. Получить у производителя оборудование или ПО (нередко, для отчетности в бухгалтерии, ПО скачивается не с сайта, а поставляется на CD/флешке).
  6. Внедрить закладку в оборудование или ПО. Понятно, что в зависимости от железа или софта это может потребовать определенной квалификации, но невозможным я бы это не назвал.
  7. Осуществить поставку оборудования или ПО заказчику.
  8. Бинго!

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

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

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

  • Внедрение SDLC (также и применительно к железу) на стороне производителя. Тема SDLC непроста - немногие производители, особенно небольшие, особенно в России, реализуют у себя цикл безопасной разработки. Крупные игроки тоже не всегда могут похвастаться идеально выстроенными процессами. Могу привести пример нашей компании - мы в Cisco реализовывали все поэтапно (вот тут  презентация  и  видео  с конференции ФСТЭК, где про это рассказано более подробно) и контроль целостности на уровне софта (при загрузке и в процессе исполнения) и на уровне железа у нас появился по меркам компании относительно недавно.




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




  • Использование третьей стороны, которая возьмем на себя оценку целостности поставленных решений. Частным случаем такого пути решения проблемы является сертификация на отсутствие недекларированных возможностей и проведение соответствующего тестирования (с упором на поиск именно постороннего вмешательства, а не уязвимостей, которые являются результатом деятельности разработчиков).
  • Мониторинг активности. Это традиционная деятельность любой службы ИБ или ИТ, но в контексте заметки привычные системы класса NTA (Network Traffic Analysis), EDR (Endpoint Detection & Response), UEBA (User Entity Behavior Analytics), NFT (Network Forensics Tool) и т.п. должны включать в область своего контроля еще и средства защиты (что бывает нечасто) и иные "доверенные" устройства и решения. Это не так сложно и не требует больших усилий (если технологии мониторинга аномалий на уровне софта и железа, сетевом и прикладном в компании есть) - просто надо признать такую угрозу актуальной.
ЗЫ. Когда уже заканчивал заметку пришло в голову, что в проекте методики моделирования угроз ФСТЭК, этот тип нарушителя впрямую не указан, как и сама угроза. Хотя направление размышлений задано в проекте верно.




 

Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Красная или синяя таблетка?

В Матрице безопасности выбор очевиден

Выберите реальность — подпишитесь