Русский
Русский
English
Статистика
Реклама

Киберполигон

Пентест Свет не выключайте, пожалуйста. Киберполигон А город надолго без света?

11.11.2020 16:12:52 | Автор: admin

Потребность в оценке защищенности ИТ-инфраструктуры появилась практически одновременно с компьютерными системами. В 50-е годы прошлого столетия ученые начали предполагать, что на компьютерные системы возможны атаки, а в 1988 году Робертом Моррисом младшимбыл создан первый массовый сетевой червь, который по скромным оценкам нанес ущерб в 96 млн долларов. Тогда общественность всерьез задумалась над угрозой компьютерных атак.

В 1992 году появился первый документ, содержащий правила управления ИБ в компании, который впоследствии превратился во всем известный ISO/IEC 17799. На основании этого документа стали проводиться аудиты для выявления несоответствий. Вот только аудиты эти помогали убедиться, что системы обеспечения информационной безопасности в компании соответствуют установленным на бумаге (в политиках, регламентах) требованиям, а не защищают от реальных киберугроз. Причем сама проверка проводилась преимущественно в форме опроса сотрудников.

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

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

Эти запреты связаны с тем, что компании боятся необратимости последствий, вызванных моделированием кибератак. Из-за этих ограничений пентест, как правило, заканчивается либо проникновением в локальную сеть компании, либо получением доступа к учетной записи администратора домена. И все. Только демонстрация гипотетических возможностей злоумышленников. И то без демонстрации последствий, ведь доводить атаку до конца запрещено. Это минус для всех сторон: для экспертов ИБ, которые не могут предоставить доказательства своих слов, лишь предполагая, к чему приведут действия хакеров; для службы ИБ компании, которая не может проверить, работают ли меры по противодействию атакующим; для руководства компании, которое может не доверять гипотетическим угрозам.

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

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

Поэтому среди экспертов ИБ так популярны соревнования Capture the Flag (CTF). На CTF-площадках участники могут искать уязвимости в сервисах и использовать их для развития векторов атак на другие команды без негативного влияния на бизнес-функции компаний. Кроме того, эти соревнования отличный способ обучения экспертов ИБ (исследователей, пентестеров, участников Red Team и Bug Hunter). И если раньше бизнес не относился серьезно к CTF, считая это лишь развлечением, то сейчас мы видим, что многие общепризнанные эксперты ИБ, которые теперь занимают высокие должности, когда-то принимали участие в CTF. Правда, соревнования за более чем 20-летнюю историю преобразились.

До 2010 года CTF-соревнования были далеки от реальной жизни и инфраструктуры, уязвимости искусственны, а результат игры неприменим для бизнеса. Есть два формата проведения CTF:

  • Task-based, в котором требуется решать отдельные задачи и получать очки за правильные ответы (флаги).

  • Attackdefense, в котором участники получают идентичные серверы с набором уязвимых сервисов (приложений), не связанных между собой. Задача каждой команды заключается в том, чтобы найти уязвимости, устранить их на своем сервере и воспользоваться ими для получения конфиденциальной информации (флагов) у соперников.

Во время соревнований участники отрабатывают навыки быстрого поиска и закрытия уязвимостей, они учатся работать в команде, развиваются как эксперты. Сегодня работодатели приветствуют опыт в CTF как для пентестеров, так и для специалистов службы ИБ и SOC. Компании даже сами устраивают соревнования, например Trend Micro с 2015 года, Google с 2016 года. Кроме того, появились публичные программы bug bounty, в которых любой желающий может протестировать сервисы и продукты известных компаний и получить денежное вознаграждение за выявленные уязвимости. Так, за zero-click-уязвимость с исполнением кода на ядре компания Apple готова заплатить 1 млн долларов.

В 2010 году НАТО впервые провела открытые соревнования Locked Shields, в которых столкнулись Red Team (атакующие) и Blue Team (защитники). С 2001 года подобные соревнования под названием Cyber Defense Exercise проводило Агентство национальной безопасности США, но только для учащихся военных академий США. Формат таких соревнований не похож на CTF, это киберучения, эмулирующие реальный мир. В киберучениях применяются ИТ-системы, выполняющие бизнес-процессы, присущие реальным компаниям. Так, в декабре 2020 года Европейское агентство по сетевой иинформационной безопасности(ENISA) проведет Cyber Europe 2020, в котором организаторы смоделируют сценарии, касающиеся здравоохранения.

