Почему сертифицированные решения не защищают

Новости безопасности с портала securitylab.ru за 26-27 августа 2019

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

Сегодня вы покупаете не какую-то голую железку для защиты, а к ней прилагается сервис, в котором задействованы сотни человек, которые круглосуточно отслеживают атаки всего мира, пишут новые сигнатуры для антивируса, IPS, изучают новые приложения (майнеры, анонимайзеры, туннели), смотрят где появились новые вредоносные URL, DNS, IP и все это своевременно поставляют в Ваше устройство защиты. То есть устройство защиты сегодня - живое. Оно меняется с той же скоростью, с какой меняются угрозы.

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

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

Для заказчика шансов остаться без закладок нет, даже если все сертифицировано, потому что закладку могут вставить в любой момент цепочки поставки от производства до доставки в ЦОД, о чем рассказывал Александр Матросов на Offzone 2019.

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

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

Почему верно проверять исходный код или среду разработки, включая обновления? Потому что даже сама компания-производитель может непроизвольно вставить в свой код вредоносный код. Так уже было с производителем бухгалтерского софта M.E.Doc, в обновлениях которого был вредоносный код Petya. Но, к сожалению, мы как пользователи можем только принять такие риски и скачивать обновления, начиная, с операционных систем, браузеров и продолжая смартфонами и приложениями на нем.

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

Сейчас, любой здравомыслящий отдел безопасности проводит тестирование продуктов, поскольку появилось очень много маркетинга и любой продукт сейчас "самый лучший в мире".  Любой, кто прослушал все презентации вендоров по ИБ теперь хорошо разбирается в презентациях вендоров по ИБ. Тестирование - по сути это и есть сертификация, которую все-равно проводят все заказчики. И слава богу (а кому еще?), этот пункт проверки соответствия включен в 239 приказ ФСТЭК.

Сейчас сертификация, уровень доверия и криптография связаны, поэтому сертифицировать можно только обрубленный функционал, который возможно еще как-то проверить. Алексей Лукацкий в своем блоге уже привел пример, почему сейчас NGFW нельзя сертифицировать: можно сертифицировать только L4 firewall, без VPN, SSL и удаленного управления, ведь SSH и HTTPS для управления уже нельзя использовать.

Итак, сертификация - это хорошо и правильно, но она не достигает цели, потому что

- сертифицирован всегда старый код, который уже не актуален;

- сертифицирован только обрезанный код продукта, который не является лучшим современным решением;

- обновления не приходят своевременно, как нужно для реальной защиты;

- управление группой устройств с одной точки и их обновлениями чаще всего отключается.

Можно ли изменить процесс сертификации, чтобы актуальная защита была проверена быстрее?

Почему компании, купив L7 firewall, настраивают правила L4

В то время как я писал статью про разницу L4 и L7 правил, я еще не думал, что реально, покупая NGFW компания по сути покупает еще 

- обучение сотрудников

- внедрение новых процессов

Обучение сотрудников и процессы

Оказалось, что те два сотрудника (которых как правило отправляют на обучение по NGFW после покупки) никак не влияют на всех сотрудников компании. Они начинают жить в своем L7 мире, а все другие сотрудники остаются жить с обычными L4 вендорами. Происходит разрыв шаблона. 

Для 99% ИТ сотрудников является нормальным открыть наружу в Интернет порт 80. А для обученных в инновационных компаниях двух сотрудников это дико - ведь по 80 порту ходит 1332 разных приложения и какое реально L7 приложение они должны пропустить по этому порту? L4 люди забывают сказать, потому что они просто не в курсе, что приложений много, а не только браузер. Вы как думаете? Вот что можно разрешить на порту 80, если поискать по протоколу tcp и порту 80 в базе приложений NGFW:

Соответственно, идеология L4 отражается в HelpDesk системах: они содержат просьбы открыть им только порты, без объяснения, что за приложения реально нужны. 

