jonrau1/syntheticsunБессерверная среда автоматизации безопасности AWS, которая собирает данные об угрозах, применяет ML-обнаружение аномалий (RCF, IP Insights) и обогащает телеметрию безопасности в Kibana для автоматического предотвращения, обнаружения и реагирования на угрозы.
SyntheticSun — это фреймворк глубинной безопасности, автоматизации и мониторинга, который использует аналитику угроз, машинное обучение, управляемые сервисы безопасности AWS и бессерверные технологии для непрерывного предотвращения, обнаружения и реагирования на угрозы.
Ты спишь в битом стекле
С отражениями себя,
Но чувствуешь ли ты себя живым?
Да, позволь спросить тебя,
Чувствуешь ли ты себя живым?
- Norma Jean, 2016
SyntheticSun построен на основе использования Malware Information Sharing Platform (MISP) и Anomali's LIMO — сообщества платформ обмена угрозами (TIP), предоставляющих различные типы индикаторов компрометации (IoC). Нормализованная и дедуплицированная аналитика угроз проверяется в почти реальном времени для быстрого выявления известных угроз в различных типах сетевого трафика. Для повышения динамизма выявления потенциальных угроз развертываются модели IP Insights, позволяющие находить аномалии (и потенциальные угрозы в них) между парами IP-адресов и сущностей (например, ID основных субъектов IAM, user-agent и т.д.). Также используются нативные детекторы RCF в Elasticsearch для обнаружения аномалий в телеметрии безопасности в почти реальном времени по мере ее поступления в Kibana. Чтобы демократизировать использование и тонкую настройку моделей ML в командах безопасности, предоставляются утилиты для обучения моделей IP Insights в качестве дополнения к основному решению.
Для оркестрации и автоматизации, а также для извлечения, преобразования и загрузки (ETL) телеметрии безопасности в Kibana используются различные бессерверные технологии AWS, такие как AWS Lambda, Amazon DynamoDB и AWS CodeBuild. Эти бессерверные технологии применяются из-за их масштабируемости, простоты использования и относительно низкой стоимости по сравнению с тяжелыми решениями MapReduce или Glue ETL. Большая часть решения развертывается через CloudFormation со вспомогательными скриптами на Python и shell, предоставленными на всех этапах, чтобы способствовать внедрению и потенциальному развертыванию в конвейерах непрерывной интеграции.
Чтобы сделать «внутренности» решения максимально легкими, основные модули Python, такие как boto3, requests, json, ipaddress, socket и re, выполняют большую часть извлечения, преобразования и загрузки (ETL) в последующие сервисы. Поскольку вся информация о геолокации предоставляется ip-api.com, она не требует учетной записи или платных тарифов и имеет отличный API, включающий информацию о регулировании в заголовках ответов. Большая часть зависимостей Elasticsearch и Kibana также предоставляется в коде (индексы, маппинги, визуализации и т.д.), чтобы избежать тяжелой ручной настройки.
SyntheticSun разделен на три этапа из-за размера решения и необходимых зависимостей. Вся архитектура и инструкции по установке (а также часто задаваемые вопросы) находятся в рамках соответствующего этапа. Дополнительные модули (называемые Приложениями) также предоставляются для расширения функциональности и имеют свою архитектуру и инструкции по установке.
SyntheticSun, как и любое найденное на GitHub, является концептуальным решением, поэтому я не стал прилагать дополнительные усилия для абсолютного укрепления безопасности в первом релизе. Если вы читаете это в момент, когда я еще не внес необходимые изменения, учтите следующее перед развертыванием решения в производственной среде (или любой среде с повышенными требованиями к безопасности). Я добавлю эти пункты в дорожную карту и обновлю по мере необходимости.
SyntheticSun — это простой способ начать использовать киберразведку угроз и машинное обучение для защиты периметра в облаке AWS без необходимости инвестировать в одно или несколько коммерческих средств или нанимать специалиста по данным для вашей команды безопасности (хотя в идеале вы должны сделать последнее). Это решение после начальной настройки полностью автоматизировано, что позволяет выявлять угрозы и реагировать на них на машинной скорости. Наконец, решение предоставляет базовые визуализации для вашей команды реагирования на инциденты, такие как разрешенные входящие или исходящие соединения или DNS-запросы к IP-адресам или доменам, признанным вредоносными. Основная часть решения опирается на очень легкие конвейеры автоматизации и обработки данных, которые теоретически можно повторно использовать для других целей, где требуется многоэтапная нормализация и обогащение или запланированные быстрые пакетные задания.
Прежде всего, если вы используете Amazon GuardDuty и/или AWS WAF, может иметь смысл оценить это решение, но это также и требование. Очевидные персонажи, которые могут воспользоваться преимуществами, — это команды, отвечающие за безопасность всего стека и не имеющие достаточного капитала или опыта для моделирования, обучения и развертывания алгоритмов машинного обучения или значимого внедрения фидов киберразведки угроз. Эти персонажи, вероятно, являются инженерами безопасности, аналитиками SecOps/SOC или инженерами DevSecOps; однако этот список не исчерпывающий, и они не обязательно должны быть привязаны к продукту/приложению, так как центральные команды также могут это использовать. Другой вариант использования — те же персонажи (SecOps, инженеры безопасности), работающие в централизованной команде и желающие создать динамический список блокировки для брандмауэров и систем предотвращения вторжений. Проекты CodeBuild можно перенастроить для сброса CSV или плоских файлов практически в любое место (например, брандмауэры Palo Alto, фильтры URL прокси Squid и т.д.).
SyntheticSun в настоящее время не охватывает все основные источники журналов, а именно S3 Access Logs и CloudFront Access Logs, которые неотъемлемы для способа доставки услуг многими людьми (особенно для SPA на корзинах S3). Обнаружение аномалий не распространяется дальше WAF, API Gateway Access Logs или CloudTrail из-за моей одержимости IP Insights и полного отсутствия какого-либо образования в области науки о данных (серьезно, я даже не умею пользоваться pandas или numpy). Нет глубокого анализа сырых IoC киберразведки, кроме попытки сопоставить их в журналах.
Самый простой способ развернуть это решение для организации — развернуть его в централизованной учетной записи сервисов безопасности. Для телеметрии нижнего уровня, такой как VPC Flow Logs и WAF Logs, следует рассмотреть возможность предоставления вспомогательных скриптов или шаблонов CloudFormation через AWS Service Catalog для упрощения включения в более низких средах. Вам нужно будет оценить потребление шардов и ротацию индексов Elasticsearch Service, а также разрешения, если у вас будут потоки доставки Kinesis Data Firehose между учетными записями, публикующиеся в централизованное место. Я создал это решение в своей личной песочнице, поэтому не встроил в решение ни одно из вышеперечисленных соображений. Я буду рад поработать над PR с учетом этого и, возможно, сделаю это сам в будущем.
По состоянию на 31 ИЮЛЯ 2020 года политики AWS Firewall Manager поддерживают агрегацию журналов WAF между несколькими учетными записями, что приближает вас на шаг к тому, чтобы сделать это гораздо менее болезненным...
ПРЕДУПРЕЖДЕНИЕ: Я не специалист по данным, и это будет длинный ответ. Короче: это детектор аномалий, и, думаю, да.
Поскольку я не имею никакого отношения к науке о данных или обучению, вам лучше почитать документацию. Тем не менее, вот моя любительская попытка объяснить: IP Insights — это алгоритм неконтролируемого машинного обучения, который изучает взаимосвязь между IPv4-адресом и сущностью (например, номер учетной записи, имя пользователя, user-agent). Затем IP Insights пытается определить, насколько вероятно, что сущность будет использовать этот IPv4-адрес. За кулисами IP Insights находится нейронная сеть, которая изучает латентное векторное представление этих сущностей и IPv4-адресов. Расстояние между этими векторизованными представлениями является показателем того, насколько аномально (или нет) для сущности быть связанной с (например, отправлять запрос с) IPv4-адреса.
Нейронные сети почти такие же, как они звучат; они образуют систему машинного обучения, предназначенную для поведения, аналогичного человеческому мозгу, с компьютеризированными нейронами и синапсами. В неконтролируемом машинном обучении алгоритм может выяснить, как выглядит «хорошее» (т.е. True Negative) по сравнению с «плохим» (т.е. True Positive), глядя на связь между всеми IPv4-адресами и их парными сущностями. Эта связь оценивается для идентификации векторов, которые похожи на другие, по их «расстоянию». В случае IP Insights предоставляется предварительно созданный кодировщик, который ищет IPv4-адреса, а затем хэширует все сущности в кластеры. Затем он итеративно обрабатывает их, используя векторизацию. Векторизация — это способ выполнять вычисления в виде матрицы вместо циклов (представьте цикл «For» для списка, содержащего десятки миллионов значений).
Когда вы обучаете модель IP Insights, она фактически создает себе ложные срабатывания, связывая IPv4-адреса с сущностями, имеющими большое расстояние (т.е. сильно аномальные), которые вряд ли произойдут в реальности; теперь модель может различать True Positives, False Positives и True Negatives. Это делается для предотвращения другого сумасшедшего термина, называемого «перекрестная энтропия» (также известная как «логарифмические потери», как будто это проще), и вводит еще один термин — бинарную классификацию. IP Insights по сути спрашивает: «Какова вероятность того, что этот IP-адрес, связанный с этой сущностью, является аномальным?» Это делает его бинарным, я думаю, так что «да, это плохо» или «нет, это не так». Вероятность представляется в виде значения от 0 до 1, цель всех моделей машинного обучения — сделать его как можно ближе к 0, поэтому предсказание значения 0,01 для того, что на самом деле равно 1 (известный True Positive), приведет к очень высоким логарифмическим потерям. Итак, с учетом всего вышесказанного, создавая намеренно мусорные данные, IP Insights помогает уменьшить эти логарифмические потери (т.е. плохие предсказания) во время обучения.
Это подводит нас к выводу из endpoint. Когда вы запрашиваете его (либо пакетами, либо в почти реальном времени с помощью API InvokeEndpoint), ответ представляет собой неограниченное число с плавающей запятой, которое может быть отрицательным или положительным. Чем выше оно над 0, тем более вероятно, что это аномалия, и здесь начинается ваша работа. В этом решении я выбрал все, что выше 0,03, что в значительной степени условно; чтобы приблизиться к истине, вы должны предоставить True Positives эндпоинту и посмотреть, каков будет ответ. Основываясь на этих результатах, вы можете настроить многоуровневый подход, когда ваше приложение может выдать второй фактор аутентификации, поднять тревогу или заблокировать его напрямую в зависимости от оценки. Ответ на вторую часть вопроса: «Да, я так думаю». Обучение модели с user-agent в паре с IP-адресом на самом деле довольно сомнительно. Для других менее волатильных сущностей (номер учетной записи, имя пользователя, пользователь IAM) это кажется предполагаемым использованием.
В решении я предоставляю несколько примеров фидов, которые вам следует использовать; некоторые из них довольно очевидны, например фид доменов киберпреступности, Emerging Threats и CI-badguys. На своей реальной работе я работаю с одним из самых талантливых специалистов по киберразведке угроз в мире (без шуток, она потрясающая!), который также повлиял на выбор. Как и в моделях машинного обучения и всем остальном, что вы будете строить, вы должны адаптировать свои фиды угроз и их агрегацию к вашей текущей среде угроз. Дубликаты идентифицируются в MISP, и в таблицах DynamoDB указан только хэш-ключ для обеспечения уникальности, поэтому даже если 5 фидов сообщают об одном и том же IPv4-адресе, в таблицу попадет только один.
Вы также можете добавить собственные коммерческие платформы и фиды киберразведки угроз, такие как InfoBlox или Recorded Future, направив их на таблицы DynamoDB с аналогичным синтаксисом.
Большинство доставок журналов от AWS осуществляются по принципу «best effort», поэтому нет официального SLA; однако я бы предположил, что это около 99,5–99,9%, где последние 0,5–0,1% не будут доставлены. «Производственный» трафик также является приоритетным в AWS; если есть ограничения пропускной способности сети, он по умолчанию будет отдавать приоритет восстановлению связи с клиентами, а не отправке журналов. Более вероятное событие — что необработанный файл журнала был слишком велик для Lambda, чтобы обработать его полностью за отведенное время; вы часто видите это, когда вас засыпают DOS или краулером с одного и того же IP-адреса клиента. WAF и ALB группируют файлы журналов по вызывающему (насколько я могу судить), поэтому, если вы поглощаете сотни запросов, файл журнала может быть очень большим.
Да, однако вам потребуется выполнить одно из следующих действий:
Это повлечет дополнительные расходы. Lambda в VPC, особенно при десятках параллельных вызовов, скорее всего, приведет к дополнительным проблемам из-за того, что ENI остаются и занимают ваше RFC1918 пространство. Если у вас нет абсолютной необходимости изолировать весь трафик внутри VPC для соответствия требованиям, я бы не стал идти по этому пути.
Да, это достижимо путем изменения решения для публикации окончательно отформатированных журналов в Kinesis Data Firehose и направления их в Splunk.
Я надеюсь получить поддержку для журналов DNS Route 53, S3 Access Logs, CloudFront Access Logs и API Gateway Access Logs, а также, возможно, некоторых других журналов на основе хостов в будущем.
Честно говоря, я бы предпочел использовать агент Kinesis Data, но столкнулся с множеством проблем: он не включен по умолчанию в Amazon Linux 2, и теперь, когда AMI Ubuntu 18.04 LTS поставляются с предустановленной Java 11, я столкнулся с проблемами обратной совместимости с агентом, так как сборка завершается ошибкой, если у вас нет OpenJDK 8 или 9. Было гораздо проще установить агент CloudWatch, так как он часто обновляется новыми функциями, и существует поддержка документа Systems Manager для конфигурации; у него даже есть мастер установки. Если AWS когда-нибудь будет относиться к поддержке агента Kinesis Data так же серьезно, как к агенту CloudWatch, я, возможно, переключусь на него, так как я бы предпочел публиковать напрямую в Kinesis Data Firehose для определенных журналов на основе хостов (Suricata, Squid, Nginx, Apache) вместо использования CloudWatch Logs в качестве посредника.
Я с радостью принимаю PR для пунктов, отмеченных как «Help Wanted» в Issues или Project Board. Я также рассмотрю любые другие предложенные PR, если они соответствуют духу проекта.
Особая благодарность David Dorsey и Ryan Nolette, которые предоставили ценные отзывы, тестирование и вклад в тонкую настройку SyntheticSun.
Эта библиотека лицензирована в соответствии с GNU General Public License v3.0 (GPL-3.0). См. файл LICENSE.