Движение бизнеса в сторону практической безопасности прозрачной, результативной и обоснованной привело к абсолютно новому формату соревнований. Этим форматом стали киберучения, в которых одновременно могут принять участие все специалисты компьютерной безопасности: пентестеры, исследователи, сотрудники службы ИБ и центра мониторинга. Сценарии атак для киберучений могут быть автоматизированы, а могут реализовываться с привлечением Red Team, состоящей из экспертов ИБ. Привлечение нескольких команд атакующих позволяет улучшить подготовку сотрудников службы ИБ и SOC, поскольку у них появляется возможность проработать больше техник и сценариев атак.

С появлением киберполигона The Standoff у сообщества появилась среда для моделирования кибератак, оценки значимости ресурсов и реализуемости рисков на цифровом макете реального города. В инфраструктуру города заложены живые бизнес-сценарии нефтяной компании, ТЭЦ, подстанции, химического завода, аэропорта, банка, железной дороги, морского порта, а значит, участники столкнутся с настоящим оборудованием и сервисами, используемыми в этих компаниях. The Standoff это уникальная возможность довести вектор атаки до конца и посмотреть, к чему это приведет: будет ли украден миллиард и надолго ли останется город без электричества после выхода из строя паровой турбины ТЭЦ. При проектировании The Standoff были использованы реальные контроллеры, которые используются на идентичных объектах критически значимой инфраструктуры, а значит, у экспертов ИБ есть возможность протестировать сценарии атак до конца. Если атака будет успешной и электростанция остановится, значит, она остановилась бы и в реальной жизни.

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

Изучить киберполигон The Standoff вживую вы сможете уже завтра 12 ноября. The Standoff стартует в онлайн-формате и продлится в этом году целых шесть дней. Помимо активностей, связанных с кибер-битвой, вы сможете послушать доклады лучших экспертов в области практической кибербезопасности со всего мира: более 30 спикеров из России, США, стран Европы и Азии поделятся с вами своими последними наработками. Для участия в мероприятии достаточно лишь подключиться к онлайн-платформе.

Автор: Ольга Зиненко, аналитики информационной безопасностиPositiveTechnologies

Подробнее..

Большая ретроспектива участия RBK.money в The Standoff 2020

02.12.2020 18:09:40 | Автор: admin
или как хакеры ломали наш опенсорс платежный процессинг в кибергороде.

Привет! Мы тут недавно с процессингом RBK.money приняли активное участие в киберполигоне The Standoff это когда делают виртуальную модель целого мегаполиса со всей его инфраструктурой, энергостанциями, магазинами и прочими важными элементами. А потом пускают в этот цифровой двойник города команды blue team (6 команд в этом году) и red team (29 команд в этом году соответственно), первая защищает всю эту инфраструктуру, вторая же активно пытается что-то сломать.


из к/ф Бегущий по лезвию 2049

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

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

Внедрялись в кибергород мы в ощутимой спешке: это один из первых наших деплойментов в Kubernetes (до этого мы все разворачивали Salt-стейтами), и нам пришлось использовать новые подходы по инсталляции. И последствия от этой спешки не заставили себя долго ждать.

Подсказки хакерам




Ещё до раскатки процессинга на кибергород мы намеренно оставили там два довольно слабых места.

Первое уязвимость, связанная с методами токенизации карт. Эти методы были подвержены уязвимости в виде replay-атак, то есть карту можно было успешно токенизировать в каком-то одном магазине, а потом с этим токеном прийти в другой и переиспользовать его там. Мы робко надеялись, что уязвимость найдут, но увы.

Второе простая учетка главного мерчанта. Мы создали всего одного мерчанта-олигарха, это было юридическое лицо, которое владело интернет-магазинами в кибергороде. И у этого толстосума были довольно простые учетные данные, то есть пароль вида Parolec0 в принципе можно было бы и подобрать. Но тоже не взлетело.

