Работа вендора над информационной безопасностью начинается задолго до того, как защита попадает в продукт и становится доступной клиентам. Новые уязвимости и вредоносные инструменты требуют постоянного мониторинга, воспроизведения атак, разработки детектирующей логики и регулярных обновлений. Этот процесс представляет собой непрерывный цикл, где скорость реакции должна сочетаться с качеством и минимизацией ложных срабатываний. Рассмотрим, как он устроен и как добиться оптимального баланса.
Закладка фундамента: сбор информации
Цикл работы внутри вендора начинается со сбора информации. На этом этапе ведется мониторинг инфополя — собираются упоминания о новых угрозах, уязвимостях, уже совершенных атаках и инструментах, которые используют злоумышленники. В качестве источников могут выступать профильные СМИ, публикации специалистов, заметки других вендоров. Кроме того, постоянно ведется обмен данными внутри профессионального сообщества.
Далее полученные данные анализируются и проходят внутренние критерии отбора. Они помогают понять суть уязвимости и выяснить, какие механизмы она затрагивает, а также определить, есть ли в продуктовой линейке готовое решение, которое может ее устранить. Критерии зависят от типа продукта и включают приоритизацию по распространенности программного обеспечения, резонансности уязвимости и ее релевантности для рынка. Фокус делается на тех угрозах, которые могут затронуть большинство клиентов и требуют оперативного закрытия.
В ряде случаев внутренняя аналитика позволяет выявлять проблемы еще до того, как они становятся широко известны. Так, в ходе анализа одного из мессенджеров были обнаружены серьезные недостатки в шифровании. Из-за недостатков в реализации механизма генерации сеансового ключа появилась возможность доступа к групповым чатам и подмены сообщений. Подобные находки также выступают основой для определения логики защиты и ее внедрения в программное обеспечение.
Воспроизведение атак и создание детектирующей логики
После прохождения критериев отбора начинается этап воспроизведения. На этой стадии идет моделирование атаки. Уязвимая инфраструктура воссоздается в лабораторных условиях. Затем инженер ИБ берет на себя роль злоумышленника и максимально полно воспроизводит его действия. Эта работа позволяет получить цифровые артефакты атаки. Они могут проявляться в журналах событий, сетевом трафике, поведении приложений. Эти маркеры собираются и анализируются, чтобы определить, каким продуктом лучше закрыть конкретную уязвимость. Если следы остаются в событиях, речь идет о SIEM. Если атака видна в трафике — о системе обнаружения вторжений. Если направлена на веб-приложение — логика добавляется в WAF. В случаях, когда атака затрагивает сразу несколько уровней, обнаружение внедряется сразу в несколько продуктов.
Отдельная сложность состоит в том, что не всегда существуют готовые эксплойты. Иногда доступно только описание механизма, и тогда приходится предполагать развитие событий, чтобы выявить корень проблемы. Это позволяет строить более устойчивое обнаружение, которое опирается на принцип атаки, а не на ее отдельные вариации.
После разработки правил проводится валидация. Она включает воспроизведение атаки с уже написанными детекторами, проверку корректности работы и тестирование легитимной активности, позволяющее избежать ложных срабатываний. Затем все это доставляется клиентам, от них вендор получает фидбэк, смотрит, как все происходит в реальности. А дальше цикл запускается по новой, потому что с течением времени уязвимостей становится все больше, появляется новая информация. Весь этот путь — постоянный цикл улучшений, проходящий через практически все перечисленные выше этапы.
Баланс между скоростью и качеством
Когда возникает новая уязвимость, бизнес по понятным причинам хочет закрыть ее прямо сию же секунду — или хотя бы так быстро, как только возможно. В свою очередь, очевидно, что вендору для построения надежного заслона требуется время, и чем тщательнее он проводит анализ, тем дольше идет процесс. Где искать золотую середину? На практике баланс между скоростью выпуска и качеством достигается за счет итеративного подхода. При появлении эксплойта в публичном доступе сразу же появляется немало желающих его испытать, т. е. начинается массовая эксплуатация. Особенно это актуально для популярных программных решений. К примеру, год назад была очень резонансная волна атак, которые проводились через зараженные серверы Microsoft Exchange. В результате хакеры перехватывали в открытом виде пароли и логины от Microsoft OWA. Атакам подверглись серверы в десятках стран, в том числе в России, при этом жертвами стали крупные компании и государственные организации.
Поэтому, когда речь идет о подобных уязвимостях и атаках, которые я не побоюсь сравнить с пандемией, то в первой итерации лучше пожертвовать качеством и универсальностью, но взамен эффективно отразить именно ту конкретную вариацию, которая в настоящий момент актуальна. А уже после этого можно дорабатывать решение, повышать качество, разрабатывать инструменты против семейства подобных атак, чтобы у клиента усиливалась защита и появлялся задел на будущее. Параллельно запускается работа с клиентами, отправляются информационные рассылки с новостями, заметками, руководством к действию и т. п. Если же эксплойта в общем доступе нет, то приоритеты сдвигаются от скорости к качеству, и есть возможность уже на старте заложить логику для закрытия не только этой конкретной уязвимости, но и ее будущих вариаций.
Важно понимать, что защита требует постоянного пересмотра. Бывали случаи, когда уязвимость считалась закрытой, но уже через неделю появлялось описание, как ее задействовать снова, где вендор не запатчил ее полностью и где остались альтернативные пути эксплуатации. Поэтому нужно постоянно отслеживать, что происходит, какие новые подробности об уязвимости появляются. Иначе говоря, стоит всегда быть готовым оперативно обновить защиту.
Существуют также методы получения информации до появления эксплойта в открытом доступе. Назвать их предугадыванием будет слишком громко, однако и они вносят свой вклад в ИБ. Например, анализ патча через обратную разработку позволяет выявить место уязвимости и понять, как она может быть использована, чтобы заранее подготовить детектирующую логику.
Синергия как ключ к защите
После того как клиент получает продукт, ему необходимо в том числе следить за тем, чтобы было включено обновление, а также удостовериться в правильности настроек. Иначе говоря, он не может на 100% полагаться на вендора и при этом полностью бездействовать. Вендор не знает, как устроена конкретная инфраструктура, поэтому клиент тоже отвечает за использование инструментов, полученных от поставщика. Грамотная настройка решает очень много проблем. Если все настроено правильно, если все обновления включены, то вы можете быть уверены в том, что получите актуальный контент, который поможет вам защититься.
С другой стороны, создание защитной логики невозможно без экспертов на стороне вендора, которые занимаются анализом угроз и разработкой детекторов. Важна синергия опытных сотрудников и молодых специалистов, которые учатся в боевых условиях и привносят альтернативный взгляд. Именно наличие такой команды определяет способность вендора оперативно реагировать на новые угрозы.