А если нужно открыть более сложные приложения, например в DMZ, то я просто в ужасе что же пишут в запрос (тикет) cлужбы поддержки. В ужасе, потому что догадываюсь!

И этот тренд 2019 года продолжают сам вендора которыми мы пользуемся. Если читать их документацию, то они пишут про что? Про L4 правила! Например, если нужно открыть Microsoft Skype For Business, существует только документация портовая у компании Микрософт! Здрасьте, приплыли!

Вот что по мнению Микрософт должен сделать владелец L4 Firewall:

Что делает владелец L4 firewall глядя на этот список? Правильно! Он разрешает все порты выше 1024 на сервер! Ему же надо доступ дать, а не башню на танк поднять (я про анекдот).

В то время как владелец NGFW должен разрешить одно приложение ms-lync. Удобно ли это? Ему удобно, бизнесу удобно, и компании безопасно и быстро! Ну впрочем, если, правда, в компании безопасность - важна и сотрудников ИТ - ценят.

Итог

В итоге к чему я клоню. Мне как сотруднику компании, которая придумала и сделала NGFW - выговор. Я должен позаботиться, чтобы все ИТ сотрудники знали, что существуют более удобные методики межсетевого экранирования. А я этим не занимаюсь? Занимаюсь, но недостаточно.

А надо ли это этим счастливчикам, которые живут в L4 и разрешают все возможные 1332 приложения по порту 80 всем?  

5G, CIoT, NB-IoT, LPWAN и другие технологии защищены в межсетевом экране K2

https://www.paloaltonetworks.com/solutions/industries/service-providers/mobile-network-operators

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

Развитие технологий происходит очень бурно особенно мир IoT. Мир идет в сторону LPWAN (Low-power Wide-area Network — «энергоэффективная сеть дальнего радиуса действия») куда может быть подключено огромное число различных датчиков.

Или другой стандарт NB-IoT (поддерживаемый Huawei, Ericsson, Qualcomm и Vodafone), который предлагает подключать неиспользуемые полосы 200 кГц для подключения миллиардов устройств IoT через «глобальные сети с низким энергопотреблением». Это могут быть медицинские датчики или системы умного дома, удаленный сбор данных счетчиков воды и электроэнергии, контроль влажности, пожаров, уровня воды.

Ожидается что к 2025 году в мире будет 25 миллиардов подключенных устройств IoT.

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

Одновременно такие датчики содержат небольшие процессоры, память и программисты  и пользователи не ставят задачи их защиты. Посмотрите даже на свои устройства bluetooth: у вас стоит пароль по-умолчанию 0000? И вы ни разу не захотели его поменять?

Мир пестрит объявлениями об удаленных взломах самолетов и автомобилей, что уж говорить про простейшие датчики и создании целых бот-сетей на их основе Mirai, Satori, Asuna. Вот пример бота RIFT, который использует сразу 17 эксплойтов https://threatpost.ru/iot-botnet-rift-targeting-17-cves/30347/

Устройство OwnStar для взлома системы управления автомобилем компании General Motors OnStar RemoteLink.

В 2018 году компания Palo Alto Networks выпустила впечатляющий по скорости 1 Террабитный межсетевой экран K2 специально для защиты от новых угроз. K2 защитит мобильную сеть от штормов сигнализации, включая различные атаки на туннельном уровне и уровне приложений, проходящие через сети GRX / IPX на интерфейсах S8, S6a / S6d. Этот межсетевой экран был представлен также на Mobile World Congress 2019. Его задача - определение приложений, какие бы они не были: медицинские, ICS/SCADA, телеком, транспорт, нефтяные или энергетические системы. После задач визуализации того что творится, его задача знать и защищать от уже известных атак и также обнаруживать новые атаки методами корреляции с уже имеющимися знаниями всего мира и на основе поведенческого анализа. 

Однажды слышал на конференции "В общем тут артифишал интелидженс на биг дата". Что-то в этом есть ;-)

K2 серия межсетевых экранов Palo Alto Networks поддерживает все возможные применения мобильных устройств: роуминг, RAN, SGi, защита доступа к не-3GPP сетям.

