ИТ-портал компании «Инфосистемы Джет»

Меняет ли машинное обучение сферу информационной безопасности?

Меняет ли машинное обучение сферу информационной безопасности?

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

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

Зачем WAF’у машинное обучение

Отчет Verizon, Data Breach Investigations Report (DBIR) относит атаки на веб-приложения к основным причинам взломов и утечек данных на протяжении предыдущих нескольких лет. Что из себя представляют веб-атаки и почему они так популярны? Это серия зловредных HTTP-запросов к веб-приложению, с помощью которых можно, к примеру, вывести его из строя через DDoS-атаку, получить доступ к важной информации в базе данных с помощью SQL-инъекции, проникнуть внутрь периметра организации и т.д. Популярность веб-атак объясняется очень просто – все веб-приложения уязвимы: наша собственная статистика за 2017 год показывает, что уязвимости разной степени риска содержатся в 100% веб-приложений, более половины их содержат уязвимости максимального уровня риска, а доля успешных попыток проникновения через атаки на веб-приложения составляет аж 72%! На смещение фокуса злоумышленника в сторону поиска уязвимостей в приложениях и их эксплуатации влияют современная культура быстрой гибкой разработки, частота обновлений приложений, рост их сложности и критичности для бизнеса. Традиционно для защиты веб-приложений используются межсетевые экраны уровня приложений (Web Application Firewalls, WAF) и далее мы поговорим о применении технологий машинного обучения именно для этого класса средств защиты.

Нельзя просто взять и запретить все «плохое»

В любом WAF, как и в большинстве других продуктов по безопасности, есть фиксированный набор правил (сигнатур). В WAF эти правила применяются к HTTP-запросам, блокируя представляющие угрозу для приложения, т.е. являющиеся частью атаки. Эта база правил лежит в основе негативной модели безопасности – «разрешать только то, что не запрещено». Но веб-угрозы очень вариативны, постоянно меняются и усложняются, возникают новые типы атак, что делает невозможным описать все «плохое» и обеспечить должный уровень защиты.

Создавая свой продукт, мы задались вопросом: «если нельзя описать все вариации плохого, чтобы запретить, возможно, нужно пойти от обратного и смоделировать хорошее?». Здесь и пришло на помощь машинное обучение ― с его помощью PT Application Firewall учится на веб-трафике и создает позитивную модель работы приложения, которая описывает состояние, когда веб-приложению «хорошо», т.е. оно работает правильно, в штатном режиме. По отклонению значений параметров запроса от значений из модели можно выявлять аномалии в трафике ― «плохие» запросы и атаки. Это на порядок эффективнее, поскольку описать правила блокировок для всех «плохих» запросов и поддерживать такую базу в актуальном виде в каждый момент времени если и возможно, то нецелесообразно (с точки зрения ресурсоемкости этой задачи).

Не все машинное обучение одинаково полезно для защиты от веб-атак

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

Пример вектора такой атаки: env X='() { (a)=>' sh -c "echo date"; cat echo

Данный вектор атаки состоит из набора символов, допустимых для параметра User-Agent, то есть на первый взгляд запрос абсолютно безобидный. Однако здесь важно стечение обстоятельств: реализация данной атаки была возможной только при расположении символов в значении параметра в строго определенном порядке (как в примере) и только для тех приложений, работавших на определенной версии веб-сервера. Эта атака могла повлечь за собой самые серьезные последствия. Имея возможность выполнить произвольную команду на веб-сервере с правами самого веб-сервера, можно было получить полный контроль над ним, а это значит, что появлялся шанс проведения произвольной вторичной атаки – подмены информации на сайте, получения доступа к важным данным, атаки на пользователей сайта и множество других неправомерных действий. В некоторых случаях данная уязвимость позволяла даже проникнуть во внутреннюю сеть организации.

Превентивные методы, основанные на сигнатурном анализе, исключают возможность обнаружения такой атаки на 0-day уязвимость (а это именно тот случай). Более того, не все подходы с использованием машинного обучения позволили бы ее обнаружить и заблокировать. Например, некоторые WAF’ы строят статистическую модель машинного обучения, оценивая только номинальный состав символов в наборе данных, а не их последовательность. Поэтому, даже применяя такие алгоритмы построения позитивной модели, невозможно добиться обнаружения атаки на ShellShock.

Другой пример ― уязвимость в веб-сервере IIS «the IIS Range Header attack (CVE-2015-1635)», эксплуатация которой могла привести к отказу в обслуживании, чтению памяти с сервера (где могут быть и исходные коды приложения, и сессионные данные и другая важная информация), а в худшем случае – к удаленному выполнению кода (атака Remote Code Execution, RCE). Вектор данной атаки выглядел следующим образом:

wget --header="Range: bytes=18-18446744073709551615" http://server-address/a-file.png

