Рубрикатор |
Блоги | Алексей ЛУКАЦКИЙ |
Маскировка киберпреступников под личиной партнеров ИБ/ИТ-вендоров
24 августа 2017 |
Есть гораздо более вероятные сценарии. Например, на днях прошла новость о якобы обнаруженной новой угрозе, которую уже успели окрестить емким термином "Chip-in-the-Middle" ("чип посередине"), суть которой заключается в установке в мобильные устройства чипов (например, во время ремонта) с вредоносной функциональностью. На самом деле это угроза не нова и вполне предсказуема при правильном моделировании угроз в управлении цепочками поставок. Вот хорошая иллюстрация из презентации, которую я делал еще 3 года назад.
- Зарегистрироваться в качестве партнера у интересующего производителя решений по ИБ (на самом деле это касается не только ИБ-производителей, но и любого поставщика, например, ИТ). Выдавать себя лучше за регионального партнера - их проверяют (если вообще проверяют) не очень пристально.
- Податься на конкурс по поставке средств защиты, организованному предприятием-жертвой.
- Установить минимальную цену своего предложения (можно ничего не заработать, а можно даже и в минус уйти). Нередко (а у госорганов в соответствие с 44-ФЗ так почти всегда) основным критерием выбора продукта является цена (что вызывает неудовольство разных сторон, и продавцов, и покупателей) - кто дешевле, тот и выиграл.
- Выиграть конкурс, который, по тому же 44-ФЗ, практически невозможно отменить.
- Получить у производителя оборудование или ПО (нередко, для отчетности в бухгалтерии, ПО скачивается не с сайта, а поставляется на CD/флешке).
- Внедрить закладку в оборудование или ПО. Понятно, что в зависимости от железа или софта это может потребовать определенной квалификации, но невозможным я бы это не назвал.
- Осуществить поставку оборудования или ПО заказчику.
- Бинго!
В результате, злоумышленникам не нужно осуществлять никаких
проникновений в корпоративную или ведомственную сеть - процесс установка
программных или аппаратных закладок осуществляется полностью на
легальных основаниях. Более того, жертва еще и сама все это будет
устанавливать в своей сети, полностью доверяя своим партнерам и
контрагентам. И, скорее всего, у жертвы даже подозрения не возникнет,
что партнер, поставляющий продукты и сделавший прекрасное ценовое
предложение, извлечет из этой истории совершенно иную выгоду, а прибыль
получит позже.
К счастью, пока эта угроза не столь популярна у злоумышленников, так как
требует определенных шагов, которые требуют ресурсов (временных,
финансовых) больше, чем обычно. Но и невозможной эту угрозу я бы не
назвал, особенно в условиях желания многих производителей расширять
число партнеров, продающих их решения, и в условиях российского
законодательства, предусматривающего выбор продукта не по его
функциональности, а по цене.
Как бороться с этой угрозой? Направлений я с ходу могу назвать четыре:
- Внедрение SDLC (также и применительно к железу) на стороне производителя. Тема SDLC непроста - немногие производители, особенно небольшие, особенно в России, реализуют у себя цикл безопасной разработки. Крупные игроки тоже не всегда могут похвастаться идеально выстроенными процессами. Могу привести пример нашей компании - мы в Cisco реализовывали все поэтапно (вот тут презентация и видео с конференции ФСТЭК, где про это рассказано более подробно) и контроль целостности на уровне софта (при загрузке и в процессе исполнения) и на уровне железа у нас появился по меркам компании относительно недавно.
- Использование сервисов мониторинга целостности оборудования и ПО, предлагаемых производителем. Это большая редкость и я вот так сходу и не вспомню производителей, которые бы предлагали такие сервисы, как дополнение к своим решениям. Но это пока - думаю не за горами, когда такие услуги будут предлагаться и заказчику только останется решить, тратить на это деньги или принять соответствующие риски.
- Использование третьей стороны, которая возьмем на себя оценку целостности поставленных решений. Частным случаем такого пути решения проблемы является сертификация на отсутствие недекларированных возможностей и проведение соответствующего тестирования (с упором на поиск именно постороннего вмешательства, а не уязвимостей, которые являются результатом деятельности разработчиков).
- Мониторинг активности. Это традиционная деятельность любой службы ИБ или ИТ, но в контексте заметки привычные системы класса NTA (Network Traffic Analysis), EDR (Endpoint Detection & Response), UEBA (User Entity Behavior Analytics), NFT (Network Forensics Tool) и т.п. должны включать в область своего контроля еще и средства защиты (что бывает нечасто) и иные "доверенные" устройства и решения. Это не так сложно и не требует больших усилий (если технологии мониторинга аномалий на уровне софта и железа, сетевом и прикладном в компании есть) - просто надо признать такую угрозу актуальной.
Источник
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.