Таким образом типовые схемы инсталляции:

• Защита от угроз Интернет (S/Gi)
• Защита роуминга (S8/Gp)
• Radio access network security (S1/S11)
• Non-3GPP network access (S2)
• IoT безопасность
• Защита сигнализации

Выступление на MWC2019 "K2 series 5G Firewall"

https://www.cnbc.com/video/2019/03/21/its-hard-to-say-whos-ahead-in-the-5g-race-palo-alto-networks.html

Список сертифицированных ФСТЭК России МСЭ и СОВ на 29 июля 2019 года

Реестр ФСТЭК в части по сертифицированным межсетевым экранам (МЭ) и системам обнаружения вторжений (СОВ) содержит много информации, включая сертификаты под сертифицированные отдельные образцы. Я выписал оттуда данные по тем продуктам, что сертифицированы как серия, поскольку если лишь несколько штук, то это уже проданные кому-то экземпляры под какой-то проект. 

Мне не удалось обнаружить у многих производителей в тексте сертификата номер их версии операционной системы, которая была сертифицирована.  А ведь версия важна, потому что если в сертифицированной версии есть уязвимости, то тогда сертификат работает только с применением дополнительных мер защиты устранящих уязвимость.
Также нужно проверять сертифицирована ли система управления. Это оставлю на потом.

Сертификат МЭ.А4 на серию действует у следующих межсетевых экранов
Наименование	Версия	Номер сертификата	Действует до
Рубикон-К		3290	02.12.2020
Check Point 77.10	77.10	3634	03.10.2019
ViPNet Coordinator HW 4		3692	26.01.2020
FortiGate 5.4.1	5.4.1	3720	16.03.2020
Traffic Inspector		3834	04.12.2020
UserGate UTM C, D, D+, E, E+, F, X1		3905	26.03.2021
С-Терра Шлюз 4.2		4058	27.12.2023
Diamond VPN/FW		4066	24.01.2024
Huawei 63XX, 66XX, 95XX версия V500	V500	4083	04.02.2024
ViPNet xFirewall 4		4093	13.02.2024
Застава-150 VPN/FW		4125	14.05.2024
Сертификат МЭ.А5 на серию
нет таких межсетевых экранов
Сертификат МЭ.А6 на серию действует у следующих межсетевых экранов
Наименование	Версия	Номер сертификата	Действует до
Сisco ASA 5506-X, 5508-X, 5516-X версия 9.*	9.*	3973	25.07.2021
Huawei Eudemon 8000E-X3 версия V500	V500	3909	05.04.2021
Cisco ASA SM-1 версия 9.* (снят с продажи)	9.*	3909	27.02.2021
Сертификат СОВ.С4 на серию действует у следующих устройств
Наименование	Версия	Номер сертификата	Действует до
HP TippingPoint		3232	12.09.2020
Рубикон-К		3290	04.12.2020
Сheck Point 77.10	77.10	3634	03.10.2019
FortiGate	5.4.1	3720	16.03.2020
ViPNet IDS 2	2.4	3804	10.10.2020
ИВК СЕНСОР		3868	24.01.2021
UserGate UTM		3905	26.03.2021
Кречет		3911	06.04.2021
Аркан		3976	27.07.2021
Kaspersky Industrial CyberSecurity for Networks		4027	25.10.2023
Positive Technologies Network Attack Discovery		4042	30.11.2023
Аргус		4048	19.12.2023
С-Терра СОВ		4055	24.12.2023
Diamond VPN/FW		4066	24.01.2024
Сертификат СОВ.С5 на серию действует у следующих устройств
Наименование	Версия	Номер сертификата	Действует до
Cisco ASA Firepower 6.2, ASA 55XX-X		3904	19.03.2021
Сертификат СОВ.С6 на серию
никому не выдан

Результаты общего тестирования межсетевых экранов в компании NSS Labs 2019 года