Зато взошли наши собственные косяки.

Поспешишь не всё защитишь




Внимательный читатель из пункта про главного мерчанта сделает вывод погодите-ка, это же у вас один-единственный олигарх, которому принадлежат все интернет-магазины, достаточно взломать один такой интернет-магазин, и можно получить доступ к остальным. Ну да, вот так в спешке не продумали этот момент..

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

В принципе, это правильно, если ты здоровенный жадный олигарх, который захапал себе вообще всё страдай. Мы сделали выводы и решили оперативно раскулачить толстосума, создав ещё 5 самостоятельных юридических лиц, и для каждого отдельные пары логин-пароль и API-ключ. Думаю, в следующих подобных соревнованиях постараемся сделать ситуацию еще более приближенной к реальности в бизнесовой ее части.

А ещё наприлетало из-за особенностей кубера.

В Kubernetes основное хранилище о состоянии кластера ETCD, полезная распределенная система, на которой можно строить весьма и весьма надежные штуки. Но она слишком критична к latency жестких дисков.

Как я писал, мы разворачивали процессинг в виртуальной среде кибергорода. На соседние с нами объекты шли довольно активные атаки, и однажды к нам на датастор кубера передвинули один из таких шумных объектов, инфраструктуру одного из участников, которую ломали долго и упорно. И хотя де-факто мы в этом случае не были мишенью и в тот момент никто не ломал именно процессинг, он продолжал работать штатно, но сам кластер начал дико тормозить, харды просто не справлялись (успели заметить что вывод команды ls -l занимал порядка 19 секунд). Получилось, что вышел своеобразный DoS, и в одну ночь мы отдавали на все запросы наших стандартных котиков.



После этой ситуации организаторы The Standoff передвинули нас на другие диски, то есть погасили одну виртуальную машину и включили еще одну, в другой локации. После чего наша распределенная СУБД радостно словила split-brain, половина нод содержали одну информацию, половина другую, и особо не могли с собой договориться. На бою мы, конечно, серьезнее бы заморочились с миграцией и не допустили подобного. А в тестовой среде куда проще было просто грохнуть все имеющееся и инсталлировать заново, что мы и сделали, потратив, кстати, 2 часа. Почему я это выделяю потому что мы развернули полноценный рабочий процессинг со всеми составляющими за два часа, и такое с нашим процессингом вы можете проделать на бою в своей компании. Классические процессинги обычно разворачивают в компаниях месяца 3.

Так вот, про split-brain, это все спешка. Мы в запаре просто на одной из нод под корень снесли /tmp. Кто ж знал, что модуль CSI LVM, который раздает локальные тома с железа в поды, скрыто (!) монтирует персистентный том кубера в /tmp. Таким образом получилось, что мы своими собственными руками снесли данные под ногами СУБД, которые на ней крутились. Причем, несмотря на то, что мы снесли хранилище для части нод в кластерах баз, у нас все продолжало работать до первого перезапуска виртуальной машины, который случился, когда нас начали переносить на новые сторы.

Blue-team медленно выключает свою защиту




В один из дней команды blue-team решили выключить внешние защиты (firewall и прочее). То есть первые пару дней хакеры пытались ломать системы с включенной защитой такого рода, а потом без. У нас также стоял сторонний WAF, который в ингрессе с нжинксом в виде модуля подгружался и защищал наш трафик.

И вот настал этот день, мы пошли выключать WAF и поняли, что он и так уже отключен. Два дня назад. Потому что мы молодцы и в спешке (да, да), настраивали ingress kubernetes, на котором был экземпляр WAF. И всё бы хорошо, но WAF банально не достучался до управляющего сервера, не смог с него скачать файл лицензии, пожал плечами и просто выключился от греха. И получается, что мы все эти два дня Ломаем с включенной защитой сидели, собственно, без этой защиты.

Но всё равно нас не сломали.

Ещё одно подкрепление тезиса, что спешить вредно (вдруг вам мало предыдущих) ситуация с нашим антифродом. Я описывал его в предыдущих постах блога, там волшебная коробка с набором правил. Антифрод защищает от перебора банковских карт, попыток оплатить в одну точку из разных локаций / IP / email и прочих недружественных действий. Мы сказали команде защиты, что сами вдумчиво настроим все эти правила.

И мы это сделали мы тщательно настроили все правила для антифрода. На нашем боевом сервере RBK.money вместо инсталляции для The Standoff. Банально перепутали урлы UI в адресной строке браузера. То есть антифрод на это время представлял собой коробку с молчаливой загадочной пустотой.

Это и стало одним из успешных векторов для редов:
например, они до этого взломали сторонний интернет-банк, стырив PAN-код карты (сами цифры, Primary Account Number), имя держателя карты и подобрав дату действия. После этого уже в нашем процессинге по этому PAN стали перебирать CVV. И все было бы хорошо, после 3 попытки перебора карты были бы заблокированы нашим антифродом. Если бы см выше.

А вообще подобных смешных историй было много. В какой-то момент у нас перестали резолвиться сервисы и перестало синхронизироваться время на нодах, причем как-то рандомно, с части хостов.

Конечно, первым делом грешили на мисконфиг, непонятную работу кластера.

С DNS проблему быстро решили выносом CoreDNS подов прямо на ноды, где этот трафик не фаерволился, а с NTP нам повезло по счастью, большого clock skew мы не поймали, а при создании кластера ноды еще успели синхронизироваться.

Оказалось в какой-то момент на уровне фаервола были отключены исходящие NTP- и DNS-запросы для части нод. Видать, кто-то слишком сильно закрутил гайки с фильтрацией.

Другие атаки




Атаки на другие соседние объекты кибергорода также временами проходили успешно, включая те, что, как и мы, были в финансовой системе кибергорода.

Хорошо, что мы не перепутали урлы алертов над эластиком и в мониторинге, и видели их достаточно точно и достаточно быстро.

Для примера, как в случае со взломом нашего олигарха и уведённым API-ключом. Взломали его в 22.17 МСК. В 22.22 мы на своей стороне заметили это и сразу отрепортили команде защитников и организаторам. Заметили, кстати, благодаря кривому использованию API хакеры передали в первом запросе странный заголовок content type, вызывали редкий метод нашего API, еще кое-какие нюансы вот и был повод сработать алерту.

Когда система работает штатно и автоматически, это все редко совпадает одновременно. А вот если происходит подобное, значит, с API кто-то играется именно руками. Вот алерт и сработал.
Если говорить не о кибергороде, а о реальных ситуациях такого рода, то тут все происходит еще быстрее, в таких случаях система автоматически блокирует действия мерчанта, чтобы у него со счета ничего не вывели и в принципе никак не навредили работе и бизнесу, поднимает панику и подключает уже живых сотрудников

На будущее


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

И это на самом деле было очень классно и весело. Фактически мы получили большой набор Chaos Monkey-кейсов, которые не факт что стали бы воспроизводить на продакшене, мы протестировали процессинг на атаки, получив за 2 дня больше атак, чем к нам штатно приходит за полгода.

Мы многому научились, и самое главное увидели, что наш продукт, который мы пишем для себя и для вас, пользуется популярностью у участников кибергорода, для нашего ИТ это было сильной мотивацией ведь приятно, когда результатом твоего труда пользуются люди, пусть в данном случае и с весьма специфическими целями.

Нам очень понравилось и хочется ЕЩ.

В следующем Стендоффе ждите нас с еще более интересными схемами, большим количеством платежных функций и новыми векторами атак!
Подробнее..

Глобальный SOC на The Standoff2020 всевидящее око

04.12.2020 08:08:46 | Автор: admin

Мы, я имею в виду экспертный центр безопасности Positive Technologies, традиционно участвуем в противостоянии The Standoff уже несколько лет с 2018-го, когда оно было частью Positive Hack Days. В первый год мы следили за игровыми трендами и событиями, используя SIEM-систему (MaxPatrol SIEM), наше решение для анализа сетевого трафика (PT Network Attack Discovery) и многоуровневую систему выявления и блокировки вредоносного контента (PT MultiScanner). Наша задача состояла в том, чтобы изучить активность участников мероприятия, отследить тактики и инструментарий, ими используемый, и, конечно же, поработать со своими продуктами при повышенной нагрузке. Во время подобных мероприятий наши инструменты используются на полную мощность (и даже еще немного больше): в 2018 году мы двое суток следили за 12 командами, MaxPatrol SIEM пережевывал 20000 EPS, PT Network Attack Discovery переработал более 3 ТБ сетевого трафика, а наша команда определяла успешные атаки, искала следы компрометации (веб-шеллы, удаленные консоли, авторизацию на узлах и проч.), а накопленные знания в дальнейшем в числе прочего легли в основу обновлений наших продуктов.

Год спустя мы увеличили количество глаз нашего SOC на The Standoff в рамках очередного PHDays: к предыдущим трем добавились еще PT Application Firewall и PT Industrial Security Incident Manager. Это позволило нам получить максимально полную картину противостояния во всех элементах инфраструктуры цифрового мегаполиса. Все длилось также двое суток, но следили мы за бльшим числом участников (в тот году было уже 18 команд атакующих, шесть команд защитников и три команды SOC), которые вели очень активную деятельность в городской инфраструктуре. В отличие от команд, мы не вмешивались в события на площадке соревнований, а только лишь наблюдали за ними. Ключевая наша задача состояла в том, чтобы продемонстрировать на практике эффективность современных систем для выявления и расследования киберинцидентов. Ну и конечно же изучить те тактики и техники, которыми пользовались участники, в режиме реального времени, поскольку на The Standoff команды атакующих традиционно используют самые актуальные средства и приемы.

Поэтому, с одной стороны, в преддверии The Standoff в этом году наши задачи, цели и планы нам были ясны не первый раз, как говорится. Однако масштаб мероприятия наложил-таки свой отпечаток на нашу работу.

Purple teaming как он есть

Начать можно с того, что пять с лишним суток (123 часа) непрерывного мониторинга в условиях повышенной активности команд атакующих под силу только правильно собранной команде. В этом году команда нашего SOC включала нескольких специалистов, которые отвечали за непрерывный мониторинг и поддержание процесса threat hunting в наблюдаемом виртуальном окружении, передачу информации работающим посменно аналитикам, составлявшим общую картину происходящего, с помощью которой возможно было строить kill chains реализации конкретных угроз и рисков. Также мы включили в команду экспертов со специфическими скилами: например, в области АСУ ТП, анализа вредоносного кода, написания детектов для выявления действий хакеров в инфраструктуре. Такой состав команды позволяет максимально полно оценивать происходящее, обнаруживать, классифицировать и исследовать вплоть до мельчайших технических деталей все векторы атак в контексте конкретных киберрисков.

Кстати, о рисках за все время The Standoff команде нашего глобального SOC удалось зафиксировать реализацию атакующими 24 киберрисков, притом два из них не были изначально заложены в условия соревнования. Таким образом, для всех участников, включая наш SOC, The Standoff стал еще и тренировкой в части адаптации фокусов мониторинга на лету: после первой фиксации этих дополнительных рисков они были включены в программу, и в дальнейшем отчеты атакующих об их реализации принимались наравне со всеми прочими. Для этого были настроены дополнительные решающие правила на средствах защиты информации.

В ходе всего мероприятия наши специалисты в режиме 24/7 отслеживали события безопасности, происходившие в развернутой инфраструктуре виртуального города (который, однако, имел и физическое воплощение в виде масштабного макета). Иными словами наблюдали за действиями команд атакующих, red teams. А затем на основе полученной информации оценивали качество, полноту и справедливость представленных атакующими отчетов о выполнении того или иного игрового задания. Результатом этой постоянной работы стала полная хронология происходящего, которая затем использовалась жюри как некий базовый справочник, а также чтобы своевременно предоставлять информацию профессиональному сообществу, наблюдавшему за происходящим на портале The Standoff. Примерно таким же образом осуществлялась оценка полноты сведений, представленных командами защитников, blue teams, уже в их собственных отчетах о зафиксированных инцидентах.

Ну и наконец, по сути своей The Standoff представляет собой, среди прочего, масштабный purple teaming то есть некую синергию между командами красных и синих, позволяющую первым проверить подготовленные ими либо найденные на лету новые тактики и техники атак, а вторым научиться эти атаки выявлять и быстро разрабатывать соответствующие методы и средства контроля. А перед нашим SOC стояли ровно такие же задачи в отношении нашей продуктовой линейки, которая была задействована почти в полном составе.

Инструментарий всевидящего ока

Итак, на каких технологиях работал наш SOC?

Рис. 1 Схема инфраструктуры одного из офисов, созданного на киберполигоне The StandoffРис. 1 Схема инфраструктуры одного из офисов, созданного на киберполигоне The Standoff

Защита периметровых сервисов (сервисов так называемой демилитаризованной зоны) и мониторинг атак на них были построены на базе PT Application Firewall. Сердцем нашего SOC стала система MaxPatrol SIEM, к которой в качестве источников событий были подключены почти все узлы информационной инфраструктуры нашего виртуального города. Почему почти все? Потому что в сетевых сегментах АСУ ТП мы, по понятным причинам, в большей степени полагались на систему PT Industrial Security Incident Manager. Своеобразным швейцарским ножом специалиста нашего глобального SOC стал PT Network Attack Discovery, в комбинации с SIEM-системой позволяющий проводить глубокий анализ сетевого трафика и выявлять в нем аномалии и вредоносные воздействия как автоматически, так и при непосредственном участии эксперта.

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

Ну и, last but not least, оперативно выявлять атаки, связанные с применением социальной инженерии, в том числе фишинга, и проводить их анализ позволила система PT Sandbox.

В ходе подготовки такого мероприятия мы и наши коллеги, отвечавшие непосредственно за инфраструктуру, разумеется, столкнулись с определенными сложностями. Необходимо было подружить между собой огромное количество различных технических решений, имитирующих реальные бизнес-процессы виртуального города, скоммутировать подсети, добиться устойчивой работы всех систем. А уже нам как специалистам SOC критически важно было добиться на 100% чистой и стабильной видимости всего, что происходило на полигоне, и при этом снятием, например, сетевого трафика не мешать работающим процессам ни в корпоративных, ни в технологических сетях а также, конечно, ничего не пропустить. Ради этого на проект еще на этапе строительства инфраструктуры со стороны SOC были выделены два архитектора мониторинга, каждый из которых кропотливо, с привлечением профильных специалистов по обнаружению атак на узлах и в сети, проверял сетевую доступность, видимость сетевого трафика во всех сегментах инфраструктуры, фактическую видимость запросов к веб-приложениям в PT AF.

Мы подготовили набор решающих правил для MaxPatrol SIEM, сигнатур для PT ISIM и PT NAD, в том числе экспериментальных, требовавших обкатки как раз в условиях, максимально приближенных к реальным. И львиная доля этих правил и сигнатур будет доступна пользователям наших продуктов в стандартной поставке экспертизы.

Мониторинг в действии

Наши предварительные ожидания что в первые дни противостояния команды атакующих будут в основном заниматься разведкой и только готовиться к серьезным действиям не оправдались. Red teams пошли в бой с первой минуты после старта мероприятия и сохраняли такой напор практически на всем его протяжении. Количество выявленных нашим SOC событий безопасности, которые можно было квалифицировать как инциденты, перевалило за сотню уже к наступлению первой же ночи, и заданный темп впоследствии не снижался, а в последние дни, когда командам особенно важно было стало добрать очков с помощью реализации дополнительных рисков, даже возрос.

К концу противостояния команды защитников смогли объединить в цепочки и зафиксировать более 200 инцидентов (некоторые из них включали инциденты, которые наш глобальный SOC фиксировал как атомарные, в рамках одного сообщения об инциденте) и провести 21 расследование. Что интересно, на расследование отдельных инцидентов у команд защитников иногда уходили считаные минуты, но вот среднее время полноценного расследования составило порядка 11 часов. Команды атакующих реализовали 47% всех заложенных по условиям киберрисков виртуального города от падения колеса обозрения в парке аттракционов до хищения персональных данных пассажиров авиакомпании.

Пока мы отслеживали происходящее на поле боя, выяснилось несколько любопытных моментов. К примеру, команды защитников часто выявляли действия атакующих уже на этапе разведки на конкретном узле или в начале попыток перемещения в сети офиса, но пропускали первичный вектор проникновения, такой как брутфорс с попытками входов, грамотно разнесенными по времени. А наш SOC смог выявить такие инциденты с помощью профилирования поведения пользователей и решающих правил, в которые была заложена логика, учитывающая техники обхода средств защиты, основанные на временных задержках. Кроме того, разработанные нами правила корреляции позволили нашим специалистам определить отдельные действия атакующих в офисах как инциденты ИБ, связав их с первоначальной компрометацией узлов и учетных записей. Подобные действия при отдельном рассмотрении выглядят легитимными, и здесь помогало именно выстраивание цепочки от точек первичного проникновения. Таким же образом нашему SOC удавалось выделять нелегитимные запуски различных утилит, в том числе предназначенных для разведки на узлах и в сети, а также получение доступа к файлам. С помощью нашего решения для глубокого анализа трафика и песочницы мы выявляли успешные попытки фишинговых атак. И безусловно, нашим преимуществом в данном случае стало то, что мы включили в процесс мониторинга экспертов по анализу сетевого трафика. Хочется отдельно подчеркнуть важную при непрерывном мониторинге роль оперативной доработки решающих правил (как минимум дополнение связанных табличных списков), на которых основываются решения о легитимности выявляемых событий. Именно такие гибкие контроли позволили нам ловить атакующих на определенных шагах и далее отслеживать всю их активность. Этот подход доказал свою эффективность и в конечном счете обеспечил нам ряд преимуществ перед играющими командами защитников.

Кому и зачем показан The Standoff

Выводы по итогам The Standoff каждый может сделать для себя сам. Лично для меня мероприятие стало отличным подтверждением того, что сообщество специалистов по информационной безопасности в наше время должно двигаться в сторону постоянного взаимодействия и сотрудничества. Например, в рамках подобных масштабных киберучений производители прикладного ПО и аппаратуры получают отличную возможность проверить свои продукты на прочность под реальным натиском профессионалов из offensive security. Вендоры, сервис-провайдеры и интеграторы в области информационной безопасности опять же проверить в деле свои продукты и свои команды специалистов, взявшись за защиту какого-то из объектов инфраструктуры. По итогам мероприятия все участники получают новые технические данные о продуктах, уязвимостях, о методах и средствах проведения, выявления и предотвращения последствий компьютерных атак, и могут, безусловно, впоследствии применить новый опыт для укрепления безопасности любого реального объекта, а значит помочь нам всем сделать еще один шаг в безопасное будущее.

По итогам The Standoff всей команде PT ESC удалось проверить свои возможности по организации полноценного мониторинга информационной безопасности на действительно сложной инфраструктуре, собрать данные для дальнейшего обучения наших решающих модулей, а также отработать взаимодействие непосредственно SOC с другими подразделениями. Противостояние стало для нас, среди прочего, поводом взглянуть на процессную сторону такого взаимодействия под новым углом.

P.S. Пользуясь случаем, хотел бы еще раз поблагодарить всю команду, работавшую над организацией The Standoff вместе с командой нашего PT ESC, команды экспертов АСУ ТП, базы знаний ИБ, инженеров, отвечавших за внедрение и поддержку продуктов, аналитиков, собиравших отчетные материалы по ходу мероприятия, сказать спасибо нашей PR-команде, отвечавшей за информационную поддержку, и команде маркетинга, готовившей площадку и приносившей голодным сотрудникам SOC еду :) Над проектом работало очень много людей, и очень просто кого-то забыть при этом перечислении, но знайте мы обо всех вас помним и очень вам благодарны.

Автор: Павел Кузнецов, заместитель директора экспертного центра безопасности (PT Expert Security Center), Positive Technologies

За 6 дней киберполигона The Standoff атакующие вывели из строя системы аэропорта, парка развлечений, химического завода и нефтедобывающей компании. Потери понесли банк и деловой центр.

В четверг, 10 декабря в 14:00 эксперты Positive Technologies раскрутят цепочки нескольких атак, расскажут, как хакерам удалось взломать системы и покажут, как продукты Positive Technologies детектировали действия атакующих.

Вебинар будет интересен сотрудникам SOC, специалистам по ИБ и пользователям продуктов Positive Technologies: MaxPatrol SIEM, PT Application Firewall, PT NAD, PT Sandbox, PT ISIM.

Вебинар бесплатный, для участия необходимо зарегистрироваться.

Подробнее..

Открыт набор атакующих и защитников для участия в кибербитве The Standoff на Positive Hack Days

31.03.2021 04:09:55 | Автор: admin

18 мая начинаются киберучения на полигоне The Standoff, который в этом году станет полноправным партнером форума Positive Hack Days 10 (пройдет 20 и 21 мая). Все меньше времени остается до обоих событий, и мы рады сообщить, что открыли набор команд атакующих и защитников, которые будут бороться друг с другом в мегаполисе.

Что такое The Standoff

The Standoff это киберполигон. Инструмент, с помощью которого мы моделируем технологические процессы и бизнес-системы реальных компаний в промышленности, на транспорте, в энергетике, финансовом и других секторах. Задача полигона создание среды, в которой можно:

  • провести настоящие хакерские атаки на инфраструктуру предприятия;

  • обнаружить слабые места в системе информационной безопасности;

  • проверить и отработать навыки специалистов по обнаружению и предотвращению атак.

Специалисты по ИБ на полигоне изучают методы атакующих и тренируются в расследовании и отражении атак. Полигон позволяет защитникам за несколько дней получить опыт, который в обычных условиях сложно приобрести даже за годы работы.

На протяжении нескольких лет полигон The Standoff разворачивался в рамках PHDays. В прошлом году киберучения выделились в самостоятельное событие, которое может существовать в партнерстве с другими мероприятиями (как, к примеру, это было в случае с HITB). Ожидается, что в мае сойдутся в кибербитве несколько десятков команд, и мы приглашаем вас принять участие.

Технические подробности

Как и в прошлом году, The Standoff на PHDays пройдет в режиме онлайн. Большая часть инфраструктуры киберполигона будет уже знакома многим участникам: нефтяная, газовая? энергетическая и другие компании. Однако мы добавим и новые объекты инфраструктуры со своими бизнес-процессами и рисками. Какие пока секрет :) Полигон станет больше, используемые в нем технологии мощнее, а соревнование еще более практичным и приближенным к реальности.

Кого мы ждем

Мы рады не только тем, кто участвует много лет, но и тем, кто хочет попробовать свои силы впервые. Однако наша аудитория это в основном опытные специалисты, которые уже давно занимаются тестированием на проникновение и анализом защищенности и не понаслышке знают, что такое JNDI, XXE OOB и xp_cmdshell.

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

Правила The Standoff таковы, что количество участников в одной атакующей команде ограничено шириной канала, но организаторы отмечают, что для максимально комфортного участия в киберучениях число участников должно не превышать 10 человек.

Условия киберучений на The Standoff призваны сделать его максимально похожим на реальность и повысить практическую применимость его результатов. В частности мы сфокусировали и атакующих, и защитников на рисках цифровых двойников реальных объектов, а не просто на неких флагах, как это реализовано, к примеру, во всем знакомых CTF. Наша цифровая копия мегаполиса ждет тех, кто сможет обнаружить атакующих в их стремлении реализовать какую-нибудь аварию. При этом одно из ключевых требований к защитникам иметь полноценную слаженную команду.

При этом для команд защиты наличие опыта именно в тех отраслях, объекты из которых присутствуют на полигоне, необязательно. Самое главное иметь навыки выявления и расследования инцидентов, тогда участие в The Standoff позволит прокачать их еще сильнее и затем эффективно применять в ежедневной работе.

Для того, чтобы принять участие в The Standoff командам достаточно отправить заявки:

Выяснить подробности проведения The Standoff из первых рук также можно в режиме онлайн в телеграм-чате мероприятия https://t.me/TheStandoff оставайтесь с нами на связи!

До встречи на PHDays и The Standoff!..

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru