Вопреки расхожему мнению, машинное обучение — изобретение не XXI века. За последние двадцать лет появились лишь достаточно производительные аппаратные платформы, чтобы нейросети и другие модели машинного обучения было целесообразно применять для решения каких-либо повседневных прикладных задач. Подтянулись и программные реализации алгоритмов и моделей.
Соблазн сделать так, чтобы машины сами заботились о нашей безопасности и защищали людей (довольно ленивых, но сообразительных), стал слишком велик. По оценке CB Insights почти 90 стартапов (2 из них с оценкой более миллиарда долларов США) пытаются автоматизировать хотя бы часть рутинных и однообразных задач. С переменным успехом.
Главная проблема Artificial Intelligence в безопасности сейчас — слишком много хайпа и откровенного маркетингового буллшита. Словосочетание «Искусственный интеллект» привлекает инвесторов. В отрасль приходят люди, которые готовы называть AI простейшую корреляцию событий. Покупатели решений за свои же деньги получают не то, на что надеялись (пусть даже эти ожидания и были изначально слишком завышенными).
Как видно из карты CB Insights, выделяют с десяток направлений, в которых применяется МО. Но машинное обучение пока не стало «волшебной пилюлей» кибербезопасности из-за нескольких серьёзных ограничений.
Первое ограничение — узкая применимость функциональности каждой конкретной модели. Нейросеть умеет хорошо делать что-то одно. Если она хорошо распознаёт изображения, то эта же сеть не сможет распознавать аудио. То же самое и с ИБ, если модель обучили классифицировать события с сетевых сенсоров и выявлять компьютерные атаки на сетевое оборудование, то она же не сможет работать с мобильными устройствами, например. Если заказчик — фанат ИИ, то он будет покупать, покупать и покупать.
Второе ограничение — нехватка обучающих данных. Решения предобучены, но не на ваших данных. Если ситуацию «Кто же считает false-positive в первые две недели эксплуатации» ещё можно принять, то в дальнейшем «безопасников» ждёт лёгкое недоумение, ведь решение покупали, чтобы машина взяла на себя рутину, а не наоборот.
Третье и, наверное, пока главное — МО-продукты нельзя заставить отвечать за свои решения. Даже разработчик «уникального средства защиты с искусственным интеллектом» может на такие претензии ответить, «Ну а что вы хотели? Нейросеть — это же чёрный ящик! Почему она решила именно так, никто, кроме неё, и не знает». Поэтому сейчас инциденты информационной безопасности подтверждают люди. Машины помогают, но ответственность несут по-прежнему люди.
С защитой информации проблемы есть. Их рано или поздно решат. Но как дела с нападением? Могут ли МО и ИИ стать «серебряной пулей» кибератак?
Варианты использования машинного обучения для повышения вероятности успеха пентеста или анализа защищённости
Наверное, сейчас выгоднее всего использовать МО там, где:
- нужно создать что-то похожее на то, с чем нейросеть уже сталкивалась;
- нужно выявлять неочевидные человеку закономерности.
С этими задачами МО уже отлично справляется. Но и кроме этого некоторые задачи можно ускорить. Например, мои коллеги уже писали об автоматизации атак с помощью python и metasploit.
Пытаемся обмануть
Или же проверить осведомлённость сотрудников в вопросах информационной безопасности. Как показывает наша практика тестирования на проникновение, социнженерия работает — почти на всех проектах, где была проведена такая атака, мы добивались успеха.
Предположим, что мы уже восстановили, используя традиционные методы (сайт компании, соцсети, сайты вакансий, публикации и т.д.):
- организационную структуру;
- список ключевых сотрудников;
- паттерны адресов электронной почты или реальные адреса;
- позвонили, прикинулись потенциальным клиентом, узнали как зовут продавца, менеджера, секретаря.
Дальше нам нужно получить данные, чтобы обучить нейросеть, которая будет имитировать голос конкретного человека. В нашем случае — кого-нибудь из руководства тестируемой компании. В этой статье говорится, что достаточно одной минуты голоса, чтобы достоверно притвориться.
Ищем записи выступлений на конференциях, сами на них ходим и записываем, пытаемся поговорить с нужным нам человеком. Если у нас получается сымитировать голос, то стрессовую ситуацию для конкретной жертвы атаки мы можем создать сами.
— Алло?
— Продавец Пресейлович, здравствуй. Это Директор Начальникович. У тебя чего-то мобильный не отвечает. Там тебе сейчас придёт письмо из ООО «Вектор-Фейк», посмотри, пожалуйста. Это срочно!
— Да, но…
— Всё, не могу больше разговаривать. Я на встрече. До связи. Ответь им!
Кто не ответит? Кто не посмотрит вложение? Посмотрят все. И грузить в это письмо можно всё, что угодно. При этом не обязательно знать ни телефон директора, ни личный телефон продавца, не нужно подделывать адрес электронной почты на внутрикорпоративный, с которого придёт вредоносное письмо.
Кстати, подготовку атаки (сбор и анализ данных) тоже можно частично автоматизировать. Мы как раз сейчас ищем разработчика в команду, которая решает такую задачу и создаёт программный комплекс, облегчающий жизнь аналитика в области конкурентной разведки и экономической безопасности бизнеса.
Атакуем реализации криптосистем
Предположим, что мы можем слушать зашифрованный трафик атакуемой организации. Но нам хотелось бы знать, что именно в этом трафике. На идею меня натолкнуло вот это исследование сотрудников компании Cisco «Обнаружение вредоносного кода в защифрованном TLS-трафике (без дешифровки)». Ведь если мы можем на основании данных из NetFlow, служебных данных TLS и DNS определять присутствие вредоносных объектов, то что нам мешает использовать те же данные для идентификации коммуникаций между сотрудниками атакуемой организации и между сотрудниками и корпоративными ИТ-сервисами?
Атаковать крипту в лоб — себе дороже. Поэтому, используя данные об адресах и портах источника и получателя, числе переданных пакетов и их размере, временных параметрах, мы стараемся определить зашифрованный трафик.
Далее, определив криптошлюзы или конечные узлы в случае p2p-коммуникаций, мы начинаем их досить, вынуждая пользователей переходить на менее защищённые способы связи, которые атаковать уже проще.
Прелесть метода заключается в двух преимуществах:
- Машину можно обучить у себя, на виртуалочках. Благо бесплатных и даже open-source продуктов для создания защищённых коммуникаций существует предостаточно. «Машина, вот это такой-то протокол, в нём такие-то размеры пакетов, такая-то энтропия. Поняла? Запомнила?». Повторить как можно больше раз на различных типах открытых данных.
- Не надо «гнать» и пропускать через модель весь трафик, достаточно только метаданных.
Недостаток — MitM ещё надо получить.
Ищем баги и уязвимости ПО
Наверное, самая известная попытка автоматизировать поиск, эксплуатацию и исправление уязвимостей — DARPA Cyber Grand Challenge. В 2016 году в финальной CTF-подобной битве сошлись семь полностью автоматических систем, спроектированных разными командами. Конечно, цель разработок декларировалась исключительно благая — защищать инфраструктуры, iot, приложения в реальном времени и с минимальным участием людей. Но на результаты ведь можно посмотреть и под другим углом зрения.
Первое направление, в котором развивается МО в этом деле — автоматизация фаззинга. Те же участники CGC широко использовали american fuzzy lop. В зависимости от настройки фаззеры генерируют больший или меньший объём выходных данных во время работы. Там, где много структурированных и слабоструктурированных данных, модели МО отлично ищут закономерности. Если попытка «уронить» приложение сработала с какими-то входными данными, есть вероятность, что такой подход сработает где-то ещё.
То же самое и со статическим анализом кода и динамическим анализом исполняемых файлов, когда исходный код приложения недоступен. Нейросети могут искать не просто куски кода с уязвимостями, а код, похожий на уязвимый. Благо, кода с подтверждёнными (и исправленными) уязвимостями очень много. Исследователю останется проверить это подозрение. С каждым новым найденным багом такая НС будет становиться всё «умнее». Благодаря такому подходу можно уйти от использования только предварительно написанных сигнатур.
В динамическом же анализе, если нейросеть сможет «понимать» связь между входными данными (включая пользовательские), порядком выполнения, системными вызовами, распределением памяти и подтверждёнными уязвимостями, то она со временем сможет искать и новые.
Автоматизируем эксплуатацию
Сейчас с чисто автоматической эксплуатацией есть проблема —
Решить её пытается Isao Takaesu и другие контрибуторы, которые разрабатывают Deep Exploit — «Fully automatic penetration test tool using Machine Learning». Подробно про него написано тут и тут.
Это решение может работать в двух режимах — режиме сбора данных и режиме брут-форса.
В первом режиме DE идентифицирует все открытые порты на атакуемом узле и запускает эксплойты, которые уже раньше срабатывали для такой комбинации.
Во втором режиме атакующий указывает название продукта и номер порта, а DE «бьёт по площадям», используя все доступные комбинации эксплойта, пейлоада и цели.
Deep Exploit может самостоятельно обучаться методам эксплуатации, используя обучение с подкреплением (благодаря обратной связи, которую DE получает от атакуемой системы).
Может ли сейчас ИИ заменить команду пентестеров?
Наверное, пока нет.
У машин есть проблемы с выстраиванием логических цепочек эксплуатации выявленных уязвимостей. А ведь именно это зачастую прямо влияет на достижение цели тестирования на проникновение. Машина может найти уязвимость, может даже самостоятельно создать эксплойт, но она не может оценить степень влияния этой уязвимости на конкретную информационную систему, информационные ресурсы или бизнес-процессы организации в целом.
Работа автоматизированных систем генерирует МНОГО шума на атакуемой системе, который легко замечается средствами защиты. Машины работают топорно. Уменьшить этот шум и получить представление о системе можно с помощью социнженерии, а с этим у машин тоже не очень.
А ещё у машин нет смекалки и «чуйки». У нас недавно был проект, где наиболее экономически выгодным способом проведения тестирования было бы использовать радиоуправлямую модель. Я не представляю, как не-человек мог бы до такого додуматься.
А вы какие идеи для автоматизации могли бы предложить?
Автор: Serenevenkiy