Сегодня ночью опубликован отчет NSS. В 2019 году в тесте NGFW NSS Labs участвовали следующие устройства:

• Barracuda Networks CloudGen Firewall F800.CCE v7.2.3

• Check Point Software Technologies 6500 Security Gateway R80.20

• Forcepoint 2105 NGFW v6.3.11

• Fortinet Fortigate 500E v6.0.4 build 0231

• Huawei USG6620E v600R006C00SPC310

• Palo Alto Networks PA-5220 PAN-OS 8.1.6-h2

• Sophos XG 750 Firewall SFOS v17.5

• SonicWall NSa 4650 SonicOS v6.5

• Versa Networks FlexVNF v16.1R2-S7

• WatchGuard Firebox M670 Firmware: 12.3 B589695 Ver-4.907

Из этого списка на российском рынке присутствуют в основном Check Point, Fortinet, Huawei и Palo Alto Networks. Также изредка я вижу Sophos и Barracuda. Компания Cisco со своим  решением FirePower в этом году в тесте NSS Labs не обнаружена.

Мне лично приятно, что Palo Alto Networks NGFW стал лидером этого тестирования (самый верхний зеленый кружок) Зеленый означает, что мы обнаружили все техники обхода.

Диаграмма без имен: https://www.nsslabs.com/ngfw-svm-graphic

Результаты все публично доступны на сайте NSS и все три отчета: сравнительный между производителями, конкретно по модели PANW PA-5220 и обзорный SVM более детальные можно скачать отсюда.

Новые тренды на рынке ИБ

Новые тренды на рынке ИТ и на рынке ИБ

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

Информационная безопасность неотделима от ИТ! Только если ты хорошо знаешь сетевые технологии, то ты можешь хорошо защищать сети, если ты хорошо знаешь операционные системы, то можешь хорошо их защищать и так далее.

Контейнеры

Сотрудники ИТ все чаще используют контейнеры вместо виртуальных машин. Такие слова как Docker, Kubernets, Pod, OpenShift активно используются сотрудниками многих компаний. Знаете ли их вы и знаете ли вы проблемы в ИБ в них, как безопасники?

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

Одновременно у контейнеров уже найдены уязвимости и уже были взломы, например, взлом и использование затем мощностей Тесла для зарабатывания криптовалюты был основан на уязвимостях Kubernets.

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

Например, продукт компании https://www.twistlock.com/ позволяет визуализировать контейнеры, показать уязвимости, защитить контейнеры во время их работы, создать внутреннюю сегментацию в рамках одного хоста с контейнерами.

Function as a Service или бессерверные вычисления

Да, уже есть такие типы облачных сервисов как IaaS, PaaS, SaaS и даже SecaaS, теперь еще и FaaS, когда вы платите поставщику сервиса за исполнение ваших функций, а не операционных систем или приложений. Впервые такое сервис предоставила в 2014 году AWS Lambda, затем уже Google Cloud Functions и Microsoft Functions. Также эту технологию называют бессерверные вычисления. То есть вы передаете сервису для обработки какую-то функцию которая вам нужна в данный момент. Это очень удобно масштабировать и позволяет резко усилить возможности компании в период отчетности или наплыва запросов клиентов, например, в конце квартала или года.

И у этих технологий тоже уже есть уязвимости, например, в данном видео в поле с именем файла PDF для отдела HR вставляется команда curl для скачивания дополнительного кода с pastebin и этот код выполняется на сервере FaaS и результат атаки впечатляет. Как от этого защититься?

Существуют компании, которые занялись защитой Serverless технологий, например, компания PureSec, в продукте выполняется контроль работы таких приложений и даже есть WAF для проверки входящих запросов к сервисам.

SOAR и автоматизация

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

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

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

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

Например, Demisto может собрать нужные индикаторы IOC, затем проверить их с полученными в инциденте IP, URL, DNS адресами, хешами и др. Затем автоматически настроить сиетемы защиты на из блокировку, оповестить людей и сформировать графический отчет о своей работе.

