“Каждый год мы с друзьями ходим в баню…». Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности – PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне – «Миша, давай что-нибудь технологическое сделаем!». А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все – начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам – свои навыки обнаружения и отражения угроз.
Итак, возник вопрос, как же нам «понаблюдать» за этой битвой, с точки зрения информационной безопасности? Собственно, эта статья именно о подробностях построении такого процесса наблюдения и полученных нами результатах.
Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA – Network Traffic Analytics) – это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и «бесшовнее», чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и «обучиться» за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее «шумными» с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание
на вот такой материал.
Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня – я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта – а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово «просто» и теперь попробую развернуть его подробнее.
Итак, как же выглядит процесс?
Надо запросить триалку, это занимает пару минут.
Ссылка тут.
Потом, в течение пары дней начинают приходить разные полезные письма и в конце концов приходит письмо про то, что портал активирован!
После этого получаешь себе личный портал, ссылка на который выглядит так:
cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.
Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики – 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги.
Сразу скажу, что у сенсора есть два интерфейса – один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.
После установки сенсор бежит в облако, где размещена консоль – это на самом деле AWS и выдает прекрасное сообщение:
Это тот самый IP адрес, под которым сенсор считает, что видит себя во внешнем мире, пробившись через корпоративный межсетевой экран, трансляцию адресов и т. п. На всякий случай, сразу скажу, что сенсору нужен HTTP и HTTPs, а также настройка DNS-а. После получения указанного выше сообщения надо просто взять этот адрес и добавить его в список своих сенсоров на консоли:
И через некоторое время сенсор окрашивается в зеленый цвет – это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг – это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт.
На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:
И скопировать полученную информацию на наши сетевые устройства. Все – система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия – например Cisco Tetration, IBM QRadar и т. п.
Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она «прилагается» по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут.
Итак, первым делом и настроил такую интеграцию:
Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: https://habr.com/ru/company/jetinfosystems/blog/529174/.
Особых надежд на нее я не возлагал, пологая, что все самое интересное будет происходить внутри полигона, а обеспечивать защиту этого полигона в мои задачи не входило.
После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:
После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:
Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо – облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:
В этом месте я прочитал свой текст выше и понял, что писал его гораздо больше времени, чем заняла настройка системы, включая все интеграции.
Ну а теперь – что же мы увидели?
В первые дни Standoff телеметрию мне отдавала парочка наших виртуальных межсетевых экранов ASAv, но потом количество источников несколько увеличилось – добавилось еще межсетевых экранов, а также Netflow с центрального брокера трафика.
Первые уведомления пришли очень быстро, и, как и следовало ожидать, они были связаны с многочисленными сканированиями. Ну а потом наблюдать за процессом становилось интереснее с каждым часом. Я не буду тут расписывать весь процесс наблюдения, а просто расскажу о нескольких фактах. Во-первых, удалось собрать неплохую информацию что есть что на полигоне:
Во-вторых, оценить масштабность мероприятия – с какими же странами был наиболее активный обмен трафиком:
На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными «внешними», помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:
Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:
И при желании, спросить про них у других полезных аналитических источников:
Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:
Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:
Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже – это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:
Итак, немного коротких выводов по результатам этого небольшого и занимательного пилота.
Первый — компания Positive Technologies провела прекрасные киберучения и было очень интересно немного понаблюдать за ними «изнутри», причем это было удобно, легко и просто.
Второй, о котором я вынужден сказать – облачные решения по безопасности – это быстро, просто и удобно. А если их еще и много и между ними можно настроить интеграцию – к тому же и очень эффективно.
Третий — участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft.
Четвертый – автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут.
Ну и маленький заключительный комментарий — в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все – начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам – свои навыки обнаружения и отражения угроз.
Итак, возник вопрос, как же нам «понаблюдать» за этой битвой, с точки зрения информационной безопасности? Собственно, эта статья именно о подробностях построении такого процесса наблюдения и полученных нами результатах.
Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA – Network Traffic Analytics) – это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и «бесшовнее», чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и «обучиться» за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее «шумными» с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание
на вот такой материал.
Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня – я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта – а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово «просто» и теперь попробую развернуть его подробнее.
Итак, как же выглядит процесс?
Надо запросить триалку, это занимает пару минут.
Ссылка тут.
Потом, в течение пары дней начинают приходить разные полезные письма и в конце концов приходит письмо про то, что портал активирован!
После этого получаешь себе личный портал, ссылка на который выглядит так:
cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.
Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики – 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги.
Сразу скажу, что у сенсора есть два интерфейса – один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.
После установки сенсор бежит в облако, где размещена консоль – это на самом деле AWS и выдает прекрасное сообщение:
{"error":"unknown identity","identity":"185.190.117.34"}Это тот самый IP адрес, под которым сенсор считает, что видит себя во внешнем мире, пробившись через корпоративный межсетевой экран, трансляцию адресов и т. п. На всякий случай, сразу скажу, что сенсору нужен HTTP и HTTPs, а также настройка DNS-а. После получения указанного выше сообщения надо просто взять этот адрес и добавить его в список своих сенсоров на консоли:
И через некоторое время сенсор окрашивается в зеленый цвет – это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг – это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт.
На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:
И скопировать полученную информацию на наши сетевые устройства. Все – система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия – например Cisco Tetration, IBM QRadar и т. п.
Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она «прилагается» по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут.
Итак, первым делом и настроил такую интеграцию:
Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: https://habr.com/ru/company/jetinfosystems/blog/529174/.
Особых надежд на нее я не возлагал, пологая, что все самое интересное будет происходить внутри полигона, а обеспечивать защиту этого полигона в мои задачи не входило.
После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:
После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:
Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо – облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:
В этом месте я прочитал свой текст выше и понял, что писал его гораздо больше времени, чем заняла настройка системы, включая все интеграции.
Ну а теперь – что же мы увидели?
В первые дни Standoff телеметрию мне отдавала парочка наших виртуальных межсетевых экранов ASAv, но потом количество источников несколько увеличилось – добавилось еще межсетевых экранов, а также Netflow с центрального брокера трафика.
Первые уведомления пришли очень быстро, и, как и следовало ожидать, они были связаны с многочисленными сканированиями. Ну а потом наблюдать за процессом становилось интереснее с каждым часом. Я не буду тут расписывать весь процесс наблюдения, а просто расскажу о нескольких фактах. Во-первых, удалось собрать неплохую информацию что есть что на полигоне:
Во-вторых, оценить масштабность мероприятия – с какими же странами был наиболее активный обмен трафиком:
На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными «внешними», помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:
Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:
И при желании, спросить про них у других полезных аналитических источников:
Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:
Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:
Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже – это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:
Итак, немного коротких выводов по результатам этого небольшого и занимательного пилота.
Первый — компания Positive Technologies провела прекрасные киберучения и было очень интересно немного понаблюдать за ними «изнутри», причем это было удобно, легко и просто.
Второй, о котором я вынужден сказать – облачные решения по безопасности – это быстро, просто и удобно. А если их еще и много и между ними можно настроить интеграцию – к тому же и очень эффективно.
Третий — участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft.
Четвертый – автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут.
Ну и маленький заключительный комментарий — в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.