Здесь также значение параметра содержит только допустимые протоколом HTTP символы, но из-за уязвимости в логике веб-сервера использование набора символов, представляющего собой максимальное значение целого числа, как показано в примере выше, приводило к успешной атаке. Применяя лишь некоторые алгоритмы машинного обучения, можно определять не только состав символов и их последовательность, но и длину самой последовательности, тем самым выявляя аномальные запросы, что позволяет обнаруживать и блокировать подобные атаки. Метод скрытых моделей Маркова (Hidden Markov’s Models, HMM), используемый нами, отлично справился с этой задачей во время атак на данную уязвимость. Однако многие все еще продолжают выявлять аномалии по принципу статистического машинного обучения, реализуя негативную модель безопасности – когда модель описывает «как не должно быть» и блокирует все запросы, попадающие под значения в этой модели. Но эффективность такого подхода ниже в силу невозможности предугадать и описать заранее все плохое, что может случиться, включая атаки нулевого дня.

С учителем или без?

В WAF могут использоваться алгоритмы машинного обучения с учителем (supervised machine learning) и без учителя (unsupervised machine learning). Нельзя утверждать, что какой-то тип работает лучше – они решают разные задачи в разных условиях и скорее являются взаимодополняющими.

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

Отмечу, что такой алгоритм работает только на выявление аномалий, по сути решая задачу кластеризации, но не способен по определению к классификации (т. е. в нашем случае – ответить на вопрос, как именно атакуют приложение). Ответ на этот вопрос очень важен, когда ваше приложение не является конечной целью атакующего, а лишь используется для реализации более сложной таргетированной атаки (Advanced Persistent Threat, APT) – если не вышло с приложением и WAF выявил аномалию, заблокировав запрос, то атакующий будет продолжать искать другие пути реализации своей атаки. В этом случае знание о том, попытка какой именно атаки была пресечена, может помочь в расследовании с использованием других систем защиты (например, SIEM) и предотвращении всей цепочки атак.

С задачами классификации и распознавания помогут справиться только алгоритмы, требующие учителя. Все хотя бы раз (на самом деле чаще) натыкались на reCAPTCHA от Google – «докажи, что ты не робот». Хитрый Google сначала предлагал написать два слова с картинки, тем самым обучая алгоритмы для использования в своем проекте по оцифровке книг Google Books Library Project, потом предлагал написать текстом номера домов с фотографии для улучшения сервисов Google Maps и Google Street View. И в первом, и во втором случаях мы с вами, как и миллионы других пользователей по всему миру, стали учителями для алгоритмов Google и помогали корпорации решать задачи классификации и распознавания реальных изображений.

В предметной области безопасности приложений для решения этой задачи мы используем рекуррентные нейронный сети (Recurrent Neural Networks, RNN), которые были разработаны для эффективной обработки входных последовательностей переменной длины. Поскольку они изначально были разработаны для построения точных языковых моделей в вычислительной лингвистике, они способны изучать очень длинные зависимости и сложные структурные связи в данных. Применение RNN к задаче анализа HTTP-запроса ― естественный выбор, учитывая нетривиальную структуру сообщений HTTP-протокола. Фактически, используя HMM, мы решили задачу построения модели, способной находить аномалии в потоке необработанных данных. Теперь, когда у нас есть современная, хорошо структурированная база данных известных атак, мы можем сформировать сбалансированный набор данных для алгоритма обучения с учителем, и в качестве этого алгоритма был выбран RNN как наиболее продвинутый сегодня способ классификации данных.

Существуют и иные преимущества, делающие RNN более привлекательным, чем другие. Его использование позволяет эффективнее интерпретировать результаты классификации; становится возможным показать пользователю точное местоположение атаки, обнаруженной WAF, определить ее класс и специфичные для атаки параметры. Можно пополнять существующую модель новыми данными в режиме реального времени, что особенно важно для динамических и постоянно обновляемых приложений с большим количеством пользователей с различным поведением в разное время. Очень важной особенностью является то, что RNN позволяет выявлять связи, проявляющиеся лишь спустя какое-то время после начала обучения и связывающие элементы наборов данных из различных промежутков времени. Это делает возможным ретроспективное обучение, учитывающее уже накопленный моделью «опыт» и промежуточные результаты обучения, полученные ранее.

Ложные срабатывания – как различать хорошее и плохое

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

Взять, к примеру, распределенные атаки на отказ в обслуживании (Distributed Denial of Service, DDoS). Суть одной из вариаций этого типа атак состоит в отправке веб-приложению множества HTTP-запросов с различных хостов, с целью катастрофического увеличения нагрузки на веб-сервер и, как следствие, отказа в обработке штатного трафика. На прикладном уровне бороться с такой атакой возможно двумя способами: либо наращивать вычислительные ресурсы сервера, для обеспечения прохождения и вредоносного, и штатного трафика, либо искать критерий, по которому можно будет отличить один от другого, чтобы обеспечить эффективную фильтрацию «информационного шума». То есть мы возвращаемся к идее классификации. Например, используя подход, основанный на HMM, можно вывести критерий блокировки в том случае, если классифицирующий признак присутствует непосредственно в HTTP-запросе. Это может быть совокупность таких параметров, как значения каких-либо HTTP-заголовков, комбинация значений параметров запроса, адрес запрашиваемого документа и т.п.

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

Зачем машине человек, а человеку машина?

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

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

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su