Вот так выглядит простейший Playbook когда вы сравниваете свой файл с базой Threat Intelligence например из Facebook и затем со следующей базой, например, с VirusTotal и так далее.

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

Пример автоматизации Demisto + песочницы Palo Alto Networks Wildfire + системы Threat Intelligence Autofocus

Троян в BIOS или руткит в ОС можно обнаружить по сетевому трафику

На прошедшей неделе многие исследователи говорили о том, что проблемой современного мира является атака на цепочку поставок оборудования (supply chain). Существует угроза, что кто-то встроит закладку либо в плату, либо в BIOS в поставляемое вам оборудование. Сделать это можно бесконтрольно в любой точке логистики: от старта производства чипов до доставки собранного оборудования к вам.

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

Он привел несколько вариантов защиты на уровне ядра, загрузчика. На конференции  ICC.MOSCOW об этом же рассказал в своем выступлении (запись уже доступна) Тимур Биячуев.

Как вы видите на слайде Александра Матросова выше, защиты от трояна в BIOS нет. Так ли все плохо?

Как узнать, что ваш BIOS содержит троян?

Существует одна проблема для атакующего - ему нужно каким-то образом передавать информацию из кода запущенного из BIOS в сторону своего создателя или центра управления. Для этого трояну приходится использовать сеть компании, в которой стоит данное взломанное оборудование, будь то сервер, роутер, сотовый телефон, кофемашина (угрозы IoT) или станок (если мы говорим про защиту ICS/SCADA).

И злоумышленники понимают, что в сетевом пакете им спрятаться некуда. Да, они могут зашифровать само передаваемое сообщение, но сам сетевой пакет им спрятать некуда - он виден в сети и этот неожиданный пакет от конечного оборудования будет замечен и, возможно, заблокирован. Поэтому обычно используются соединения по типовым открытым портам в сети: порт 80, порт 53, порт 123. Смотрите ли вы за всеми неожиданными пакетами в своей сети?

Концепция Zero Trust

Существуют продвинутые безопасники, которые в курсе методологии Zero Trust - безопасно разрешать только те соединения изнутри сети наружу, которые реально нужны для работы. Если в вашей сети соединения в стиле permit any any для всех хостов в сети друг к другу и к Интернет, то безопасности никакой нет и межсетевой экран совершенно бесполезен. Если вы хотите усилить свою безопасность, предлагаемая методика - для вас.

О концепции Zero Trust говорят во всем мире уж лет пять, например, презентация Данила Дрожжина (КРОК) и Евгения Кутумина (PANW) про Zero Trust и реализацию его на межсетевых экранах Palo Alto Networks:

Соответственно, презентация выше о том, что если вы применяете технологию Zero Trust, то вы должны не просто купить лучший в мире межсетевой экран, а еще и важно настроить его правильно. И в этом случае утечь из вашей сети информация из трояна НЕ МОЖЕТ, пока вы ее сами не разрешили.

NGFW отлично справляются с различными видами туннелирования, типа TCP-over-DNS и техниками обхода защиты, например, использования чужого порта другого приложения (например, передавать данные по 80 или 53 порту, которые обычно быть открыты). С правильно настроенным NGFW вредоносному коду сложно бороться.

Как найти несанкционированные соединения в Интернет на своем межсетевом экране. Практика. 

Посмотрите в трафик своей сети и соберите статистику используемых вашими сотрудниками приложений. Вы должны увидеть какие приложения передают трафик с каждого компьютера сотрудника или с сетевого устройства (принтер, роутер, сервер и др). Если у вас NGFW, то каждое соединение "раскрашено" контекстом: что за приложение L7 используется, какая страна, какой URL, какой конкретно сотрудник работает на компьютере, какие типы файлов внутри и др.

Пример: Unknown-TCP

На приведенном ниже скриншоте из вкладки ACC показан dashboard "TOP 10 приложений L7", вы видите, что в сети за последний час были соединения, которые помечены как unknown-tcp. Эта информация должна вас встревожить, потому что в сети компании обычно 200-300 приложений разного типа, и встроенный в NGFW детектор приложений их все "знает", то есть обнаруживает и блокирует, какими бы сложными они не были. На данной картинке видно, что за час сделано 36 сессий TCP, контент которых межсетевой экран не понял, поэтому пометил как unknown-tcp. Картинку можно кликнуть и увеличить:

Что наличие приложения unknown-tcp значит для вас? Наличие неизвестного соединения TCP или UDP или ICMP на NGFW - это инцидент. Нужно проводить расследование!

Проведем расследование инцидента c unknown-tcp используя возможности Palo Alto Networks NGFW

Начнем с простого: посмотрим в какие страны идут эти неизвестные соединения. Включим глобальный фильтр по исследуемому приложению unknown-tcp (видно слева на картинке, что фильтр включен). Посмотрим в dashboard Destination Regions, на котором показаны страны, в которые идет unknown-tcp:

Видно, что за 7 последних дней соединения были с Англией, США, Аргентиной, Россией, Германией, Францией, Китаем, Ирландией. Здесь выводы зависят от вашей сети и от вашего бизнеса. Обычно самые подозрительные - это редкие соединения! 5 раз соединялись с Китаем: кто, почему, зачем? Если вы не ведете бизнес с Китаем, то конечно вас должны заинтересовать все соединения в Китай из вашей сети - то есть вы их будете расследовать как более подозрительные. (Я встречал у заказчиков неизвестные им IPSEC туннели в Китай, хотя вроде как IPSEC в Китае разрешен далеко не всем.)

Следующим шагом можно перейти уже в подробный журнал и вывести на экран все соединения, например, давайте посмотрим все соединения с Китаем по unknown-tcp. Для простоты есть специальная кнопка в виджете Destination Regions - кликаем на кнопку и переходим из вкладки ACC (скриншот вкладки ACC был выше, где были dashboard со статистикой приложений в сети) во вкладку Monitor и в журнал Traffic - в нем журналируется каждое соединение и одновременно хранится обогащенная контекстом информация по этому соединению. Здесь на картинке вы видите уже все соединения, а не просто статистику:

NGFW для unknown-tcp собрал PCAP пакетов, поэтому у вас есть возможность кликнуть на зеленую стрелку (напротив каждой строки соединения) и посмотреть что же за контент был передан в Китай. Также можно скачать себе на компьютер в виде файла PCAP эти собранные пакеты, чтобы посмотреть в Wireshark.

На картинке выше вы видите, что была применена типовая тактика обхода защиты - соединение было сделано по tcp/80 порту, который открыт практически в любой компании (потому что по порту 80 работают все браузеры).

Движок детекта приложений межсетевого экрана (далее APP-ID) не увидел в передаваемом трафике никакого WEB контента и, более того, не увидел никакого известного ему типа трафика вообще. В базе NGFW хранятся тысячи паттернов приложений L7 - они все были проверены на этому трафике и никакой из них не подошел! Посмотрите всю базу приложений Palo Alto Networks на сайте applipedia.paloaltonetworks.com. Раз никакой тип трафика не был обнаружен движком APP-ID, то данный трафик был помечен как unknown-tcp. Мы с вами увидели как реально обходят защиту и увидели как этот обход защиты обнаружить.

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

Приведенный мной метод как никогда актуален, особенно в сетях с критический инфраструктурой.

Чтобы расследовать инцидент дальше нужно разбираться с владельцем конечного устройства: смотреть что работает в памяти устройства и зачем "оно" что-то отправляет в Китай.

Прелесть периметровой защиты в том, что в одной точке вы контролируете сразу все свои тысячи устройств всеми умеющимися у вас индикаторами атак.

Что дальше?

Полное описание лучших практик и стратегии защиты вашей сети на периметре и в том числе методология защиты Zero Trust, есть в виде записи вебинара Евгения Кутумина:

Важное замечание

Заражают не только BIOS. Заражают все виды устройств и софта. И там хакеры тоже используют туннели. Важно будет добавить, что любое приложение 7 уровня может являться транспортом для туннелей: тот же DNS или SSL туннель или HTTP может быть туннелем чего-то нелегитимного. И тут уже помогают сигнатуры IPS и anti-spyware - включайте их все, пожалуйста, неважно какая у вас сеть: телеком, банк, завод, больница, отель или автозаправка.

Сейчас я бы обращал еще внимание на туннели на основе websocket - например, прямо сейчас посмотрите имеющимися средствами кто использует websocket в вашей сети и задайтесь вопросом: зачем? 

Какие трудности переживает сейчас любой SOC

Какие трудности переживает сейчас любой SOC, включая ГосСОПКУ?

• мало сотрудников
• много событий
• мало времени на расследование и тем более Threat Hunting
• много утилит, что скорее плохо, чем хорошо, между ними нет интеграции.

По данным уже расследованных взломов обнаружение факта что вас взломали происходит через 2-6 месяцев после взлома и это при наличии в крупных компаний таких передовых продуктов, как EDR,  UEBA, NTA, SOAR и других.

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

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

На диаграмме ниже показано как раскрывает причинно-следственную связь продукт XDR компании Palo Alto Networks. По сути он разворачивает последовательность действий, которые предшествовали обнаружению и блокированию атаки. Если вы увидели, например, событие что локальная защита заблокировала вирус и затем попросили продукт рассказать историю, то на экране появляется картинка что же было до того как случилось. И это можно сделать нажатием одной кнопки, а не блужданием по всем утилитам и логам, что есть в компании. В данном случае - человек получил фишинговое письмо и кликнул на ссылку в нем:

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

Сколько нужно места, чтобы хранить эту всю информацию до того момента как она понадобится. Вот что сказали сотрудники исследовательской лаборатории Palo Alto Networks, приехавшие из Тель-Авива: "Для хранения событий 200 рабочих станций выделяется 1 террабайт на 1 месяц в Cortex Data Lake". А поскольку компании сейчас гораздо крупнее и распределены по всему миру, то можно представить что места требуются уже даже не террабайты, а петабайты. 

Единственным адекватным решением, которое сегодня видят разработчики - использовать для хранения журналов и событий облачные хранилища, предоставляемые крупными провайдерами: Google Cloud, Microsoft Azure, Amazon AWS и другие. Компания Palo Alto Networks предоставляет такое хранилище для журналов NGFW, UEBA, NTA, EDR/AET, облачных приложений под торговой маркой Cortex Data Lake. И на основе этого хранилища можно реализовать различные аналитические решения, как например было реализовано решение Cortex XDR.

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

Одновременно в мире идет работа над способами обмена информацией о расследованных инцидентах и индикаторами атак, которые уже были совершены. Для этого компании составляют Playbook действий хакеров и делятся друг с другом, например, лаборатория UNIT42 компании Palo Alto Networks свои исследования выкладывает тут https://pan-unit42.github.io/playbook_viewer/

Методики работы атакующих записываются в специальных TTP, что означает Tactics, Techniques, Procedures. И даже по набору TTP можно различать этих атакующих и можно отличать даже что за кампанию они сейчас развернули и на кого она нацелена.

И одновременно продукты безопасности встраивают в себя алгоритмы обмена и проверки таких индикаторов атак. Примерами таких стандартов обмена являются:

• TAXII™ = Trusted Automated eXchange of Indicator Information
• STIX™ = Structured Threat Information eXpression
• СybOX™ = Cyber Observable eXpression

Существует глобальная база TTP - MITRE ATT&CK  и по ней ваши blue и read team могут проверять готовность компании противостоять описанным методикам и техникам взлома.

Недавно было проведено тестирование продуктов по безопасности, насколько эффективно они работают и по результатам всех опережает продукт TRAPS который обладает уникальными функциями защиты рабочих станций и одновременно является сенсором событий для Cortex XDR: