Архитектура защищенных сетей. Perimeter Layer

Citation preview

Экспресс курс по основам ИБ

Архитектура защищенных сетей Perimeter Layer Ольков Евгений, 2023 netskills.ru

Оглавление От Автора Благодарности О чем эта книга? Для кого эта книга? 1. Стратегия комплексной защиты 1.1 Уровни защиты 1.2 Дополнительные технические меры 2. Архитектура защищенной сети 3. Perimeter Layer 4. UTM/NGFW/Network Firewall 4.1 UTM - Unified Threat Management 4.2 NGFW - Next-generation firewall 4.3 UTM vs NGFW (Network Firewalls) 4.4 Типовой дизайн сети с NGFW 4.4.1 Модульный дизайн 4.4.2 Север-Юг / Запад-Восток 4.5 Ключевые игроки рынка Network Firewalls 4.5.1 Check Point 4.5.2 Palo Alto Networks 4.5.3 Fortinet 4.5.4 А что же с Cisco? 4.5.5 Sangfor - новый зарубежный игрок 4.6 Отечественный рынок 4.6.1 UserGate 4.6.2 АПКШ Континент (Код Безопасности) 4.6.3 xFirewall (ИнфоТеКС) 4.6.4 PT NGFW (Positive Technologies) 4.7 CPU, ASIC, FPGA 4.8 Ключевые проблемы Network Firewalls 4.9 Бесплатные решения 4.10 Резюме по Network Firewalls 5. Email Security 5.1 Проблемы шифрования 5.2 SEG vs CAPES 5.3 Главные угрозы Email 5.4 Типовой дизайн сети с Email Security 5.5 Ключевые игроки рынка 5.5.1 Cisco Email Security 5.5.2 FortiMail 5.5.3 Microsoft

4 5 6 8 9 10 13 15 16 17 18 21 25 26 27 29 30 31 32 33 34 34 35 38 39 39 40 41 45 50 50 52 53 56 57 60 62 64 65 65

1

5.5.4 Trend Micro 5.5.5 Check Point 5.6 Отечественный рынок 5.6.1 Kaspersky 5.6.2 Dr.Web 5.6.3 F.A.C.C.T. (Group-IB) 5.7 Ключевые проблемы Email Security 5.8 Бесплатные решения 5.9 Резюме по Email Security 6. WAF 6.1 WAF vs NGFW 6.2 Ключевые угрозы web-приложений 6.3 WAF vs WAAP 6.3.1 Классический WAF 6.3.2 WAAP 6.3.3 Cloud WAAP 6.3.4 NGFW с модулем WAF 6.4 Типовой дизайн сети с WAF 6.5 Ключевые игроки рынка 6.6 Отечественный рынок 6.6.1 PTAF 6.6.2 WebmonitorX 6.6.3 SolidWall WAF 6.6.4 Nemesida WAF 6.6.5 Континент WAF 6.6.6 Check Point AppSec 6.7 Бесплатные решения 6.8 Ключевые проблемы WAF 6.9 Резюме по WAF 7. Sandbox 7.1 Типы Sandbox и варианты интеграции 7.2 Типовой дизайн сети с Sandbox 7.3 Ключевые технологии песочниц 7.3.1 Типовая архитектура песочницы 7.3.2 Виды анализа 7.3.3 Динамический анализ 7.3.4 Техники обхода песочниц 7.3.5 Очистка содержимого 7.4 Ключевые игроки рынка 7.5 Отечественный рынок 7.5.1 PT Sandbox 7.5.2 Kaspersky Sandbox

66 67 68 69 71 72 73 74 76 77 78 82 84 84 85 90 91 91 93 95 95 95 96 97 98 98 99 100 101 102 105 108 109 110 111 112 114 116 117 120 121 122 2

7.5.3 Group-IB TDS / Polygon 7.5.4 AVSOFT ATHENA 7.6 Бесплатные решения 7.7 Ключевые проблемы песочниц 7.8 Резюме по Sandbox 8. Другие средства защиты на Perimeter Layer Вместо заключения

124 124 125 126 129 130 132

3

От Автора Приветствую, Читатель. У тебя “в руках” (не у всех есть печатная версия) моя вторая книга из новой серии по информационной безопасности. Первая книга “Азы КиберБезопасности”, которая вышла практически год назад. Если вы ее не читали, то крайне рекомендую начать именно с нее, т.к. эта книга является ее логическим продолжением. На текущий момент это моя самая большая книга на написание которой я потратил в общей сложности более 100 часов. Может показаться, что это немного, но если учесть, что в день я тратил не более 1 часа (в утреннее или вечернее время), иногда делал большие перерывы (отпуск, плохое настроение, лень), то получается довольно неплохой срок - почти год. Конечно же здесь не учитывается время, которое я тратил на изучение тех или иных продуктов, но это часть моей работы. Все это время книга висела на душе мертвым грузом, поэтому я безумно рад, что закончил ее и смогу заняться следующим “проектом”. Вообще, данное руководство отлично иллюстрирует то, что можно успеть сделать даже за относительно небольшой промежуток времени. Требуется просто регулярность и дисциплина, которая у меня тоже хромает… Спешу предупредить, что книга не проходила профессиональной редактуры и с большой долей вероятности вы встретите тут много ошибок. Заранее прошу прощения. К вам, Читателям, у меня лишь одна просьба - ценить труд автора и не распространять данное руководство в сети Интернет. Этим вы поддержите наш проект и смотивируете на написание новых обучающих материалов. Большое спасибо за проявленный интерес. Желаю приятного и, надеюсь, полезного чтения!

4

Благодарности Я бы очень хотел поблагодарить несколько людей без которых, возможно, данная книга не появилась бы вообще, либо была гораздо хуже: 1. Моя жена - Ксения. Человек, который всегда и во всем поддерживает меня. 2. Мой друг и коллега - Виталий Айрапетов. Человек, который настоял на идее этой книги и сделал первый запрос на подобное руководство. 3. Мой коллега - Сергей Григорьев. Человек, который был главным “испытуемым”, первым читал мои черновики и давал ценный фидбек. 4. И конечно же мой сын - Степан. Это мой главный мотиватор во многих начинаниях. Ребята - большое спасибо!

5

О чем эта книга? Считаю очень важным сразу обозначить, о чем эта книга. Затрагиваемые темы очень обширны и естественно невозможно описать все аспекты. Поэтому весьма важно понимать цель этой книги. Если вы помните предыдущую книгу “Азы КиберБезопасности”, то там мы в большей степени затронули основы ИБ и как грамотно подойти к этому вопросу, чтобы уберечь компании от беспорядочной закупки различных средств защиты. Мы описали важность аудита активов, оценки рисков, основные драйверы безопасности, типовой ИБ процесс, политику безопасности и много другое. Здесь же мы сконцентрируемся именно на технических средствах защиты, которые используют на периметре сети. Почему мы начинаем именно с периметра? Об этом буквально в следующей главе. У меня не было задачи рассказать какое решение лучше или какая технология является наиболее перспективной. Я хотел собрать и показать целостную картину ИБ. Сложить все пазлы, так сказать. На рынке существует огромное количество ИБ решений с различной аббревиатурой, которая, на самом деле, может обозначать одно и то же. Многие средства защиты могут дублировать функционал друг друга. Довольно легко запутаться. Мне хотелось показать эти решения немного с другой стороны - со стороны задач и проблем которые они решают. Рассказать про предпосылки появления этих решений, как они эволюционировали и в чем конкурируют друг с другом. Затем подробно описать, как все эти технические средства “приземляются” на типовую архитектуру корпоративной сети. Отсюда и название - “Архитектура защищенных сетей”. Здесь важный момент - мы будем рассматривать ИБ решения именно в разрезе корпоративных сетей. ЦОД сети, сети операторов или сети АСУ ТП имеют значительные отличия. Если у вас нет представления, что такое корпоративная сеть, какие основные модули в ней есть и как она строится, то очень рекомендую к прочтению мою самую первую книгу “Архитектура корпоративных сетей”, которую я написал почти 10 лет назад. Но вернемся к нашей теме. Чего вы НЕ найдете в этой книге? - примеры настроек описываемых решений; - маркетинговые сравнения функционала; - результаты тестирования; - стоимость решений. Если вы искали что-то из списка выше, то вам нужна другая книга. Заранее извиняюсь. Какие же классы средств защиты будут рассмотрены в этой книге? Мы подробно опишем наиболее востребованные решения для защиты периметра сети: 6

- NGFW/UTM - Email Security - WAF - Sandbox Если вам не знакомы данные аббревиатуры - не пугайтесь, мы подробно распишем каждый класс. Я попробую описать наиболее важные (на мой взгляд) и концептуальные вещи: - Ключевые классы средств защиты для безопасности периметра сети. - Принципы работы этих средств защиты. - Причины необходимости этих решений и от чего они должны защищать. - Особенности реализации этих решений, как архитектурные, так и концептуальные. - Частые заблуждения по поводу этих средств защиты. - Ключевые игроки рынка, как зарубежного, так и отечественного. - Типовой функционал, который требуется от этих решений. - Типовой дизайн корпоративной сети с применением этих средств защиты. Место расположения, модульность дизайна и т.д. - Ключевые проблемы этих решений и на что стоит обращать внимание при выборе. - Бесплатные альтернативы коммерческих решений (если они есть). После прочтения этой книги вы сможете (я надеюсь) уверенно ориентироваться практически во всех ключевых решениях и технологиях по защите периметра, будете понимать как и для чего они работают, как друг друга дополняют, в какой части сети должны внедряться, какие альтернативы существуют и на что опираться при выборе конкретного вендора. Вот лишь небольшой перечень вендоров, которые будут рассмотрены в этой книге: Cisco, Check Point, Fortinet, Palo Alto, Sangfor, Microsoft, TrendMicro, UserGate, Код Безопасности, Инфотекс, Kaspersky, Positive Technologies, Group-IB, Dr. Web, Wallarm, SolidWall, Nemesida, AVSOFT и т.д. Надеюсь, что заинтересовал вас.

7

Для кого эта книга? Не менее важный вопрос - для кого написана эта книга? Я бы разбил потенциальных читателей на четыре больших категории: 1. Инженеры. Книга отлично подойдет для тех, кто внедряет, администрирует или поддерживает различные ИБ решения. Инженеры смогут взглянуть на свою работу “со стороны” и увидеть ее смысл в разрезе архитектуры защищенных сетей. Осмысленность своих действий крайне важна в любом деле, поэтому очень важно видеть всю картину, а не ее отдельную часть. 2. ИБ/ИТ менеджеры. Управленцы в самом широком смысле этого слова ИТ и ИБ директора. С помощью данного руководства можно очень быстро актуализировать и структурировать свои знания в сфере защиты корпоративных сетей. Плюс, книга позволит увидеть возможные альтернативы на рынке, что особенно важно в последние пару лет после введения санкций. 3. ИБ/ИТ продавцы. Это могут быть “сейлы” интеграторов, дистрибьюторов и даже вендоров. Несмотря на обилие технических терминов книга будет понятна даже тем, кто никогда не работал с ИБ решениями с технической точки зрения (администрирование, внедрение и поддержка). Данное руководство позволит понять типовую архитектуру защищенных сетей и принципы ее построения. Продажа средств защиты перестанет быть просто строкой в бюджете партнера. Появится четкое понимание, что и от чего защищает, а также какие решения будут актуальны для конкретной компании. 4. Студенты. Куда же без них. Весьма трудно начинать карьеру в ИБ с нуля. Университеты пока не дают действительно нужных знаний. В Интернете же очень много разрозненной информации большая часть которой уже безнадежно устарела. Данная книга (вместе с “Азы КиберБезопасности”) будет отличным стартом для карьеры. Повторюсь, очень важно изначально понимать, что и для чего ты делаешь. Т.е. понять концепт. В целом, данная книга должна пригодиться всем, кто хоть как-то интересуется сферой информационной безопасности. По крайней мере мне так кажется…

8

1. Стратегия комплексной защиты Начнем эту главу точно так же, как и в предыдущей книге «Азы КиберБезопасности». По работе мне часто приходилось общаться с людьми и обсуждать вопросы кибербезопасности. Я выслушал сотни докладов на эту тему, прошел множество курсов, прочел десятки книг, статей и поучаствовал в не меньшем количестве проектов. Но вся получаемая информация по прежнему была очень разрозненная и не структурированная. И только спустя некоторое время у меня начала формироваться четкая картина того, как именно должна строиться Информационная Безопасность компании. Тот, кто знаком с моим “творчеством”, наверняка знает, что я всегда стремился упростить сложные вещи, выделить ключевые моменты, оформить разрозненные мысли в виде понятных постулатов или формул. Не знаю, насколько верен такой подход, но я всегда придерживался его. В итоге я получил некий “фреймворк” (концепт архитектуры), которого я стараюсь всегда придерживаться. Не берусь судить, насколько он является верным. Просто хочу им поделиться. Давайте по порядку. Для обеспечения информационной безопасности в компании вам придется что-то делать, т.е. принимать какие-то меры. И первое, что вы должны четко усвоить - все меры защиты можно разбить на два больших класса. Это: 1. Административные меры Сюда входят такие вещи, как аудиты инфраструктуры, разработка политик безопасности, регламентация, документирование, периодические испытания, тренинги и даже бюджетирование. Мы подробно рассмотрели эти меры в книге «Азы КиберБезопасности». Именно с этих мер вы должны начинать процесс построения ИБ. Повторюсь, в очередной раз, ИБ это процесс, а не результат. Если у вас не выстроен процесс, то считайте, что у вас нет ИБ, даже если вы закупили самые дорогие ИБ решения. 2. Технические меры Здесь уже применяются совершенно конкретные средства защиты, как программные, так и программно-аппаратные комплексы (ПАК-и). Как было сказано еще в начале книги, этих средств защиты (а точнее классов средств защиты) огромное количество. Чтобы хоть как-то их сегментировать мы можем разбить технические меры на две большие группы: ●

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

9

«фреймворка» выделено 5 уровней защиты: Internet Layer, Perimeter Layer, Network Layer, Endpoint Layer и User Layer. Чуть позже мы обсудим их предназначение. ● Дополнительные технические меры - технические средства, которые позволяют получить максимум от всех уровней защиты, а также помогают запустить тот самый непрерывный ИБ процесс. Таким образом мы получаем следующую картинку нашего «фреймворка»:

Рассмотрим эти две группы чуть подробнее.

1.1 Уровни защиты Прежде чем начать, давайте еще раз внимательно взглянем на уровни защиты в нашем «фреймворке»:

10

Я специально выделил уровни разным цветом. Желтым - традиционные (обязательные) уровни, Красным - новые уровни, которые появились относительно недавно и еще не успели стать общепринятыми (что не отменяет их важности в современном мире). Все эти уровни содержат технические средства защиты. Давайте кратко опишем их в порядке исторического формирования: ● Perimeter Layer (уровень периметра) - максимальное сокращение площади атаки на ресурсы компании. Фильтрация контента, инспектирование разрешенного трафика, защита публичных ресурсов компании. Исторически, данный уровень защиты появился первым, на заре зарождения сети Интернет, когда появились первые межсетевые экраны. Как вы уже наверно поняли из названия, данная книга будет посвящена именно уровню защиты периметра. ● Endpoint Layer (уровень рабочих станций) - комплексная защита рабочих станций и мобильных устройств. Предотвращение угроз фишинга, шифровальщиков, вирусов, zero-day уязвимостей и т.д. с подробным расследованием инцидентов. Данный уровень сформировался вторым, с появлением первых антивирусов, когда стало понятно, что недостаточно защищать только периметр. ● Network Layer (сетевой уровень) - анализ внутреннего графика на предмет компрометации локальных узлов или поведенческих аномалий. Этот уровень появился третьим, как необходимость для выявления угроз, которые не были предотвращены на Perimeter и Endpoint уровнях. Одно из первых решений этого уровня - IDS/IPS (система обнаружения и предотвращения вторжений). ● Internet Layer (уровень Интернета) - поиск и предотвращение киберугроз вне периметра компании. Относительно «молодой» уровень защиты, который стал ярким свидетельством перехода компаний от пассивной защиты к активной. К этому уровню можно отнести решения из категории Threat Hunting, которые помогают искать актуальные угрозы для компании, еще до того, как они случились. ● User Layer (уровень пользователей) - повышение защищенности компании через обучение корпоративных пользователей основам информационной безопасности. Уровень очень быстро набирает популярность, т.к. Пользователи всегда являются самым слабым звеном в защите. На текущий момент существует огромное количество сервисов по повышению осведомленности пользователей (User Awareness). Должны ли все эти уровни присутствовать в любой ИБ архитектуре любой компании? Вовсе нет. Количество уровней и их состав определяется исключительно моделью угроз и зрелостью ИБ в компании. Но важно помнить, что любые ИБ меры эффективны только в комплексном подходе. Ни одно средство защиты вам не даст 100% гарантии. Для реальной защищенности вы 11

просто обязаны применять принцип эшелонированный защиты. Именно поэтому мы располагаем ИБ решения на разных уровнях сети. Чтобы показать эффективность эшелонированной защиты, давайте еще раз рассмотрим три главных вектора атаки на корпоративную сеть (мы это уже делали в предыдущей книге):

Email и Web угрозы закрываются на Perimeter Layer. Угрозы для рабочих станций или смартфонов блокируются на Endpoint Layer. Вроде логично. Но что делать если вирус все же проник в нашу сеть через эти уровни, либо был занесен иным образом (изначально зараженный коммутатор или сервер)? Попав в сеть зловред будет пытаться распространиться дальше по сети. При этом вредоносный трафик может даже не доходить до ИБ решений на периметре. Мы должны иметь инструменты, которые помогут детектировать подобную активность. Для этого и пригодится Network Layer со своими техническими решениями, будь то классический IDS/IPS или новомодные NTA/NDR/Honeypot решения. Таким образом мы сможем выполнять три главные технические задачи любого «безопасника»: ● Prevent. Как можно раньше обнаружить и предотвратить атаку. Мы должны пытаться сделать это сразу на нескольких уровнях корпоративной сети. ● Detect & Contain. Как можно быстрее обнаружить и локализовать успешную атаку (например, распространение шифровальщика по сети). Невозможно гарантировать 100% предотвращение всех возможных угроз, даже при использовании лучших средств защиты. Вы должны быть готовы к активным действиям после успешной атаки на ваши ресурсы и иметь соответствующие инструменты. ● Forensic & Respond. После того, как вы остановили атаку необходимо провести детальный анализ произошедшего. Как была совершена атака (entry point), какая уязвимость использовалась, каким данным был нанесен ущерб, все ли удалось восстановить и как предотвратить следующие атаки? Именно многоуровневый подход с использованием различных ИБ решений позволяет реализовать надежную защиту корпоративной сети. В

12

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

1.2 Дополнительные технические меры Уровни защиты это хорошо, но как же сам процесс ИБ? Откуда ему взяться? Эффективность построения ИБ всегда зависит исключительно от системности подхода и технические средства защиты здесь играют далеко НЕ самую важную роль. В большей степени эта системность (т.е. процесс) закладывается именно в Административных мерах. Но и среди технических средств защиты есть решения, которые помогают выстроить этот ИБ процесс. В нашем «фреймворке» они вынесены в отдельную группу - Дополнительные технические меры.

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

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

14

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

Уверен, что в таком виде “уровни защиты” гораздо удобнее для понимания. Мы четко видим где они применяются и какие классы средств защиты туда входят. Естественно, здесь перечислены не все возможные классы ИБ решений, но я и не ставил подобную цель. Это скорее минимальный и наиболее эффективный набор, который позволяет построить комплексную и эшелонированную защиту - скелет любой защищенной сети. Мне бы очень хотелось, чтобы после прочтения книги этот концепт прочно засел у вас в голове. Стоит отметить, что практически каждый представленный уровень защиты заслуживает отдельной книги. Мы же сосредоточимся именно на Perimeter Layer.

15

3. Perimeter Layer Как и было сказано ранее, уровни мы будем изучать в порядке их исторического появления. И так уж сложилось, что первым появился именно уровень Периметра. На заре его “зарождения” это был всего лишь межсетевой экран (или Firewall, как его называют), однако сейчас на данном уровне располагается сразу несколько классов средств защиты. Вот наиболее яркие представители: 1. NGFW/UTM 2. Email Security 3. WAF 4. Sandbox 5. DLP Мы подробно рассмотрим каждый (кроме DLP). Хоть у них и разный набор функций, почти у всех одна главная задача - предотвратить проникновение злоумышленника или зловредного трафика внутрь корпоративной сети из Интернета. Т.е. тот самый периметр - граница между внешним и внутренним миром. Исключение здесь представляют лишь DLP решения, которые наоборот предотвращают утечку “чувствительных” корпоративных данных во внешнюю сеть. К слову, данный функционал часто обозначают в составе современных NGFW/UTM решений (конечно же с “некоторыми” ограничениями). Но обо всем по порядку! Важность Perimeter Layer обусловлена не только историческим фактом появления, но и самим ландшафтом угроз. Как вы помните, три главных вектора атаки: Web, Email и Endpoint (ПК и смартфоны). На периметре мы можем закрыть два главных вектора (Web и Email), причем различными классами средств защиты, которые друг друга дополняют и усиливают. Практически все “безопасники” начинают строить защиту именно с периметра. При этом можно сказать со 100% уверенностью, что наиболее популярным решением по защите периметра является межсетевой экран и лишь затем следуют все вышеупомянутые классы. Почему так? Узнаем буквально в следующей главе! Уверен, что после прочтения этой книги, вы станете экспертом по защите периметра сети и будете отлично ориентироваться в современном рынке ИБ решений!

16

4. UTM/NGFW/Network Firewall Как только появились зачатки глобальной сети, всем стало очевидно, что необходимо как-то отделять свою инфраструктуру от общей сети (тогда еще не было понятия Internet). Если представить вашу сеть как крепость, то межсетевой экран это ворота, которые должны пропускать только своих горожан или их друзей.

Межсетевой экран как ворота в крепость (Design vector created by freepik www.freepik.com) Согласитесь, что защищать крепость окруженную стенами и имеющую всего один вход-выход гораздо проще! Как раз это и делает межсетевой экран (далее МЭ) - выстраивает стену с воротами вокруг вашей инфраструктуры. Ключевая задача МЭ - максимально уменьшить площадь атаки на вашу инфраструктуру. Собственно так и делали довольно долгое время. На МЭ разрешали только нужные tcp/udp порты, а все остальное запрещали. Делается это с помощью так называемых access-lists (списки доступа). Применялся

17

подход “запрещен весь трафик, который явно не разрешен”. Типовые порты, которые обычно разрешают на уровне периметра: ● tcp/80 - HTTP трафик ● tcp/443 - HTTPS трафик ● tcp/25 - SMTP трафик ● tcp/udp/53 - DNS ● и т.д. Однако, в скором времени стало очевидно, что этого недостаточно. Атаки могли совершаться и через разрешенные порты. Вот несколько типовых сценариев: 1) Пользователь открывает зловредный сайт (80 или 443 порт) и скачивает вирусный файл под видом нужного документа, картинки, архива и т.д. Стоит отметить, что даже известный интернет ресурс может быть “взломан” и стать точкой массового распространения вирусного контента. Такие случаи происходят на регулярной основе и под угрозу попадает огромное количество людей. 2) Этот же сайт может использоваться для эксплуатации известной уязвимости браузера пользователя и, как следствие, заражения рабочей станции. Пользователю даже не нужно ничего нажимать, заражение происходит автоматически в фоновом режиме. 3) Зараженная рабочая станция может использовать разрешенный протокол DNS для связи с командным центром злоумышленника. Т.е. несмотря на МЭ на периметре сети, вашим устройством будет управлять кто-то другой. Эта рабочая станция может быть использована для кражи данных, дальнейшей атаки на другие устройства сети или стать частью botnet сети (к примеру осуществлять DDoS атаки на сторонние ресурсы). Это лишь малая часть возможных сценариева. Но проблема очевидна недостаточно лишь ограничивать трафик, нужна проверка разрешенного! Так и появился концепт UTM.

4.1 UTM - Unified Threat Management Если коротко, то суть UTM — консолидация нескольких средств защиты в одном решении. Т.е. все в одной коробке или некий all inclusive. Что понимается под “несколько средств защиты”? Ниже представлено определение UTM от известной аналитической компании Gartner: “Unified threat management (UTM) is a converged platform of point security products, particularly suited to small and midsize businesses (SMBs). Typical feature sets fall into three main subsets, all within the UTM: firewall/intrusion prevention system (IPS)/virtual private network, secure Web gateway security (URL filtering, Web antivirus [AV]) and messaging security (anti-spam, mail AV).”

18

Т.е. типовой набор для UTM это: ● Firewall - классический межсетевой экран, который может ограничивать трафик на основе ip-адресов и портов. Практически все современные МЭ поддерживают технологию SPI (stateful packet inspection - инспекция пакетов с сохранением состояния), которая была придумана компанией Check Point. SPI исключает возможность подмены пакетов в рамках открытой сессии. ● IPS - система предотвращения вторжений (Intrusion Prevention System), которая позволяет выявлять вредоносный трафик на основе сигнатурного или поведенческого анализа. Мы посвятим этой теме отдельный параграф в Network Layer. ● VPN - виртуальная частная сеть (Virtual Private Network). Если коротко, то VPN позволяет организовать безопасный канал передачи данных практически через любое интернет подключение. Обычно эта технология используется для объединения филиалов в одну большую сеть (Site-to-Site VPN) или же для предоставления удаленного доступа сотрудникам к корпоративным ресурсам (Remote Access VPN). ● URL filtering - фильтрация интернет ресурсов. При этом блокировка может выполняться как по категориям сайтов (социальные сети, стриминговые сервисы, сайты для взрослых), так и по конкретным адресам. Изначально эта технология появилась в таких решениях как Proxy, но позже стала обязательной и для UTM. ● Web Antivirus - антивирус, который позволяет проверять безопасность скачиваемого контента с любых веб-ресурсов. Иногда его называют потоковым антивирусом, т.к. он должен уметь проверять файлы “на лету”, до того, как они дошли до компьютера пользователя. ● Anti-Spam - фильтрация СПАМ сообщений. По статистике, более 80% всех email сообщений в мире являются спамом. ● Mail Antivirus - антивирус для файлов или ссылок полученных по почте. Как было сказано ранее, электронная почта до сих пор остается главным вектором атаки. Злоумышленники могут присылать фишинговые письма, ссылки на зловредные ресурсы или вирусные файлы. Все это объединяется в рамках одного UTM решения, что проще с точки зрения интеграции, настройки, администрирования и мониторинга. В свою очередь это положительно сказывается на общей защищенности сети. При таком подходе, любое соединение, которое было разрешено на уровне МЭ, проходит дополнительную проверку на безопасность. Ниже представлен типовой сценарий обработки трафика: - URL Filtering проверяет разрешен ли ресурс, на который переходит пользователь. Возможно сайт находится в блок листе и доступ будет закрыт (несмотря на разрешенный 80 и 443 порт на уровне МЭ). 19

-

IPS отслеживает возможные аномалии в сетевом трафике и осуществляет сигнатурный анализ. Если сайт зловредный и пытается использовать известный эксплойт, соединение будет заблокировано. - Web Antivirus проверяет все файлы, которые пользователь может попытаться скачать. Некоторые файлы скачиваются автоматически при открытии веб-ресурса (картинки, js скрипты и т.д.), чем и любят пользоваться злоумышленники. Несмотря на все описанные преимущества UTM, когда они только появились, то их рассматривали исключительно для небольших компаний (SMB - small and midsize business), т.к. UTM не справлялись с большими объемами трафика. Это было по двум причинам: 1) Способ обработки пакетов. Первые версии UTM решений обрабатывали пакеты последовательно, каждым “модулем”. Пример: сначала пакет обрабатывается межсетевым экраном, затем IPS, потом его проверяет Антивирус и так далее. Естественно такой механизм вносил серьезные задержки в трафик и сильно расходовал ресурсы системы (процессор, память).

2) Слабое “железо”. Как было сказано выше, последовательная обработка пакетов сильно отъедает ресурсы и “железо” тех времен (1995-2008) просто не справлялось с большим трафиком. Со временем ситуация конечно же изменилась. На рынке появилось много достойных вендоров. Ниже представлен знаменитый магический квадрант Гартнера для UTM решений за сентябрь 2018 года:

20

Как видно, среди лидеров находятся Fortinet, Check Point и Sophos. Что же изменилось с момента зарождения UTM и почему в этом рейтинге 2018 год, когда на дворе уже 23-й? Ответы будут даны чуть позже, чтобы не запутаться. А пока продолжим рассмотрение защиты периметра в хронологическом порядке.

4.2 NGFW - Next-generation firewall Довольно долго UTM решения обеспечивали надежную защиту периметра. Пока не эволюционировала сеть Интернет и не стала возможной работа тысячи “приложений” через один единственный порт… Для примера возьмем HTTPS (443 порт). Вы не можете его запретить, т.к. на его основе работают более 90% интернет ресурсов (хотя еще 5 лет назад доля HTTPS была менее 60%). Но через этот порт теперь могут работать не только полезные для работы ресурсы в виде онлайн почты, новостных порталов, торговых площадок и т.д. Через этот же порт теперь доступны:

21

● Развлекательные сервисы (YouTube, Spotify, Internet телевидение) ● Файлообменники (Dropbox, Google Drive, OneDrive, Yandex Disk и т.д.) ● Социальные сети и мессенджеры (Facebook, Instagram, WhatsApp, Telegram и т.д.) ● Утилиты удаленного управления (TeamViewer, AnyDesk и т.д.) ● Игровые сервисы (Google Stadia, GeForce Now, PokerStars и т.д.) ● Tor-узлы (так называемый darknet) ● И многое другое. Есть отличная картинка от Palo Alto Networks, которая ярко демонстрирует проблему классического “портового” межсетевого экрана:

Знаменитая картинка от Palo Alto Networks Здесь может возникнуть логический вопрос: “UTM решения имеют функцию URL Filtering, которая позволяет отфильтровать эти категории сайтов. Разве этого недостаточно?”. Нет, недостаточно. Дело в том, что даже в рамках одного веб-ресурса может работать несколько микро-сервисов и виджетов. Для примера возьмем Facebook. Кроме основного сайта, где мы можем просматривать профили людей или компаний (что весьма важно для некоторых сотрудников), есть еще такие микро-сервисы как: - просмотр видео; - создание публикаций; - чаты с другими пользователями (messaging); - игры на платформе facebook; - загрузка файлов, картинок; - и многое другое.

22

Очевидно, что некоторые подобные сервисы (например игры или загрузка файлов) желательно блокировать. Механизмами URL фильтрации этого не сделать, т.к. все эти виджеты работают на одном единственном сайте. Добавьте к этому популярные десктопные приложения типа Telegram, WhatsApp, которые используют динамически изменяемые URL для подключения к серверам. Вы просто не сможете их “поймать” механизмами классического веб-фильтра. Все это представляет серьезную опасность для корпоративной сети и самих пользователей. Кроме того, что многие ресурсы/сервисы могут отвлекать сотрудников от работы, они еще и могут использоваться злоумышленниками. Скомпрометированный известный ресурс может долгое время распространять вредоносное ПО и никто этого не заметит (банальная подмена скачиваемого файла). Многие хакеры используют для своих вирусных файлов такие популярные хранилища как Google Drive, OneDrive или Dropbox. Большинство пользователей доверяет им и считает безопасным ресурсом. Можно привести огромное кол-во сценариев атаки через 443 и 80 порт, но в целом современный Интернет требует от МЭ следующий функционал: 1) Возможность определять используемое приложение. Не важно, десктопный ли это клиент (Telegram, Skype, Dropbox, TeamViewer) или веб-сервис (Youtube, Lenta.ru, Gmail, Office365). Любой современный сайт можно считать приложением (веб-приложение). Мы должны уметь строить разрешающие или запрещающие политики доступа на основе приложений или категорий приложений. 2) Осуществлять проверку безопасности этого трафика. Как следует из примера выше, нельзя полностью доверять даже самому известному приложению или ресурсу. В любой момент он может оказаться источником вредоносного трафика или вирусных файлов. Поэтому необходимо проверять содержимое даже разрешенного контента. Так и зародился концепт NGFW - Next-Generation Firewall. Впервые понятие NGFW прозвучало “из уст” компании Palo Alto Networks, которая выпускала “межсетевые экраны следующего поколения”. В 2009 году аналитическая компания Gartner опубликовала соответствующий пост, где объяснила принципиальное отличие NGFW (или Enterprise Firewall) от классических межсетевых экранов: “«Next-generation firewalls (NGFWs) are deep-packet inspection firewalls that move beyond port/protocol inspection and blocking to add application-level inspection, intrusion prevention, and bringing intelligence from outside the firewall. An NGFW should not be confused with a stand-alone network intrusion prevention system (IPS), which includes a commodity or non enterprise firewall, or a firewall and IPS in the same appliance that are not closely integrated.»”

23

Т.е. NGFW должен уметь осуществлять проверку трафика до уровня приложений - 7-ой уровень модели OSI. Здесь имеется в виду именно глубокий разбор трафика (DPI - Deep Packet Inspection), который одновременно может проверяться и другими технологиями, такими как IPS или Antivirus. Кроме того, отличительной особенность NGFW стала возможность строить списки доступа на основе учетных записей пользователей, а не на основе ip-адресов, как это делалось ранее. Т.е. не важно с какого устройства пользователь подключался к сети, его политика доступа формировалась именно на основе учетной записи. Стоит отметить, что многие UTM решения также уже имели эту функцию. Ниже представлен рейтинг NGFW решений за октябрь 2018 года.

Как видно, среди лидеров находятся Palo Alto Networks, Fortinet, Check Point и Cisco. Почему рейтинг тоже только за 2018 год? Почему некоторые вендора присутствуют и в рейтинге UTM? Ответы в следующем параграфе.

24

4.3 UTM vs NGFW (Network Firewalls) Самый частый вопрос слушателей, которые впервые знакомятся с концептами UTM и NGFW: “А что лучше?”. Вопрос справедливый, а ответ неоднозначный. Давайте разбираться. Если помните, исторически концепт UTM появился раньше. Но были две основные проблемы: последовательный метод обработки пакетов и слабое “железо”. В результате UTM использовали только в SMB сегменте. Но прогресс не стоит на месте. С тех пор значительно увеличились аппаратные мощности, а обработка пакетов изменилась (надо признать, что далеко не у всех вендоров) и стала позволять практически одновременный анализ сразу в нескольких модулях (МЭ, IPS, AntiVirus и т.д.). Современные UTM решения могут “переваривать” десятки гигабит в режиме глубокого анализа, что дает возможность использовать их в сегменте крупного бизнеса или даже датацентров. Но самое главное - все современные UTM решения научились распознавать приложения (причем довольно давно). С другой стороны, в 2009 году “появились” NGFW решения, которые изначально были спроектированы для быстрой и глубокой инспекции пакетов на больших объемах трафика. При этом ключевой функцией была возможность распознавать приложения и строить политики доступа на основе учетной записи. На момент появления термина “NGFW” был всего один вендор, который на 100% подходил под это определение - Palo Alto Networks. Многие полагают, что это был грамотный маркетинговый трюк (стоит признать, что Palo Alto Networks серьезно подтолкнули рынок и с самого основания находятся среди лидеров). Несмотря на очевидные плюсы NGFW решений, были и минусы отсутствие привычных функций UTM и высокая цена для SMB сегмента. Долгое время NGFW решения могли себе позволить только крупные компании. Учитывая все плюсы и минусы двух классов решений начался процесс, который я называю “диффузией”. Т.е. началось смешивание функций. Большинство вендоров, которые изначально позиционировали свою продукцию как UTM устройства, обзавелись функционалом NGFW. В это же время, NGFW вендора существенно расширили функциональные возможности на примере UTM и появились модели для небольших офисов (тот самый SMB). Ценник немного выровнялся. Начиная где-то с 2015 года стало довольно трудно отличить UTM от NGFW, т.к. делали они примерно одно и то же (хотя подходы к реализации могли существенно отличаться). Именно этим объясняется, что некоторые производители были в рейтингах и UTM, и NGFW (Gartner их называл Enterprise Firewalls). Как результат, в 2019 году Gartner объединил эти два класса в один Network Firewalls. Это довольно логичный шаг на фоне того, что NGFW перестал быть классом решений, а стал лишь одной из функций, которая есть

25

практически у всех вендоров МЭ. Т.е. в большинстве случаев теперь нет деления на UTM или NGFW (по крайней мере среди лидеров рынка), есть Network Firewalls - устройство защиты периметра сети. Однако, многие продолжают называть их NGFW, просто по привычке.

4.4 Типовой дизайн сети с NGFW Прежде чем перейти к обзору основных игроков рынка NGFW давайте рассмотрим типовой дизайн корпоративной сети с применением межсетевого экрана. Ниже представлена примерная структурная схема:

Как видно из картинки, NGFW (выделен красной пунктирной линией), как правило, применяют именно на границе сети (тот самый периметр) и формируют, как минимум, 3 логических зоны (линии синего цвета): 1. Публичная сеть, т.е. Интернет. Зона с наименьшим уровнем доверия. 2. Локальная сеть, куда могут входить сети пользователей и сети локальных серверов/сервисов. Пример таких серверов: почтовый сервер,

26

1с сервер, файловый сервер, контроллер домена и т.д. Является доверенной зоной. 3. DMZ. Сегмент, в котором располагаются публичные сервисы компании, к которым есть доступ из сети Интернет. Пример таких сервисов: сайт компании, FTP сервер, почтовый шлюз (SMTP) и т.д. Является недоверенной зоной, т.к. сегмент публичный, он может быть скомпрометирован и в дальнейшем использоваться для атаки на остальную сеть. В реальной жизни зон конечно же может быть больше, а каждая зона может быть разбита на несколько сегментов, но все же ключевые роли мы перечислили. Именно пограничный NGFW формирует “Периметр сети” и именно здесь происходит фильтрация и проверка трафика максимальным количеством функций безопасности.

4.4.1 Модульный дизайн На схеме можно заметить, что кроме NGFW на границе сети присутствуют пограничные маршрутизаторы. Иногда их называют “бордеры” (от англ. border граница). Это довольно частая практика для крупных компаний, которые могут иметь несколько интернет каналов, использовать BGP (протокол динамической маршрутизации) для отказоустойчивого доступа к своим публичным ресурсам и применять прочие продвинутые функции маршрутизации. Зачем так делать? Т.е. использовать выделенные “бордеры”? Дело в том, что большинство NGFW решений имеют весьма посредственный функционал в плане маршрутизации. И это нормально, NGFW это устройство безопасности, а не маршрутизатор. Многие об этом забывают и пытаются навесть абсолютно все задачи на единственное устройство. Естественно NGFW справится с простейшими задачами роутинга, но для серьезных инсталляций, где отказоустойчивость Интернет соединения является приоритетной задачей, лучше использовать выделенные маршрутизаторы. И это не единственный пример того, как некоторые критически важные задачи выносятся на отдельные решения. Вот частые кейсы: - Каналообразующее оборудование для связи с филиалами. Устройства которые реализуют Site2Site VPN или SD WAN с филиалами компании. - Шлюз удаленного доступа. Подключение удаленных сотрудников к корпоративной сети посредством Remote Access VPN. Задачи проверки трафика, роутинга, связи с филиалами и предоставления удаленного доступа безусловно можно реализовать в рамках одного NGFW решения на периметре. Но подходит это обычно для небольших сетей с простыми задачами и небольшим трафиком. Для высоконагруженных и отказоустойчивых систем чаще применяют именно раздельный дизайн, который может выглядеть следующим образом:

27

Здесь у нас 4 функциональных модуля для 4х разных задач: - NGFW как ядро периметра; - “Бордеры”, как отказоустойчивость интернет подключения; - Site2Site VPN / SD WAN решение для организации связи с филиалами; - RA VPN шлюз для подключения удаленных сотрудников. Давайте еще раз проговорим ключевой вопрос большинства начинающих “безопасников” - можно ли это все сделать на единственном NGFW? Как уже писал выше - иногда можно. Но представленная модульная схема более гибкая и отказоустойчивая. Выход из строя любого модуля не приводит к остановке всей сети. Дополнительный плюс такого дизайна - вы можете использовать специализированные решения, которые могут быть значительно лучше, чем встроенные функции в каком-либо NGFW. Ключевой минус такого дизайна больше финансовых затрат и выше нагрузка на администрирующий персонал. Поэтому при выборе NGFW и планировании сети важно четко понимать, какие функции вам нужны, насколько они критичны и стоит ли их выносить в отдельные функциональные модули.

28

4.4.2 Север-Юг / Запад-Восток Если продолжить тему дизайна, то добавлю, что трафик пользователей в Интернет и трафик из Интернета в DMZ часто называют “Север-Юг”. Как вы уже поняли, для его проверки есть пограничный NGFW.

Но это не единственный вектор трафика в типовых корпоративных сетях. Есть еще трафик между локальных серверов и трафик от пользователей к этим же серверам. Этот вектор называется “Запад-Восток” и такой трафик не доходит до NGFW на периметре сети. Как можно видеть на картинке выше, локальную сегментацию как правило выполняют на коммутаторах ядра, которые лишены каких-либо функций по проверке трафика. Таким образом мы теряем возможность видеть угрозы, которые уже внутри - на Сетевом уровне (Network Layer согласно нашему концепту). Мы подробно обсудим особенности защиты на сетевом уровне в одной из следующих книг. А здесь же просто обозначим, что в крупных компаниях NGFW ставят не только на периметре, но и в ядре, для выполнения локальной сегментации и проверки трафика уже внутри сети. Пример на картинке ниже:

29

Естественно, что для внутренней сегментации требуются более производительные устройства, т.к. трафик “Запад-Восток” обычно значительно больше. Есть повышенные требования к наличию сетевых портов: их количество, скорость (1/10/40/100 Гбит/с) и тип (sfp/sfp+/qsfp и т.д.). Однако, следует отметить, что для локального трафика редко используют абсолютно все типы проверок. Обычно ограничиваются контролем приложений и IPS. Такие функции как потоковый антивирус, или эмуляция проходящих файлов в “песочнице” чаще всего НЕ применяют. Использование NGFW в качестве ядра является хорошей практикой с точки зрения безопасности, однако это не всегда возможно по финансовым причинам.

4.5 Ключевые игроки рынка Network Firewalls Как было сказано выше, начиная с 2019 года Gartner публикует рейтинги Network Firewalls. Ниже представлен свежий рейтинг за ноябрь 2021 года:

30

Как видно, в квадранте лидеров (правый верхний угол) находятся Palo Alto Networks, Fortinet и Check Point. Давайте вкратце рассмотрим их.

4.5.1 Check Point Самая старая компания из трех. Основана в 1993 году в Израиле. Штаб-квартира находится в Тель-Авиве. Общее число сотрудников более 5400 человек. Именно в Check Point придумали технологию Stateful Inspection без которой невозможно представить любой современный МЭ. Отличительные особенности этого вендора: - Занимаются только кибербезопасностью и ничем больше. Т.е. высокая сфокусированность и экспертиза. Регулярно находят новые уязвимости. - Стабильно, уже больше 10 лет, находятся среди лидеров во всех рейтингах (UTM, NGFW, а теперь и Network Firewalls).

31

-

Несмотря на свой возраст, компания живет в непрерывном режиме стартапа. Новые технологии, новые подходы, все это про Check Point. - Признанная лучшая система управления устройствами безопасности. В Check Point одни из первых начали применять концепт централизованного управления шлюзами. - Главное кредо компании: “We prevent, not detect”. И это подтверждается многими независимыми лабораториями, где Check Point показывает высочайший процент блокировки угроз (а не просто детектирования). - Check Point имеет очень большое сообщество экспертов, которые делятся своим опытом. - Обладают уникальной технологией масштабирования - Check Point Maestro. - Для обработки трафика традиционно используют CPU. Однако, буквально в момент написания этой главы, Check Point выпустил большое обновление в модельном ряду - Quantum Lightspeed. Шлюзы поставляются с предустановленной платой с ASIC микросхемами на борту. Устройство производится в партнерстве с NVidia. - Капитализация компании почти $17 млрд (на январь 2022). К слову, это единственный вендор из лидирующей тройки, который до сих пор официально продается в России (по состоянию на лето 2023 года) после ухода большинства других игроков в связи с февральскими событиями. Однако Check Point соблюдает санкционный список и не продает свои решения большинству компаний из банковской, военной, газонефтедобывающей и государственной сферы.

4.5.2 Palo Alto Networks Американская компания, основана в 2005 году Ниром Зуком, бывшим инженером Check Point. Штаб квартира находится в Санта Клара, Калифорния. Штат более 11000 сотрудников. Компания является родоначальником класса NGFW решений. Во многом их подход определения приложений и угроз остается уникальным среди других решений. Отличительные особенности вендора: - Как и Check Point, занимаются только кибербезопасностью. Высокая экспертиза в этой сфере. Регулярно находят новые типы угроз и методы защиты от них. - Первое NGFW решение (согласно определению Gartner). - Имеют патенты на уникальные технологии: App-ID (идентификация приложений), User-ID (идентификация пользователей) и Content-ID (защита от угроз).

32

-

-

Бессменный лидер среди Network Firewalls (ранее NGFW) на протяжении десятка лет. Этот статус подтверждается и другими рейтинговыми агентствами. Одни из первых начали применять ML (Machine Learning) алгоритмы для обнаружения зловредов. Первая и пока единственная компания, которая использует FPGA микросхемы (собственного производства) для обработки трафика. Также есть устройства разработанные совместно с NVidia. Капитализация $51 млрд (на январь 2022).

4.5.3 Fortinet Американская компания, основана в 2000 году. Штаб квартира находится в городе Саннивейл, Калифорния. В штате более 5000 сотрудников. Имеют самый большой портфель решений среди приведенных лидеров и занимаются не только кибербезопасностью. На текущий момент являются самым доступным вендором (среди лидеров) межсетевых экранов для небольших компаний. Отличительные особенности вендора: - Кроме кибербезопасности также имеют решения в сфере IT: коммутаторы, точки доступа, ip-камеры, ip-телефоны и т.д. - Лидируют по количеству проданных межсетевых экранов за год. - Для обработки трафика применяют собственные чипы (FortiSOC), которые объединяют такие технологии как ASIC, Network Processor, Content Processor и CPU общего назначения (позже рассмотрим что это). Это позволяет получить значительную сетевую производительность даже в устройствах самой младшей линейки. - Выпускают наиболее экономичные решения (среди лидеров), которые подходят как для компаний из 5 человек, так и для дата-центров с обработкой трафика в сотни Гигабит/с. - Одни из первых (среди лидеров) реализовали нативную поддержку технологии SD-WAN. - Позволяют организовать наиболее комплексную защиту сети при использовании решений всего одно вендора - Fortinet Security Fabric. - Среди лидеров являются самой бурно растущей компанией. - Капитализация достигла $51 млрд (на январь 2022). Все три компании занимаются не только собственными разработками, но и активно поглощают успешные стартапы в области кибербезопасности. Усилия вендоров нацелены на три основных сегмента: 1) Классические корпоративные сети и дата-центры; 2) Облачная инфраструктура и контейнерные среды; 3) Эндпоинты (рабочие станции, мобильные устройства).

33

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

4.5.4 А что же с Cisco? Странно было бы не упомянуть компанию Cisco в этом рейтинге, учитывая, что они занимали (и все еще занимают) серьезную долю рынка в сфере кибербезопасности. Компания Cisco впервые “вывалилась” из квадранта лидеров в 2021 году. Это довольно знаковое событие, т.к. межсетевые экраны Cisco долгое время были самыми популярными в мире. Сначала PIX, затем знаменитая ASA. Когда решения NGFW начали набирать популярность, Cisco предприняли попытку войти в этот сегмент с собственной разработкой - ASA CX. Однако, было очевидно, что технологически они сильно отстают. Тогда и была поглощена компания Sourcefire (та самая компания, которая выпускала бесплатную IPS систему Snort). Затем последовал долгий процесс интеграции их технологий в экосистему Cisco. В результате появился продукт под названием FirePower, который долгое время был лишь программным модулем (виртуальной машиной) для Cisco ASA серии X. Такой подход оказался утопичным. Появились полноценные устройства Firepower, но они все еще сильно уступали конкурентам, как в техническом плане, так и в плане надежности работы. Слишком много времени уходило на исправление проблем интеграции. Относительно недавно произошел очередной ребрендинг и теперь рабочее название - Cisco Secure Firewall. Так, некогда лидеры рынка, перешли в статус “догоняющих”. Однако, продукт стремительно развивается и возможно в скором времени мы увидим значительные изменения. Лично я в этом сомневаюсь.

4.5.5 Sangfor - новый зарубежный игрок Относительно недавно (лето 2022 года) на Российский рынок ворвался еще один игрок из Китая - Sangfor. Флагманский продукт - NGAF (Next Generation Application Firewall). Компания Sangfor была основана в 2000 году в городе Шеньчжень. Первым продуктом стало IPsec/SSL VPN решение. Затем был прокси сервер (IAG) и другие продукты. NGAF, как отдельный продукт, был запущен аж в 2011 году, что делает его одним из самых молодых решений. В компании работает более 10 тысяч человек и 40% из них - разработчики. Отличительные особенности вендора:

34

-

Хорошая экосистема. Защита периметра (NGAF), защита рабочих станций (EDR), защита на сетевом уровне (Cyber Command), прокси сервер (IAG), собственная платформа виртуализации (HCI) и т.д. - NGAF выделяется дополнительной встроенной функциональностью: WAF, сканер уязвимостей, SOC, интеграция с EDR решениям, SD WAN. - Быстро растущая компания, которая только начинает экспансию на мировой рынок. - Высокий рейтинг в Gartner (правый нижний квадрат) и высокий уровень блокирования атак (block rate) по отчету Cyber Ratings. - Одно из самых бюджетных решений класса NGFW. - Высокая производительность устройств. Есть модели способный обрабатывать до 150 Гбит/с трафика в режиме МЭ и более 50 Гбит/с в режиме NGFW. Стоит понимать, что вендор пришел на российский рынок только после февральских событий 2022 года. Многие зарубежные вендоры покинули рынок и конкуренция снизилась.

4.6 Отечественный рынок Российский рынок не мог не наложить свой отпечаток на сегмент Network Firewalls. На текущий момент есть несколько федеральных законов (ФЗ) и несколько требований регуляторов, которые обязывают некоторые компании использовать только сертифицированные средства защиты. Эти требования распространяются и на межсетевые экраны, и на системы предотвращения вторжений (чаще всего эти решения объединены в одно устройство). Вообще, тема сертификации очень обширная и имеет множество тонкостей, поэтому мы затронем лишь ключевые моменты, которые влияют на рынок в целом. Можно выделить два ключевых типа сертификатов: 1. Сертификация ФСТЭК России. ФСТЭК - федеральная служба по техническому и экспортному контролю. Именно эта служба формирует технические требования к средствам защиты. Чтобы им соответствовать, решение должно пройти процедуру сертификации. При этом можно выделить несколько сфер деятельности, где обязательны сертифицированные (ФСТЭК) средства защиты: - Государственные информационные системы (ГИС); - Автоматизированные системы управления технологическим процессом (АСУ ТП); - Персональные данные (ЗПДн); - Критическая информационная инфраструктура (КИИ); - Государственная тайна (ЗГТ); - Конфиденциальная информация (служебная информация).

35

В этих сферах мы обязаны выполнять требования к сертификации. Иначе грозят большие штрафы и даже уголовная ответственность. На самом деле все гораздо сложнее. Очень многое зависит от того, как компания сможет себя категоризировать, какую модель угроз будет использовать и т.д. Но это уже выходит за рамки нашей книги. 2. Сертификат соответствия ФСБ России. Некоторые организации также вынуждены использовать исключительно сертифицированные средства криптографической защиты (СКЗИ). У межсетевых экранов это VPN функционал, в основе которого должен использоваться отечественный алгоритм шифрования - ГОСТ VPN. Это отдельная сертификация, при которой все устройство (а не только криптобиблиотеки) проверяется на соответствие требованиям. Т.е. сертифицируется программно-аппаратный комплекс (“железо” и “софт”). Это важный момент, т.к. далеко не каждый МЭ с сертификатом ФСТЭК имеет сертификат ФСБ. Какие компании должны использовать устройства с ФСБ сертификатом? Как и в случае с ФСТЭК, все определяется при классификации АС (автоматизированной системы). В зависимости от типа АС определяются требования к средствам защиты. К примеру, если компания работает с персональными данными, то они могут передаваться во вне только по каналам, которые шифруются ГОСТ-алгоритмом. Другой пример - если какая-то компания подключается к ГИС (государственные информационные системы), то эти каналы также можно шифровать только сертифицированными средствами. Чем же эти два сертификата могли навредить отечественному рынку Network Firewalls? Есть хорошая поговорка: “Благими намерениями вымощена дорога в ад”. Точно также вышло и с отечественной сертификацией средств защиты. Если вдуматься, сама цель хорошая - обезопасить критическую для страны инфраструктуру от возможного несанкционированного доступа с помощью возможных программных или аппаратных закладок в средствах защиты (например МЭ). Но реализация “немного” подвела. Особенности сертификации привели к тому, что те самые критические инфраструктуры вынуждены использовать далеко не самые лучшие на рынке средства защиты (а иногда и морально устаревшие). Так уж сложилось, что технологическими лидерами в сфере ИБ являются именно зарубежные компании. И как правило, именно они способны предоставить эффективную и, самое главное, актуальную защиту. Но большинство вендоров оказались либо вообще неспособны получить сертификат ФСТЭК на свои средства защиты (опять же, из-за особенностей реализации процесса сертификации), либо получить его, но на старые версии программного обеспечения (т.к. процесс сертификации занимает слишком

36

много времени, а сертификат выдается на строго определенную версию). Для примера: - Компания Check Point имеет сертификат ФСТЭК, но только на определенную версию операционной системы - Gaia R77.30. В то время, как актуальная версия на текущий момент уже Gaia R81.10. Разрыв в версиях более чем 6 лет! - Компания Fortinet также имеет сертификат ФСТЭК, но только на версию 5.4. Актуальная версия - 7.0. Здесь разрыв в версиях более 3-х лет. - Компания Palo Alto Networks вообще отказалась от процедуры сертификации, как и многие другие зарубежные вендоры. Вообще, тема с сертификацией значительно сложнее. Есть еще история с типами МЭ (А, Б, В, Г, Д) и классами защиты (1-6). Однако, это уже выходит за границы нашей книги. При этом стоит отметить, что на текущий момент, получить сертификат соответствия ФСБ практически невозможно для зарубежного вендора. В результате, на российском рынке появился гигантский сегмент сертифицированных МЭ и IPS, где практически отсутствовала какая-либо конкуренция. Рынок поделили несколько отечественных вендоров. А отсутствие конкуренции всегда неизбежно сказывается на качестве. Зачем развивать продукт, если его и так будут покупать, потому что есть закон!? К счастью, последние несколько лет эта тенденция значительно меняется. Российские вендора также включились в технологическую гонку. Объективно, пока только между собой, т.к. до зарубежных лидеров все еще очень далеко. Вот список наиболее заметных отечественных игроков в сегменте МЭ: 1) Компания Код Безопасности со своим решением АПКШ Континент. Имеют сертификат ФСТЭК и ФСБ. 2) Компания Инфотекс со своим решением ViPNet Coordinator, который имеет оба сертификата. Также существует решение класса NGFW xFirewall (только ФСТЭК). 3) Компания UserGate с одноименным решением. На данный момент имеют только ФСТЭК сертификат (ФСБ в планах). Также на рынке присутствуют такие продукты как S-Terra, Ideco, Dionis, Рубикон, Интернет Контроль Сервер, Traffic Inspector, Solar NGFW и т.д. И их количество только растет. Связано это в первую очередь все с теми же февральскими событиями. Рынок освободился от большого числа зарубежных игроков. Образовался некий технологический вакуум и как результат - резко возросла конкуренция среди отечественных игроков. Мы не сможем рассмотреть все решения в рамках этой книги, но кратко опишем уже упомянутых наиболее заметных игроков.

37

4.6.1 UserGate Российская компания в сфере ИБ, которая была основана в 2006 году (с 2009 под брендом UserGate), в Новосибирске. На текущий момент имеют офисы в Москве, Санкт-Петербурге и Хабаровске. Первым значимым продуктом компании был классический Proxy-сервер. Разработка собственного NGFW началась с 2011 года и было представлено в 2016. В основе NGFW лежит собственная операционная система UGOS. В 2022 году был сделан релиз версии 7.0, которая является наиболее значимой с точки зрения переработки и новых функций. Компания UserGate активно развивает собственную экосистему, которая носит название SUMMA. Входящие в нее компоненты: - UserGate NGFW - ядро экосистемы. Межсетевой экран следующего поколения. Компания активно работает над локализацией производства и использованием электронных компонентов собственного производства (зависимость от импортных компонентов все еще очень высока). - UserGate Log Analyzer - централизованный сбор и обработка логов со всех устройств UserGate. В одном из последних анонсов было заявлено, что последняя версия (7+) также поддерживает сбор и корреляцию событий от сторонних систем, что переводит данный инструмент в класс SIEM систем. - UserGate Management Server - централизованная система управления шлюзами UserGate. - UserGate Client - агентское решение класса NAC, которое предназначено для проверки безопасности рабочих станций при удаленном подключении. Например можно запретить VPN подключение для компьютеров без антивируса. На текущий момент (лето 2023), решение все еще в разработке. По неофициальным данным, оборот компании в 2022 году составил более 1 млрд рублей. Имеется ФСТЭК сертификат (ФСБ сертификат на шифрование каналов пока отсутствует). Если дать личную оценку компании UserGate, то можно сказать, что это один из наиболее заметных и активных игроков на российском рынке сетевой безопасности. Отличная категоризация url ресурсов и приложений. Есть проблемы со стабильностью и качеством технической поддержки. На текущий момент это самый дорогой NGFW из отечественных решений (на уровне зарубежных решений). Нет высокопроизводительных платформ (более 10 Гбит/с в режиме DPI). Буквально на днях (май 2023) было анонсировано устройство UG FG, аппаратная платформа способная “переварить” более 150 Гбит/с трафика, но пока только в режиме МЭ, т.е. без DPI (глубокая инспекция пакетов).

38

4.6.2 АПКШ Континент (Код Безопасности) Код Безопасности - российская системообразующая ИТ-компания. Ключевая деятельность - разработка ИБ средств. Изначально компания была лишь подразделением системного интегратора Информзащита. В 2008 году было принято решение о выделении в отдельную компанию. Центральный офис находится в Москве. По оценке на 2022 год Код Безопасности занимал 7% всего российского ИБ рынка. Ключевые решения Кода Безопасности: - АПКШ Континент - российское NGFW решение. Одно из ключевых преимуществ решения - наличие и ФСТЭК и ФСБ сертификатов. Это позволяет закрыть сразу два требования: защита периметра и построение шифрованных туннелей с использованием ГОСТ алгоритмов. Также примечательно, что вендор выбрал иерархическую модель, т.е. необходимость выделенного сервера управления (ЦУС). Для удаленных VPN пользователей существует ZTN клиент, который позволяет перед подключением проверять рабочии станции на соответсвтие политикам безопаности. - Континент TLS - решение предназначенное исключительно для организации удаленного доступа пользователей (RA VPN), без функций NGFW. - Континент WAF - защита веб-приложений. Продукт создан на основе стороннего решения SolidWall WAF. - SecretNet - защита данных и инфраструктуры серверов и рабочих станций (защита от вирусов, сетевых атак, несанкционированного доступа и т.д.). - Соболь - программно-аппаратный комплекс доверенной загрузки операционной системы. Выручка на 2022 год - 7,4 млрд рублей. В 2022 году Русатом приобрел 50% акций. Вендор также активно работает над локализацией сборки устройств (доля импортных компонент все еще высока). Личное мнение - заложена более правильная и потенциально выигрышная иерархическая архитектура (сервер управления - шлюз). Компания явно старается перенять практики Check Point (что и не скрывается). Есть проблемы со стабильностью, наличием нужных функций, процедурой обновления и качеством технической поддержки. IPS с хорошим уровнем блокировок. Более низкая цена в сравнении с UserGate. Нет высокопроизводительных платформ (более 10 Гбит/с в режиме DPI).

4.6.3 xFirewall (ИнфоТеКС) ИнфоТеКС - одна из старейших российских ИБ компаний, основанная в 1991 году. Входит в Топ-5 в России в сфере ИБ. Центральный офис находится в

39

Москве и еще более 9 представительств в других крупных городах страны. Штат - более 1200 человек. Флагманским решением являются шлюзы VipNet Coordinator предназначенные для шифрования каналов связи и межсетевого экранирования. Обладают сертификатами ФСТЭК и ФСБ. Другие продукты ИнфоТеКС: - Защита рабочих станций; - Средства шифрования данных; - Средства мониторинга и централизованного управления; - Программно-аппаратные комплексы обнаружения вторжений (VipNet IDS); - И т.д. Одним из новейших продуктов компании является решение класса NGFW VipNet xFirewall 5. На текущий момент (лето 2023) обладает только сертификатом ФСТЭК. По субъективному мнению, xFirewall занимает наименьшую долю рынка в сравнении с описанными выше вендорами, пока уступая как в техническом, так и в маркетинговом плане.

4.6.4 PT NGFW (Positive Technologies) Буквально за пару дней до написания этого параграфа (19 мая 2023) был презентован прототип еще одного МЭ - PT NGFW. Это межсетевой экран следующего поколения от другой хорошо известной российской ИБ компании Positive Technologies. Компания была основана в 2002 году. Штаб-квартира находится в Москве и еще 6 представительств в других городах. Число сотрудников более 1500. Оборот компании в 2022 году составил почти 14 млрд рублей (на 95% больше чем в 2021). Ключевые продукты компании: - PT SIEM - система сбора, анализа и корреляции событий. Одно из лидирующих решений на рынке. - XSpider - сканер уязвимостей и первый коммерческий продукт PT. - MP8 - система управления уязвимостями. - MP VM - система управления уязвимостями, которая должна сменить MP8. - PT NAD - система анализа трафика. Решение класса NTA/NDR. - PT Sandbox - “песочница”, позволяет бороться с атаками нулевого дня. - PT WAF - защита веб-приложений. - И т.д. Анонсированный NGFW пока лишь прототип с двумя ключевыми функциями - определение пользователей и приложений. В разработке PT NGFW упор делается на быстродействие. Прототип способен выполнить DPI 40 Гбит/с трафика, из них 10 Гбит/с в режиме SSL инспекции (и все это на

40

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

4.7 CPU, ASIC, FPGA Список лидеров довольно примечательный (Check Point, Palo Alto, Fortinet), т.к. эти три компании представляют три абсолютно разных подхода к обработке трафика с технической точки зрения - CPU, FPGA и ASIC. У большинства сразу возникает вопрос: “А что лучше?”. Ответ не так очевиден. Давайте рассмотрим их плюсы и минусы. CPU Central Processing Unit - Центральное обрабатывающие устройство или просто “процессор”. CPU для обработки сетевого трафика имеет свои плюсы и минусы: + Максимальная гибкость. CPU это универсальное устройство. На его основе работает вся вычислительная техника - компьютеры, смартфоны, смарт-телевизоры, смарт-часы и т.д. Самое главное достоинство с точки зрения обработки трафика - в любой момент можно изменить программу обработки и получить совершенно новые функции, как с точки зрения безопасности (новые типы проверки), так и с точки зрения маршрутизации (новые протоколы маршрутизации или инкапсуляции). Если вдруг обнаружится какой-то “баг” или уязвимость, то это можно с легкостью исправить переписав код. + Максимальная функциональность. Выполняемые функции зависят исключительно от вашей фантазии. Написание программ под CPU значительно проще, т.к. можно использовать различные языки программирования (От “C” до “python”). ~ Средняя цена. CPU это НЕ дешевое устройство, но стоимость значительно ниже, чем у FPGA. Практически все вендора используют сторонние разработки (Intel, AMD, Broadcom, Marvell, Nvidia, Qualcomm и т.д.), т.е. не разрабатывают сами. В каком-то смысле это разгружает компании, но с другой стороны, ставит в зависимость от чужих технологий. - Низкая производительность. CPU “медленнее”, чем ASIC и FPGA. Современные процессоры это высокотехнологичные устройства. Могут работать на высоких частотах, иметь множество ядер, множество специализированных сопроцессоров и т.д. Учитывая удобство работы с CPU, было бы здорово использовать только их. Но объемы

41

передаваемого трафика тоже быстро растут. Иногда нужно обрабатывать сотни гигабит или даже десятки терабит. Делать это на CPU дорого, а иногда и невозможно (или просто нецелесообразно). ASIC Application-Specific Integrated Circuit) - Интегральная схема специального назначения. Плюсы и минусы ASIC-ов для обработки сетевого трафика: - Нулевая гибкость. В отличии от CPU, перепрограммировать ASIC невозможно. После того как их “запекли” на заводе, их уже ни изменить, ни дополнить, ни исправить (даже в случае обнаружения серьезного “бага” или уязвимости). - Низкая функциональность. ASIC это узкоспециализированная микросхема функционал которой определяется еще при проектировании. Как было написано выше, набор функций не изменить. Более того, в силу архитектуры, некоторые функции в принципе невозможно реализовать на ASIC. + Низкая цена. ASIC микросхемы гораздо дешевле в производстве, хотя и требуют бОльшей ответственности при подготовке прототипа. + Максимальная производительность. ASIC микросхемы самые “быстрые” в сравнении с CPU и FPGA. ASIC-и идеально подходят для обработки большого объема трафика, там где не требуется глубокое инспектирование. FPGA Field-Programmable Gate Array - Программируемая логическая интегральная схема (ПЛИС). FPGA также имеют свои плюсы и минусы: + Средняя гибкость. Являются чем-то средним, между CPU и ASIC. FPGA можно перепрограммировать. Это, в свою очередь, немного упрощает подготовку к производству, т.к. в случае обнаружение проблем, их можно будет исправить. Благодаря этому, продукты основанные на FPGA, выходят на рынок быстрее, чем на ASIC. ~ Средняя функциональность. FPGA функциональнее, чем ASIC. И эти функции можно менять. Однако FPGA серьезно уступает в этом плане CPU. Для программирования используются специализированные языки (Verilog, VHDL). - Высокая цена. Производство FPGA значительно дороже чем CPU или ASIC. Вендоров, производящих FPGA значительно меньше. + Хорошая производительность. Производительность чуть ниже, чем у AISC, но ЗНАЧИТЕЛЬНО выше чем у CPU. В целом, FPGA чаще используют как макетную микросхему, на которой можно протестировать логику, а на ее основе запустить производство ASIC. Но есть и

42

исключения, когда FPGA используют в масштабном производстве (Palo Alto Networks). Вот отличная картинка, которая демонстрирует плюсы и минусы этих трех решений:

Источник - https://nag.ru/material/37503 Как видно, идеального варианта не существует. Можно было бы рассказать еще про Network Processors (сетевые процессоры, которые объединяют в себе и CPU и ASIC) или про новый тип программируемых ASIC. Но в этом случае мы бы сильно ушли от изначальной темы. А что же (и как) используют наши лидеры? Как написано выше, у них разные подходы: - Check Point, исторически, использует CPU общего назначения, x86 архитектуры. Сейчас это уже многоядерные CPU, а некоторые модели шлюзов и вовсе содержат в себе два физических CPU. На мой субъективный взгляд, Check Point лучше всех научились работать с CPU и выжимать из него максимум производительности. Они обладают множеством уникальных технологий, таких как CoreXL (работа с многоядерными CPU) или SecureXL (механизм ускорения обработки трафика с помощью функции hardware offload). Такой подход позволяет им очень быстро обновлять софт, внедрять новые функции или исправлять критические уязвимости, “баги”. Но, к сожалению, CPU все же сильно ограничивает производительность межсетевых экранов. Это подтолкнуло Check Point искать другие методы. Они одни из первых стали применять многосерверные шасси (набор серверов объединенных в одну сетевую фабрику с балансировкой нагрузки между ними), а позже

43

-

-

и вовсе уникальную для рынка технологию - Check Point Maestro. В основе Maestro лежит оркестратор (физический коммутатор-балансировщик), к которому подключаются обычные шлюзы. Это позволяет добиться колоссальной пропускной способности в несколько Терабит/с при всех включенных механизмах безопасности (Antivirus, IPS, Anti-Bot и т.д.). Плюс, как было написано ранее, Check Point также дополнил свою линейку моделями с модулями NVidia (ASIC микросхемы). Fortinet идет по пути ASIC. В основе шлюзов безопасности лежат их собственные высокопроизводительные чипы (FortiSOC), которые объединяют в себе сразу несколько технологий: Network Processor (на основе ASIC), Content Processor (также на ASIC) и процессор общего назначения (CPU). Такой концепт позволил создать дешевый и максимально быстрый “чип”, который устанавливается как в младшие, так и в старшие модели шлюзов. Разная комбинация чипов и их количество определяет итоговую производительность устройства. Стоит отметить, что Fortinet тоже использует CPU, но бОльшую часть обработки трафика старается перенести на быстрые ASIC-и, которые обновляются практически каждый год и обзаводятся новым функционалом. Как было написано выше, Fortinet производит самые доступные устройства среди лидеров. Бытует множество споров по поводу реальной производительности шлюзов Fortinet, т.к. не всегда и далеко не весь трафик можно обработать с помощью быстродействующих ASIC микросхем. Часть аргументов справедливы, часть - надуманы. Но есть важный факт - количество клиентов Fortinet непрерывно растет, причем не только в сегменте малого бизнеса, но и в крупном “энтерпрайз” сегменте. Т.е. клиенты “голосуют деньгами” за решения Fortinet. У Palo Alto Networks свой подход - использование FPGA. Они попытались вобрать все самое лучшее от CPU и ASIC. Этот подход позволил им добиться огромной производительности при максимально глубокой инспекции трафика. Особенности FPGA также позволяют им быстро внедрять новые функции и оперативнее выводить решения на рынок. Во многом именно это позволило им стремительно захватить американский рынок и держаться в ТОП-е уже более 10 лет. Но, как вы помните, FPGA это дорогая “штука”, поэтому шлюзы Palo Alto одни из самых дорогих в представленном рейтинге. Здесь необходимо добавить, что Palo Alto, как и Fortinet, тоже используют CPU общего назначения, но стараются бОльшую часть трафика обрабатывать именно на FPGA по понятным причинам.

44

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

4.8 Ключевые проблемы Network Firewalls И так, мы узнали, что такое NGFW, кто является лидером и какие подходы по обработке трафика существуют. Но в чем же ключевые проблемы этого класса средств защиты? Проблем на самом деле много, но я бы выделил две самые главные: 1. Производительность Это самая ожесточенная тема спора среди всех вендоров Network Firewalls. Производители регулярно обновляют свои линейки шлюзов и меряются цифрами в даташитах (краткое техническое описание). Дело в том, что обработка трафика может быть разной. Можно просто выполнять маршрутизацию с базовым межсетевым экранированием, а можно осуществлять DPI, т.е. разбирать пакеты до уровня приложений и проверять их такими движками как Antivirus, IPS или даже Sandbox. И даже тут есть разница. Например, можно проверять только хэш скачиваемого файла или только первые его байты. А можно осуществлять полную проверку с предварительной буферизацией всего файла. Это совершенно разная нагрузка. Практически все вендоры публикуют три цифры производительности по каждой модели: - Производительность в режиме Firewall. Т.е. сколько устройство может “переварить” трафика в режиме обычного МЭ. - Производительность в режиме NGFW. Идет глубокое инспектирование трафика (DPI) до уровня приложений с последующей проверкой модулем IPS (сигнатурный или поведенческий анализ). Здесь цифры производительности уже значительно ниже. - Производительность в режиме Threat Prevention. Вариант, когда используются все функции безопасности (IPS, Antivirus, Anti-Bot, Sandbox и т.д.). При таком варианте выдается самая низкая цифра по производительности. Для пример рассмотрим три похожих модели от трех вендоров и какие цифры они заявляют. Vendor/Model

Firewall

NGFW

Threat Prevention

Check Point GW 7000

48 Gbps

22 Gbps

9.5 Gbps

45

Fortigate 1100E

80 Gbps

9.8 Gbps

7.1 Gbps

Palo Alto 5220

-

17 Gbps

9.7 Gbps

По этой табличке очень хорошо видно, на сколько ускоряет обработку трафика ASIC чипы. Fortigate в режиме обычного МЭ выдает целых 80 Гбит/с. А вот там, где требуется проверка трафика большим набором функций, производительность уже существенно снижается, т.к. эта нагрузка не может пройти мимо CPU. При планировании NGFW как средства защиты периметра безусловно нужно ориентироваться на показатель Threat Prevention, т.к. желательно проверять трафик максимальным количеством проверок безопасности. Однако, важно понимать, что приведенные цифры получены в лабораторных условиях и практически всегда не соответствуют реальным показателям на реальном трафике. При подборе решения практически всегда стоит ориентироваться на количество пользователей, которые будут выходить в интернет через NGFW. Это обусловлено спецификой проверки трафика. Чем больше сессий, тем больше проверок должен выполнить NGFW и тем больше на него нагрузка. Для понимания, 1 Гигабит трафика можно “прокачать” в рамках десятка сессий, а можно в рамках двух миллионов. Каждую сессию нужно проверить, стерминировать и т.д. Отсюда и вытекает привязка к пользователям при расчете. Чем больше пользователей, тем больше сессий. Сюда же можно добавить проблему инспекции HTTPS трафика, при которой сначала необходимо раскрывать сессию для последующего анализа. Это также является серьезной нагрузкой для NGFW (как работает HTTPS инспекция и для чего она вообще нужна мы обсудим чуть позже). В итоге, реальные цифры по производительности оказываются СУЩЕСТВЕННО ниже абсолютно у всех вендоров. Процесс подбора оборудования (“сайзинг”) является важной задачей и должен выполняться грамотными специалистами с большим опытом. Как правило это либо представители вендора, либо инженеры интеграторов. В идеале, любой сайзинг должен сопровождаться пилотным проектом на реальном трафике заказчика. 2. Процент блокирования угроз Еще одна вечная тема - кто лучше всех блокирует угрозы? Подобные исследования ведутся уже несколько лет, регулярно проводятся тестирования независимыми компаниями и публикуются различные отчеты. Компания NSS Labs была одной из самых известных исследователей в этой области со своей собственной методикой тестирования. В ходе теста запускались различные варианты проникновения через МЭ с использованием методов обхода средств защиты (evasion). Рейтинг имел название Breach Prevention System. 46

К сожалению, NSS Labs не пережила пандемию и объявила о своем закрытии в 2020 году. Ниже представлен один из последних рейтингов по качеству блокирования угроз:

Как видно из графика, лидером является компания Check Point. При этом Fortinet обладает наименьшей стоимостью в расчете на 1 мбит защищаемого трафика. Это очень конкурентная среда и практически у всех участников рейтинга есть свои, так называемые, “киллер фичи”, которые доступны только у них. Еще один более свежий рейтинг от CyberRatings (компания создана выходцами NSS Labs) за 2022 год:

47

Здесь уже среди лидеров находятся Check Point, Sangfor, Palo Alto Networks, Forcepoint, Fortinet. По опыту могу сказать, что итоговый уровень защищенности компании практически всегда зависит от персонала, который эксплуатирует и конфигурирует NGFW. Как говорит мой знакомый: “Хорошо настроенный Mikrotik всегда лучше, чем плохо настроенный NGFW”. © Михаил Зимин. 3. Техническая поддержка Каким бы хорошим не было решение, всё и всегда будет упираться в качество технической поддержки и документации. Это неотъемлемая часть корпоративных решений. Стоимость ежегодной технической поддержки обычно колеблется в районе 10% от стоимости первоначальной закупки. И это не учитывая продление различных функций NGFW, которые требуют регулярного обновления (в среднем стоимость ежегодного владения продуктом выливается в 40% от суммы закупки). Это существенные цифры. Как человек с большим опытом могу заявить со стопроцентной уверенностью - ни одним NGFW решением невозможно пользоваться без адекватной технической поддержки или хотя бы без грамотного партнера интегратора.

48

В большинстве случаев плохая техническая поддержка это следствие бурного роста количества клиентов. При этом плохая техническая поддержка становится главной причиной бурного оттока клиентов. Иногда получается замкнутый круг. Мне посчастливилось (или нет) поработать практически со всеми NGFW, которые были рассмотрены выше. И могу субъективно заявить, что техническая поддержка Check Point одна из лучших в мире. Отдельным плюсом является их невероятная база знаний, где можно самостоятельно найти решение более 90% всех возникающих проблем. Fortinet имеет худшую поддержку из тройки лидеров. Опять же, мнение субъективное и нуждается в количественной оценке. Что касается отечественных вендоров, то абсолютно у всех пока очень сильно “хромает” и техническая поддержка, и документация продуктов. Особенно это заметно на текущий момент, когда спрос резко возрос. Будем надеяться, что это временное явление и компании смогут справиться с возросшей нагрузкой. 4. Интеграция с другими продуктами Если помните, смысл нашего фреймворка - комплексный подход. Многоуровневая защита на разных этапах атаки. NGFW здесь лишь малая часть в общей картине. Для максимальной эффективности желательно иметь возможность интеграции этих продуктов друг с другом. Это в первую очередь касается NGFW, т.к. это ядро многоуровневой защиты. Качественный NGFW должен без проблем уметь интегрироваться хотя бы с такими решениями как: - Sandbox (“Песочницы”). Классическая задача - дополнительная проверка проходящих файлов в сторонней или собственной песочнице. Интеграция со сторонним решением обычно реализуется через протокол ICAP. - DLP (Защита от утечек данных). Аналогичная интеграция через ICAP, для проверки утечек на сетевом уровне. - SIEM (Сбор и анализ событий безопасности). Наиболее частый протокол для отправки логов - syslog. Большинство решений это умеет, но везде есть свои нюансы. Например текущая версия Sangfor NGAF не поддерживает ICAP. А некоторые отечественные решения не умеют работать по ICAP в режиме предотвращения. Check Point, Fortinet, Palo Alto имеют собственные песочницы, которые интегрируются нативно и работают значительно быстрее и стабильнее, чем через ICAP. UserGate, Континент и xFirewall не имеют собственных песочниц, по крайней мере пока (лето 2023), и требуют сторонних решений. Планируемый PT NGFW может стать первым отечественным NGFW с собственной песочницей (PT Sandbox уже есть). Все эти факторы нужно обязательно учитывать при выборе. 49

Дополнительным плюсом является возможность интеграции NGFW с такими классами решений как EDR, Сканеры уязвимостей, NTA/NDR и т.д. Но это уже тема следующей книги.

4.9 Бесплатные решения В начале книги я обещал, что кроме коммерческих решений буду приводить пример бесплатных продуктов. К сожалению, в области NGFW практически нет каких-либо open source проектов. И это неспроста. Ключевая задача NGFW уметь определять приложения. Это возможно только с помощью специальных сигнатур, которые должен кто-то подготовить предварительно изучив паттерны трафика того или иного приложения. Нет другого способа. Как вы понимаете, это гигантские трудозатраты, особенно если учесть, что приложения имеют свойство менять свой паттерн трафика, а количество приложение растет ежедневно. Поэтому полноценный функционал NGFW встречается только в коммерческих продуктах. Он требует непрерывной поддержки и обновлений. А вот в сегменте UTM есть действительно неплохие варианты, которые собраны из различных open source проектов. Наиболее яркие представители: 1. pfSense 2. OPNsense Оба проекта включают в себя такие модули как Firewall, VPN, Web filtering, Antivirus, IPS и т.д. Естественно эти решения уступают коммерческим по качеству защиты. Однако, “это лучше, чем ничего”.

4.10 Резюме по Network Firewalls ● Ключевая задача любого МЭ периметра - оградить сеть от внешнего мира, тем самым максимально уменьшив площадь атаки. Крепость легче защищать когда она окружена стеной и имеет всего одни ворота (МЭ). ● Недостаточно ограничивать доступ по ip-адресам и tcp-портам, необходимо проверять содержимое даже разрешенного трафика. ● UTM решения объединяют в себе несколько средств защиты. Типовой состав: МЭ, IPS, Antivirus, Web Filtering, Anti-Spam, VPN. ● Через один единственный порт могут работать тысячи приложений. От современного МЭ требуется возможность ограничения доступа на уровне приложений - NGFW. ● В основе NGFW лежит глубокое инспектирование трафика (DPI). ● В современном мире NGFW уже является лишь функцией, а не отдельным классом решений. ● В типовом дизайне сети NGFW используется на периметре. При большой нагрузке могут выделяться такие модули как Пограничные

50

●

● ● ● ● ●

●

●

маршрутизаторы, Site-to-Site/SD-WAN, RA VPN шлюз. Т.е. модульный дизайн. NGFW может применяться не только для обработки трафика Север-Юг, но и для внутреннего - Запад-Восток, где обычно требуется меньше функций безопасности, но выше производительность. Ключевые игроки рынка Network Firewalls: Palo Alto Networks, Check Point, Fortinet. Ключевые отечественные вендора: ViPNet, Код Безопасности, UserGate. Новый игрок на рынке NGFW - Sangfor. Есть три главных подхода к обработке трафика: CPU, FPGA, ASIC. Все имеют свои достоинства и недостатки. Реальная производительность устройств не соответствует цифрам в даташитах. Для подбора устройства требуется грамотный партнер и пилотный проект на реальном трафике. Многие российские компании вынуждены использовать МЭ с сертификатами ФСТЭК и ФСБ. Далеко не все вендора имеют эти сертификаты. Бесплатные решения класса UTM: pfSense, OPNSense.

51

5. Email Security Как было обозначено ранее, 3 главных вектора атаки на пользователей: Web, Email и Mobile Devices. Мы с вами обсудили пока только Web, обезопасить который можно с помощью решений класса Network Firewalls (большинство по прежнему называют NGFW, как устоявшееся понятие). Однако, как вы понимаете, этого совершенно недостаточно… Статистически, вектор атаки через электронную почту (далее email) гораздо опаснее, чем Web. Больше половины всех кибератак начинаются именно со зловредных писем. Это может быть вирусное вложение, ссылка на зараженный ресурс, фишинговое письмо и т.д. Ниже представлена динамика увеличения угроз через Web и Email:

Подобная тенденция сохраняется уже более 15 лет и с каждым годом опасность электронной почты только возрастает. Большинство пользователей уже понимают, что опасно заходить на некоторые сайты и скачивать все подряд. Но к email у всех особое отношение. Для большинства это по умолчанию доверенный, персональный ресурс, особенно если речь идет о корпоративной почте. Здесь у кого-то может возникнуть вопрос: “Но мы же закрыли периметр сети, проверяем весь трафик, который проходит через ворота (NGFW) нашей крепости. Что еще нужно?”. Картинка ниже хорошо иллюстрирует причину недостаточности NGFW:

52

Можно сказать, что email “проходит” мимо нашего NGFW, как почтовые голуби пролетают над воротами крепости. Это конечно же образное сравнение. Чисто технически, почтовый трафик может (и должен) проходить через NGFW на периметре сети. Вот только NGFW не всегда умеет такой трафик проверять. И связано это в первую очередь с особенностью протоколов электронной почты. Чтобы разобраться, давайте познакомимся с небольшой исторической справкой.

5.1 Проблемы шифрования На заре появления сети Интернет все было довольно наивно. Мало кого заботила информационная безопасность. Первые же киберпреступления изменили ход событий: 1. Сети стали изолироваться. Локальные сети компаний стали отделяться от Интернета с помощью МЭ, а технология NAT позволяла выходить в Интернет без публичных ip-адресов на каждом хосте. 2. Трафик в сети интернет (по сути между разными локальными сетями) стали шифровать. Сейчас нас интересует второй пункт. Попробуем кратко рассмотреть эволюцию этого процесса. Сразу оговорюсь, что всё описанное ниже сильно упрощено, т.к. мне не хотелось загружать вас глубокими техническими выкладками. Но думаю этого должно хватить для общего понимания.

53

-

Изначально для Web трафика использовался всем знакомый HTTP протокол, который работает на 80 tcp порту. Такой трафик не шифруется и все передаваемые данные могут быть просмотрены (например логин/пароль) и что еще хуже - изменены (подмена банковских транзакций и прочее). Для безопасности был придуман HTTPS, который работает уже на 443 tcp порту. По сути, это все тот же HTTP протокол (для передачи данных он и используется), но “сверху” добавлено шифрование и проверка целостности с помощью протокола SSL. Чтобы трафик “не подсмотрели” и “не изменили”. На текущий момент более 90% всего веб трафика это HTTPS, а для шифрования используется протокол TLS (замена устаревшему SSL)

-

Аналогичная ситуация была и с Email трафиком. Использовался SMTP протокол (25 порт tcp), где данные передавались в открытом виде. Да, любой мог читать чужие сообщения и вложения с помощью обычного анализатора трафика типа Wireshark. Как и в случае с HTTP, решили придумать шифрованный протокол - SMTPS (465 порт tcp). Это все тот же SMTP, просто трафик шифровался с помощью SSL. Казалось бы, решение найдено, но специалисты из IANA (Администрация адресного пространства Интернет) быстро поняли, что они не могут выделять новый порт под эволюцию каждого сервиса - их слишком много и портов на всех не хватит. Альтернативное решение было найдено довольно быстро - STARTTLS. Это расширение для стандартного SMTP. Теперь общение между почтовыми серверами выглядит примерно так:

54

Т.е. сервер отправитель обращается по стандартному 25 порту к серверу получателю, а дальше они с помощью STARTTLS договариваются о параметрах шифрования. В конце отправляется ваше письмо уже в зашифрованном виде. С первого взгляда все выглядит очень круто. Веб-трафик шифруется, почтовый тоже. Что еще надо? Но есть проблема. Этот шифрованный трафик (web и email) может использовать и злоумышленник, чтобы доставить вредоносный контент до пользователя. И вы, как “безопасник”, уже не сможете его просто так проверить с помощью IPS, потокового антивируса и т.д. По умолчанию такой трафик проходит насквозь через любой NGFW. Естественно ИБ производители не могли это так просто оставить. Если говорить об NGFW, то изначально его ключевая задача это проверка именно веб-трафика. И для решения проблемы шифрованного трафика была придумана HTTPS инспекция. Часто ее называют еще ssl инспекцией, как устоявшийся термин, хотя уже везде применяется новый протокол - tls. Смысл инспекции очень прост - NGFW вклинивается в сессию между пользователем и сервером. По сути это типовая атака man in the middle, но легитимная, в рамках корпоративной сети. Это происходит незаметно для пользователя если администратор установил нужные сертификаты. Схема работы HTTPS инспекции представлена ниже:

NGFW перехватывает запрос пользователя и строит с ним защищенное соединение. Затем уже от себя строит защищенное соединение с сервером, к которому изначально обращался пользователь. Таким образом NGFW оказывается посередине, где может видеть трафик в незашифрованном виде, а 55

значит и проверять его всеми модулями безопасности. На текущий момент, использование HTTPS инспекции является обязательным для всех NGFW, т.к. доля шифрованного трафика составляет уже более 90%. Как вы понимаете, с почтовым трафиком аналогичная ситуация. Чтобы проверять почту, нужно находиться между сервером отправителем и сервером получателем, чтобы “разорвать” шифрованный почтовый трафик. По сути надо быть чем то вроде почтового сервера, который может получать и отправлять сообщения в зашифрованном виде. Есть специальное понятие для таких устройств - MTA (Mail Transfer Agent). Так вот большинство NGFW устройств такой функции НЕ имеют (хотя и есть исключения). При этом, если вы начнете смотреть описания этих NGFW, то практически у каждого заявлена функция защиты почты - anti-spam, антивирусная проверка вложений и т.д. С моей точки зрения - это всего лишь маркетинг. Работает это исключительно для нешифрованного smtp трафика, в то время как большинство сообщений именно шифруются. Для полноценной проверки электронной почты нужны устройства которые поддерживают MTA механизм. И такие продукты появились за долго до NGFW - решения класса Email Security.

5.2 SEG vs CAPES Говоря о решениях класса Email Security можно выделить две больших группы. 1. SEG - Secure Email Gateway. Это классический вариант защиты корпоративной почты. Входящее письмо сначала попадает на защищенный почтовый шлюз (SEG), который фильтрует СПАМ, вредоносные вложения, ссылки и прочее (работает как Mail Transfer Agent). Затем, легитимное письмо передается на почтовый сервер компании. Это может быть MS Exchange, Zimbra или open source решения, но, как правило, этот сервер является частью инфраструктуры компании. И уже в самом конце пользователь получает письмо в своем почтовом клиенте.

SEG решения могут быть как виртуальными, так в виде программно-аппаратных комплексов. 2. CAPES - Cloud-based API-enabled Email Security. Здесь все работает иначе. У компании нет своего почтового сервера. Вместо этого они используют почтовые сервисы. Например Office 365 или Google 56

Workspace. Т.е. это SaaS услуга. В этом варианте нельзя взять и просто поставить в разрыв какое-то SEG решение. Электронные сообщения приходят в инфраструктуру сервиса - облако. Но, есть возможность работать с этими сервисами через API (Application Programming Interface), в том числе выполнять различные проверки безопасности (СПАМ, вирусы, фишинг и прочее). Здесь уже нет необходимости в MTA функционале.

Таким образом пользователь может получать уже отфильтрованную почту. Если грубо резюмировать: SEG - классическая защита собственного почтового сервера, CAPES - защита облачной почты. На самом деле бывают решения, которые могут функционировать и как SEG, и как CAPES. Если же говорить о тенденциях, то в западных странах все больше компаний выбирают “почта как сервис” и отказываются от собственных серверов. Это быстрее, надежнее, удобнее, иногда и экономичнее. Самыми популярными почтовыми сервисами являются MS Office 365 и Google Workspace. В связи с этим, потребность в CAPES решениях только возрастает.

5.3 Главные угрозы Email Мы проговорили, что бОльшая часть почты шифруется и для полноценной проверки электронных сообщений нужно проверять их либо в режиме MTA (SEG решения), либо через интеграцию по API (CAPES решения). И прежде, чем перейти к обзору ключевых игроков рынка, хотелось бы сначала обсудить главные угрозы, которые в себе могут нести Email сообщения. - СПАМ. Если верить официальной статистике, до 90% всей электронной почты в мире это именно СПАМ. В основном это массовая рассылка с рекламой каких-то товаров, услуг и т.д. При этом нужно понимать, что СПАМ-ом является та рассылка, на получение которой вы не давали согласия. Может возникнуть вопрос: “Так а в чем опасность? Ну приходят какие-то письма”. Таких писем может быть очень много. Они отвлекают от работы (требуется время на их чтение) и мешают видеть действительно важные сообщения. - Вирусные вложения. Одна из самых древних и примитивных атак (это не значит, что неэффективных). Берется зараженный файл и 57

отправляется пользователю под видом легитимного вложения с определенной легендой - “отчет за прошлый год”, “приказ о повышении”, “накладная”, “договор оказания услуг” и прочие варианты. Существует даже определенная статистика по типам вирусных файлов, которые чаще всего рассылают:

-

Повышенную опасность представляет рассылка таких вложений от доверенных корпоративных адресов. Такое случается, если чья-то электронная почта была скомпрометирована, т.е. украден логин-пароль. Представьте, что вам приходит письмо от вашего руководителя с просьбой срочно проверить вчерашний отчет. Бдительность сильно падает. Поэтому все решения класса Email Security должны уметь эффективно бороться с вирусными вложениям, в том числе от корпоративных пользователей. Ссылки на зловредные ресурсы. Учитывая древность и массовость предыдущего типа атак, большинство компаний все же начали использовать какие-то Email Security решения, которые могут фильтровать СПАМ и проверять вирусные вложения, т.к. функционируют в режиме MTA, т.е. могут проверять зашифрованный SMTP трафик. Это две базовые функции (анти-спам и почтовый антивирус), которые присутствуют даже в бесплатных open source решениях (какие именно, мы обсудим чуть позже). В связи с этим злоумышленники стали применять более хитрую атаку - отправлять не сам вирусный файл, а ссылку на него. Это сильно повышает вероятность доставки почты до пользователя, особенно если в

58

-

компании присутствует почтовый антивирус. Получив письмо, пользователь может кликнуть на ссылку и начать скачивание файла уже через устройство на периметре сети, где может не оказаться хорошего NGFW решения. Атака становится еще более опасной, если пользователя отправляют на HTTPS ресурс. Тогда для полноценной проверки этого трафика необходимо, чтобы на пограничном устройстве была включена HTTPS инспекция (чего так не любят администраторы компаний). Таким образом email атака переходит на web атаку. Чтобы нивелировать подобный риск все коммерческие Email Security решения должны уметь проверять не только файлы, но и гиперссылки в сообщениях (open source решения обычно уже не имеют подобный функционал). Фишинг. Одна из самых сложных атак для детектирования с технической точки зрения. Нет ни вирусных файлов, ни вирусных ссылок. Т.е. классический сигнатурный анализ здесь не работает. Злоумышленник пытается обмануть пользователя в электронном сообщении, где с помощью различных техник старается получить нужную информацию. Он может попробовать перенаправить пользователя на поддельный ресурс, который выглядит идентично оригинальному (онлайн банк, социальная сеть, мессенджер), чтобы в итоге похитить логин-пароль. Может прямым текстом запросить нужные ему данные (пароль, номер карты, смс) представившись сотрудником банка или вашим бухгалтером (так называемая социальная инженерия). Техник очень много, но ключевая цель - обмануть пользователя и получить нужные данные без каких либо взломов. Хакеры давно поняли, что проще “взломать” человека, чем какой-либо сервис. Наиболее современные Email Security решения должны уметь проверять легитимность ссылок в письме, корректность запрашиваемых данных, использование шаблонных фраз (которые могли встречаться в других атаках) и т.д. Часто для этих целей используются алгоритмы машинного обучения (ML) и искусственного интеллекта (AI). Но, повторюсь, задача определения фишинга в письмах весьма и весьма сложна. Эта же угроза актуальна и для web трафика, т.е. для NGFW решений, которые тоже должны уметь с этим работать. Если же говорить о наиболее эффективном способе борьбы с фишингом и его многочисленными видами, то лучше всего работает обучение пользователей. Существует целый класс решений (User Security Awareness), направленный на обучение сотрудников компании основам безопасной работы в сети Интернет. Платформы позволяют проходить курсы, запускать собственные фишинговые компании для проверки пользователей и многое другое. Вот краткий список наиболее заметных решений на нашем рынке: 59

- Phishman; - Антифишинг; - Kaspersky ASAP. Обсуждение данных продуктов выходит за рамки нашей книги. Но мы рекомендуем ознакомиться с нашей бесплатной памяткой для обучения пользователей.

5.4 Типовой дизайн сети с Email Security Прежде, чем перейти к обзору рынка Email Security давайте рассмотрим все тот же типовой дизайн корпоративной сети и разберемся, где должен располагаться почтовый сервер, а где почтовый шлюз, который и будет обеспечивать защиту электронной почты. Мы рассмотрим применение именно классических почтовых шлюзов, которые еще иногда называют SMTP шлюзом или MTA. На английском языке это тот самый SEG (Secure Email Gateway).

60

Как видно из картинки, почтовый шлюз располагается в DMZ, а сам почтовый сервер уже во внутреннем серверном сегменте. Логически это схема выглядит немного проще:

В чем смысл такого дизайна? Почему нельзя получать почту сразу на свой почтовый сервер, на который можно установить антивирус. И зачем выделенный сегмент? Давайте разбираться. Согласно лучшим практикам построения сетей, все публичные сервисы компании должны находиться в выделенном сегменте, за межсетевым экраном, а лучше за NGFW. И это делается не для красоты. Публичность ресурса, т.е. его доступность абсолютно для всей сети Интернет, делает его уязвимым ко всевозможным атакам. Появляется высокий риск “взлома” такого публичного узла, т.е. когда злоумышленник проникает в вашу сеть. Если этот “взломанный” ресурс находится в одной сети с другими сервисами и серверами, то ничего не помешает хакеру продолжать свою атаку и получить доступ ко всей инфраструктуре. Это очень частый кейс, когда нерадивый администратор открывает доступ к какому-то узлу и забывает про это. Вспоминает, только когда все данные компании зашифрованы. Чтобы избежать подобного сценария и принято выносить публичные ресурсы в специальный сегмент (DMZ), который, как правило, формируется с помощью NGFW. Даже если какой-то узел будет взломан, то дальнейшее развитие атаки будет сильно затруднено все тем же NGFW, который может либо полностью блокировать трафик из DMZ в локальную сеть, либо строго фильтровать такой трафик с помощью контроля приложений, IPS, антивируса и т.д. Но зачем же в DMZ располагать именно почтовый шлюз, а не сам почтовый сервер? Все те же риски публичных ресурсов. 100% гарантию защищенности не дает ни одно решение, поэтому если вы развернете свой почтовый сервер в DMZ, то велика вероятность, что его взломают. Да, злоумышленник скорее всего не сможет проникнуть дальше в сеть благодаря NGFW и сегментации. Но он сможет украсть, повредить или подменить вашу электронную почту, что совершенно недопустимо для современного бизнеса, т.к. почта давно является одним из ключевых бизнес инструментов. Именно поэтому публичный доступ открывают к почтовому шлюзу расположенному в DMZ, а сам почтовый сервер помещают во внутреннем серверном сегменте. Стоит отметить, что даже при использовании почтовых 61

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

5.5 Ключевые игроки рынка Как и в случае с NGFW давайте рассмотрим ключевых игроков рынка Email Security. К сожалению я не нашел более менее свежий отчет от Gartner, но есть отличный отчет от другой аналитической компании Forrester за 2021 год. Вот как Forrester в целом описывает решения класса Email Security: “Technologies that protect organizations' email communications to mitigate and lessen the impact of email-borne attacks. These consist of on-premises or cloud-based secure email gateways (SEGs) and cloud-native API-enabled email security (CAPES) solutions. Capabilities include phishing, BEC, and spoofing protection, malware and malicious URL detection and remediation, email authentication, antispam, antimalware, data loss prevention (DLP), encryption, and phishing testing and education.” Т.е. с точки зрения Forrester рынок требует следующие функции: - Защита от фишинга; - Защита от компрометации учетных записей; - Защита от спуфинга; - Защита от СПАМ-а; - Защита от вирусов и вредоносных ссылок; - Защита от утечек (DLP); - Обучение и тестирование пользователей. Как видите, большую часть угроз мы уже описали выше. Также в своем отчете Forrester делает акцент на том, что все современные решения должны поддерживать не только классический вариант Email шлюза (SEG), но и защиту облачных сервисов (CAPES). Иногда их называют cloud native решения, которые изначально были разработаны именно для облака. Более того, Forrester утверждает, что все больше и больше компаний отказываются от традиционного варианта с собственным сервером электронной почты и выбирают облачных провайдеров Email сервисов, таких как MS Office 365 или Google Workspace. Дополнительным вызовом для “безопасников” становится массовое использование корпоративных мессенджеров, таких как MS Teams или Slack. Большая часть внутренней корпоративной коммуникации перешла именно в мессенджеры, которые представляют не меньшую угрозу. Пользователи могут подключаться к мессенджеру с любого устройства, передавать файлы, делиться ссылками и т.д. Все это, естественно, тоже надо проверять. И многие

62

CAPES решения позволяют это делать в рамках единой политики безопасность электронной почты, мессенджеров и даже облачных хранилищ файлов (OneDrive, Dropbox. Google Drive и т.д.). Это возможно только при использовании CAPES, т.е. cloud native решений, где интеграция осуществляется через API. Давайте перейдем к рейтингу Forester за 2й квартал 2023 года:

Как видно, лидирующие позиции занимают Proofpoint, Cloudflare, Trend Micro, Microsoft, Check Point. Следом идут не менее известные игроки: Mimecast, Cisco, Fortinet, Google и Barracuda Networks. Для полноты картины рассмотрим еще один рейтинг от Frost Radar за 2022 год:

63

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

5.5.1 Cisco Email Security В 2007 году компания Cisco приобретает компанию IronPort, которая была основана в 2000 году и специализировалась на защите электронной почты и безопасности веб-трафика (решения класса proxy). Начиная с 2012 года Cisco продает их уже под своим брендом:

64

- Cisco Email Security Appliance (ESA) - защита электронной почты; - Cisco Web Security Appliance (WSA) - защита веб трафика. Cisco ESA это классическое SEG решение, может поставляться в виде программно-аппаратного устройства, виртуальной машины или облачного сервиса (по сути та же виртуальная машина, но развернутая в облаке Cisco). Согласно статистике (устаревшей), еще недавно более 80% крупнейших интернет провайдеров и более 40% крупнейших предприятий использовали именно Cisco ESA. Решение также было очень популярно в России, включая банковский, нефтегазовый и государственный сектора. На текущий момент компания Cisco не обладает решениям CAPES, т.е. нативной поддержкой облачных почтовых сервисов типа Office 365 или Google Workspace, в связи с чем быстро теряет долю рынка. В России из-за санкций больше не продается (по состоянию на лето 2023 года).

5.5.2 FortiMail FortiMail от компании Fortinet представляет из себя классическое SEG решение. Может поставляться в виде программно-аппаратных устройств и виртуальных машин. Как и Cisco, Fortinet пока не имеет решения класса CAPES, что затрудняет использование FortiMail в связки с облачными почтовыми сервисами или корпоративными мессенджерами. Но по текущей информации ведется активная работа в этом направлении. FortiMail одно из самых молодых решений рейтинга, но успело завоевать большую популярность на рынке ввиду большой инсталляционной базы FortiGate-ов. В том числе в России. Многие заказчики предпочитают выстраивать защиту периметра единым вендором. Экосистемность упрощает интеграцию и администрирование. FortiMail, как и другие решения Fortinet в России больше не продается (по состоянию на лето 2023 года).

5.5.3 Microsoft При упоминании слов “Microsoft” и “почта” первая возникающая ассоциация Exchange Server. Этот почтовый сервер стал практически стандартом для корпоративного сегмента и занимает наибольшую часть рынка локальных почтовых серверов. Однако, долгое время Microsoft практически отсутствовал на рынке Email Security. Типовая конфигурация для большинства компаний: в серверном сегмент разварачивается Exchange Server с ролью MailBox, а где-нибудь в DMZ (публичный сегмент с доступом из сети Интернет) сервер с ролью Edge. И уже Edge интегрировали с каким-либо Email Security решением. Либо вообще полностью заменяли роль Edge сторонним решением. Последнее время ситуация сильно изменилась. У Microsoft появилось два важных продукта:

65

-

Exchange Online Protection (EOP). Типичное SEG решение обеспечивающее базовую защиту от спама и вредоносной почты. Может разворачиваться в облаке Microsoft для защиты облачного и локального Exchange сервера, либо в инфраструктуре клиента (on-prem). - Defender для Office 365. Продвинутая защита электронной почты, корпоративного мессенджера (Teams), файлового хранилища (OneDrive), корпоративного портала (SharePoint) и других сервисов входящих в подписку Office 365. Это уже решение класса CAPES, которое нативно работает с облачной инфраструктурой Microsoft и дополняет функционал EOP. Учитывая невероятную популярность и Exchange Server и Office 365, Microsoft имеет доступ к гигантскому кол-ву угроз, телеметрии и прочей статистике, что позволяет значительно повысить уровень детектирования угроз с применением различных механизмов машинного обучения. Немаловажным плюсом конечно же является простота интеграции, т.к. все это работает в рамках единой экосистемы Microsoft. На текущий момент (лето 2023 года) приобрести продукты Microsoft в России невозможно.

5.5.4 Trend Micro Компания Trend Micro одна из старейших компаний специализирующихся на кибербезопасности. Основана Стивом Ченом в 1988 году, в Калифорнии, но уже с 1992 года штаб квартира находится в Токио. Первые решения были предназначены для защиты рабочих станций, однако сейчас у компании большой выбор ИБ продуктов: - Endpoint Security; - Container Security; - Workload Security; - FIle Storage Security; - IPS; - Email Security; - и многое другое. Email Security содержит в себе несколько продуктов, как классический SEG (Deep Discovery Email Inspector, ScanMail и т.д.), так и CAPES решение для защиты облачной почты (Cloud App Security, Smart Protection для Office 365 и т.д.). Отдельно можно отметить, что у Trend Micro есть собственная платформа обучения пользователей (User Awareness), которая может симулировать фишинговые атаки. Многие решения Trend Micro были довольно популярны на российском рынке и присутствуют в нашей стране с 1998 года. Особенно популярными оказались решения по защите рабочих станций (входили в топ-5 по объему

66

продаж), IPS, Sandbox и защита электронной почты. Наибольший спрос наблюдался в банковском сегменте. На текущий момент (лето 2023 года) приобрести продукты Trend Micro в России невозможно.

5.5.5 Check Point В самом начале главы про Email Security мы обозначили, что большинство NGFW решений не справляются с этой задачей, т.к. для полноценной проверки сообщений необходимо работать в режиме MTA, т.е. быть промежуточным почтовым сервером. Check Point один из немногих NGFW, который умеет это делать. Для борьбы с вредоносной почтой имеется отдельный блейд (функционал в терминологии Check Point) - Anti-Spam. Есть даже нативная интеграция с Sandbox, которые мы обсудим чуть позже. Технически, все это позволяет отнести шлюзы Check Point к категории SEG решений. Почему только технически? Anti-Spam на шлюзах Check Point практически всегда проигрывал и функционально, и качественно, большинству специализированных решений Email Security. При этом использование Anti-Spam на шлюзах приводило к его повышенной нагрузке. Отсутствовала гибкость настроек. В большинстве случаев Anti-Spam от Check Point используют, когда нет другого решения. Принцип “лучше чем ничего”. Данный модуль до сих пор присутствует в шлюзах Check Point, но очень слабо развивается и большинство нововведение касается защиты от атак нулевого дня (Sandbox). Сам Check Point рекомендует использовать специализированные Email Security решения перед проверкой почты на их шлюзах. Ниже представлен типовой дизайн:

67

Как видно из картинки, сначала почта фильтруется на каком-либо почтовом шлюзе, затем передается на Check Point, который работает в режиме MTA, тот проверяет сообщения собственными движками (в том числе с помощью “песочницы”) и уже после этого письмо попадает на почтовый сервер компании. Все изменилось после покупки компании Avanan. Этот стартап появился в 2015 году и сразу разрабатывался как cloud native решение для защиты облачной почты, мессенджеров и облачных файловых хранилищ. Т.е. таких SaaS сервисов как Office 365, Google Workspace, Slack, Teams и т.д. При работе с Avanan отмечается простота интеграции. С помощью API подключение к сервисам занимает не более 10 минут. Решение обеспечивает высочайший уровень блокирования практически всего спектра угроз: спам, вирусы, фишинг и прочее. Это подтверждается различными рейтингами. Компания Check Point приобрела Avanan в 2021 году за 250-300 млн долларов, что является крупнейшей покупкой для израильской компании. На данный момент решение называется Check Point Harmony Email & Collaboration (HEC) и полностью интегрировано в экосистему Check Point Infinity (концепт безопасности). Таким образом, Check Point имеет оба класса решений по защите почты: SEG (межсетевой экран с MTA функцией) и CAPES (Harmony Email & Collaboration). На текущий момент (лето 2023) Check Point продолжает работу в России, но поддерживает санкции против государственного, нефтегазового и банковского секторов.

5.6 Отечественный рынок После массового ухода зарубежных вендоров в 2022 году на Российском рынке образовался вакуум в сегменте защиты электронной почты. Наибольшей популярностью пользовались Cisco ESA, FortiMail, Trend Micro и конечно же Microsoft. Когда появилась задача их замены, вдруг оказалось, что на отечественном рынке практически нет специализированных решений Email Security (существующие решения мы обсудим буквально в следующем параграфе). Многие производители российских NGFW заявляют эту функцию в составе своих решений, но, как мы уже обсуждали ранее, это не более чем маркетинг, т.к. для полноценной проверки почты требуется непосредственное участие в почтовом тракте, т.е. работать в режиме MTA, чего большинство отечественных решений НЕ умеют. Проблема замены классических почтовых шлюзов (SEG) весьма серьезная. Но все же есть варианты в виде пары продуктов или использования тех же open source решений, которые мы обсудим чуть позже. Самая серьезная проблема появилась у компаний, которые были вынуждены мигрировать с

68

зарубежных облачных почтовых сервисов, все тех же Office 365 или Google Workspace. Как оказалось, ни один отечественный облачный почтовый сервис не поддерживает интеграцию через API, по крайней мере на текущий момент (Yandex 360, VK WorkMail). С этим связана серьезная проблема - полное отсутствие отечественных решений по защите облачной почты (CAPES). Таким образом, если какая-то компания захочет продолжать использовать SaaS решения для почты, корпоративных мессенджеров или файловых хранилищ, то они должны быть готовы к полному отсутствию средств защиты этих сервисов. Это очень серьезные риски. Что же осталось на нашем нашем рынке в сегменте Email Security? Давайте рассмотрим основных, наиболее заметных игроков.

5.6.1 Kaspersky Лаборатория Касперского одна из немногих российских ИБ компаний, которая имеет успешный бизнес и за рубежом (присутствует в более чем 200 странах). В частности, продукты Kaspersky Endpoint Security до недавнего времени использовались в государственных учреждениях Европы и США, но были запрещены после слухов о шпионаже и сотрудничестве компании с ФСБ. Лаборатория Касперского входит в четверку ведущих мировых производителей программных решений по защите конечных устройств (Endpoint Protection). Компания имеет высочайшую экспертизу в сфере исследования киберугроз и вирусной активности. Фиды (информация о зловредных файлах, сайтах, сигнатурах, зловредных ip-адресах и т.д.) и программное ядро от Лаборатории Касперского используют и другие производители решений по кибербезопасности, даже зарубежные, такие как Check Point, Microsoft, Juniper и т.д. Можно сказать, что компания начала свою историю в 1990 году, когда Евгений Касперский возглавил команду, которая разрабатывала антивирусный продукт - AntiViral Toolkit Pro (AVP). Решение не было коммерчески успешным (объем продаж менее 200$ в месяц). В 1994 году открылся профильный магазин, а отдел распространения возглавила жена (на тот момент) Евгения Наталья Касперская. Уже к 1997 году объем продаж составил 1 млн $ и было принято решение о создании отдельной компании. Именно Наталья настояла на бренде Kaspersky (тогда еще Kaspersky Lab). В 2022 году оборот компании составил 36.5 млрд рублей, а количество сотрудников более 4000. Портфель компаний включает в себя множество решений из различных классов средств защиты. Мы же рассмотрим сегмент Email Security. На текущий момент у Kaspersky можно выделить три ключевых продукта по защите электронной почты: 1) Kaspersky Security для Microsoft Exchange Server. Ни для кого не секрет, что MS Exchange до сих пор является самым популярным

69

почтовым сервером в корпоративном сегменте. Kaspersky предлагает специальное ПО, которое устанавливается непосредственно на сам почтовый сервер Exchange и позволяет выполнять ключевые функции по защите почты: - Блокировка вредоносных вложений; - Блокировка СПАМа; - Блокировка фишинговых писем; - Контроль почтового трафика; - И т.д. Весьма популярное решение и используется даже теми компаниями, которые имеют выделенное Email Security решение. Таким образом обеспечивается эшелонированная защита. 2) Kaspersky Security для Linux Mail Server (KLMS). Аналог предыдущего решения, но уже не для Exchange сервера, а для любых других почтовых серверов на основе Linux. Часто это ПО используется на пограничных почтовых шлюзах, а не на самом почтовом сервере. Многие отечественные NGFW также используют KLMS в составе своего решения (например Ideco). 3) Kaspersky Security Mail Gateway (KSMG). Самостоятельный и полностью самодостаточный почтовый шлюз от Kaspersky. Т.е. для KSMG не нужен какой-то почтовый сервер на Linux или на Exchange. Он содержит все, что нужно для функционирования в режиме почтового шлюза. Доступен только в виде виртуальной машины. Это наиболее функциональное решение Kaspersky, которое обеспечивает все вышеобозначенные функции и имеет много дополнительных преимуществ. Продукт активно развивается, в отличии от двух предыдущих вариантов. Наиболее важные обновления появляются сначала именно для KSMG. Можно сказать, что сейчас KSMG переживает “второе рождение”, т.к. оказалось, что это чуть ли не единственное более менее серьезное решение на фоне ухода зарубежных игроков. Из важного - KSMG умеет проверять почтовые вложения в “песочнице” Kaspersky. Это весьма важный функционал, который мы обсудим подробнее чуть позже. Kaspersky также имеет решение по защите облачной электронной почты - Office 365. Т.е. решение класса CAPES. На данный момент решение теряет актуальность на российском рынке из-за санкций и невозможности продлевать подписку Microsoft. Отдельно хотелось бы отметить такой продукт, как Kaspersky Automated Security Awareness Platform (ASAP) - онлайн платформа по обучению и тестированию пользователей на знание основ безопасной работы в сети интернет (в том числе по работе с почтой). Иногда это называют “цифровой

70

гигиеной”. Согласно нашему фреймворку решение этого класса относится к User Layer, но я не мог не упомянуть его.

5.6.2 Dr.Web Еще один значимый российский продукт в сфере ИБ - Dr. Web. Началом истории компании можно считать 1992 год, когда были объединены два решения: Spider (преемник Tadpole) и доктор Web (преемник Tornado). Создатель антивируса - российский программист Игорь Данилов. Продукт изначально отличался от других решений за счет использования встроенного симулятора центрального процессора, что позволило детектировать даже неизвестные вирусы. Можно сказать, что это были первые зачатки борьбы с Zero Day, т.е. угрозами нулевого дня (мы подробнее опишем это понятие в главе Sandbox). Уже в 1997 году Dr.Web вошел в тройку лучших антивирусных решений. В этом же году был выпущен один из первых антивирусов для unix/linux систем. На данный же момент, флагманским продуктом компании является решение по защите рабочих станций - Dr.Web Enterprise Security Suite (решение для бизнеса). Что касается защиты электронной почты, то здесь не так много вариантов. На текущий момент, единственным решением Dr.Web для защиты электронной почты является - Dr.Web Mail Security Suite. Это ПО не является самостоятельным почтовым шлюзом (как Cisco ESA или KSMG) и используется как дополнительный модуль для популярных почтовых серверов Unix, MS Exchange, IBM Lotus Domino и Kerio. Решение обладает весьма базовым функционалом в части фильтрации почты и в первую очередь сводится к антивирусной проверке почтовых вложений. Из важных ограничений: - нет контентной фильтрации, - нет репутации доменов, - нет фильтрации ссылок, - нет анализа графических изображений, - и т.д. Из-за указанных недостатков чаще всего используется как обычный антивирусный модуль для других решений класса Email Security. Например вы можете использовать open source решение для почтового шлюза (позже обсудим варианты) или MS Exchange с ролью Edge, а Dr.Web Mail Security Suite как дополнительный антивирусный модуль. Примечательно, что Dr.Web с 2001 года используется компанией Yandex для проверки всех писем в сервисе Яндекс Почта (в основном антивирусная проверка вложений). Также “движок” Dr.Web используется многими зарубежными антивирусными решениями, например Kingsoft AntiVirus (Китай).

71

5.6.3 F.A.C.C.T. (Group-IB) Еще одной весьма успешной международной компанией являлась российская Group-IB, которая была основана в 2003 году студентами-первокурсниками кафедры информационной безопасности МГТУ им. Баумана. Первоначально компания специализировалась исключительно на расследованиях кибер-преступлений. Group-IB является официальном партнером Интерпола и Европола, участвуя в международных расследованиях. В 2019 году был открыт офис в Сингапуре, затем Амстердаме и Дубае. На 2022 год в компании работало более 550 человек. Кроме кибер-расследований компания разрабатывала большое количество решений по информационной безопасности: - “Песочница” (класс Sandbox решений); - Сетевой сенсор аномалий (класс NTA/NDR решений); - Продвинутая защита рабочих станций (класс EDR решений); - Почтовый шлюз (рассмотрим его через параграф); - Защита бренда; - Платформа для кибер-разведки (Threat Hunting); - Защита от “фрода”; - Центр реагирования на киберугрозы (SOC); - и т.д. Наибольшей популярностью продукты Group-IB пользовались в банковской сфере. Среди клиентов такие крупные компании как: Сбер, Альфа-Банк, ВТБ, Тинькофф, Ростелеком, Билайн, МТС, Мегафон, Роскосмос и т.д. Поворотной точкой в истории компании стал арест основателя Ильи Сачкова в 2021 году по подозрению в госизмене. На текущий момент (лето 2023) все еще идет следствие. Данное событие сильно ударило по менеджменту компании, а также сказалось на репутации среди клиентов. В 2022 году было принято решение разделить бизнес. Group-IB продолжил работу на зарубежном рынке со штаб-квартирой в Сингапуре. Для работы на российском и СНГ рынке была выделена отдельная компания - F.A.C.C.T. (Fight Against Cybercrime Technologies). Трудно судить о дальнейшем будущем компании, но ее решения однозначно заслуживают внимания в технологическом плане. В частности, F.A.C.C.T имеет одно из немногих отечественных решений по продвинутой защите электронной почты - Business Email Protection (далее BEP). Отличительные особенности продукта: - Почтовый шлюз BEP может быть развернут за несколько минут в облаке F.A.C.C.T. Электронные сообщения “заворачиваются” на шлюз с

72

помощью изменения DNS записей, т.е. без изменений инфраструктуры клиента. - Почтовый шлюз BEP также может быть развернут и локально, по классической схеме - в DMZ. - BEP является одним из немногих решений, которое поддерживает нативную API интеграцию с облачной почтой Office 365 и Gmail Workspace. Интеграций с отечественными облачными провайдерами почты нет, т.к. ни один российский сервис пока не предоставляет свой API (по состоянию на лето 2023 года). Как видно, BEP от компании F.A.C.C.T можно отнести как к классическим SEG решениям, таки и к CAPES. Почтовый шлюз BEP обладает всеми необходимыми модулями проверки безопасности электронной почты: - Антиспам и Антифишинг; - Классический сигнатурный анализ вложений и ссылок; - Репутационная проверка писем с использованием собственной Threat Intelligence платформы; - Встроенная проверка вложений с помощью технологий “песочниц”. Наиболее важен последний пункт - нативная интеграция с собственной “песочницей”. Необходимость подобной дополнительной проверки мы обсудим в разделе Sandbox, а саму проблему интеграции классических SEG решений с “песочницами” мы опишем буквально в следующей главе.

5.7 Ключевые проблемы Email Security Мы рассмотрели причины необходимости выделенного решения Email Security, ключевые задачи продуктов этого класса и основных игроков рынка, как зарубежного, так и отечественного. Какие же ключевые проблемы существуют в этом сегменте? Мы рассмотрим российский рынок, т.к. он наиболее актуален для нас. 1. Отсутствие конкуренции Как вы наверно заметили, на текущий момент на российском рынке есть всего два профильных и более менее “взрослых” продукта - KSMG (Kaspersky) и BEP (F.A.C.C.T). Конкуренция практически отсутствует, что всегда сказывается на качестве продукта, стоимости и скорости инноваций. Если говорить о KSMG, то данный продукт только в прошлом году получил “новую жизнь”. BEP от F.A.C.C.T (ранее Group-IB Atmosphere) видится серьезным игроком, но будущее компании туманно.

73

2. Интеграция с Sandbox В одной из следующих глав мы подробно обсудим важность использования “песочниц”. Но уже сейчас мы можем сформулировать нашу аксиому для почты - “Проверка почтовых вложений с помощью Sandbox является обязательной для любой компании”. Помним, что электронная почта до сих пор самый популярный вектор атаки. Так уж сложилось, что почти все игроки рынка Email Security выстраивают собственную экосистему, которая включает и собственную песочницу. FortiMail, Check Point, Cisco ESA, KSMG, BEP - все имеют собственные технологии песочниц. Например KSMG нативно интегрируется с песочницей Касперского (KATA). BEP от F.A.C.C.T имеет собственную разработку (ранее TDS Polygon). С одной стороны это хорошо - нативная интеграция. Но что делать заказчикам, у которых уже есть песочница от другого производителя? Покупать еще одну чисто для электронной почты? Это экономически неоправданно. Поэтому часто появляется задача “подружить” разные классы решений от разных производителей. И это актуально не только для почтовых шлюзов, но и для NGFW, WAF, Сканеров, SIEM систем и т.д. Но вернемся к нашему примеру “почтовый шлюз + песочница”. Перед выбором решения, как минимум, важно понимать, какую песочницу вы планируете затем использовать и проверить, что подобная интеграция возможно. В противном случае ваш почтовый шлюз не сможет обеспечить надежную защиту.

3. Отсутствие CAPES решений Мы уже обозначали эту проблему несколько раз. Она состоит из двух частей: - На текущий момент (лето 2023) на российском рынке отсутствуют провайдеры электронной почты, которые позволяют нативно интегрировать сторонние сервисы безопасности, как это реализовано в Office 365 и Google Workspace. Да, есть Яндекс 360, VK WorkMail и т.д., но не один из них не предоставляет нужного API. - Думаю по этой же причине у нас практически нет и CAPES решений, которые способны защищать облачную электронную почту, которая предоставляется как сервис. Все это не позволяет огромному количеству российских компаний плавно мигрировать с зарубежных сервисов (все те же Office 365 и Google Workspace), без необходимости разворачивать собственную инфраструктуру. Проблема весьма острая, как для производителей почтовых шлюзов, так и для отечественных почтовых сервисов. Надеюсь в ближайшее время будет найдено решение.

5.8 Бесплатные решения В отличии от NGFW, рынок Email Security изобилует бесплатными или условно бесплатными решениями. Не хватит и страницы чтобы перечислить все

74

дистрибутивы. Но если заглянуть внутрь, то практически все они базируются на трех ключевых компонентах: 1. Postfix - open source агент передачи почты. Тот самый Mail Transfer Agent (MTA). Без этого компонента невозможна полноценная проверка почты. Есть еще один распространенный open source аналог - Sendmail. Однако, субъективно, Postfix более популярен. 2. SpamAssassin - один из самых популярных анти-спам фильтров. Этот open source проект развивается в Apache Software Foundation и может использоваться любым желающим. 3. ClamAV - один из самых известных бесплатных антивирусных пакетов. Это не open source решение, но свободно распространяется под лицензией GNU General Public License. В 2007 году ClamAV был приобретен компанией SourceFire, которые планировали объединить этот движок со своим IPS решением - Snort. Сам SourceFire был приобретен компанией Cisco в 2013 году. Продукты Snort и ClamAV продолжают развиваться под эгидой Cisco и доступны для свободного распространения, но на текущий момент (лето 2023) для России есть серьезные проблемы с доступом к автоматическим обновлениям. Есть возможность ручного обновления сигнатурной базы. Безусловно есть и другие продукты и их разновидности ввиду открытости исходного кода. Но все же мы перечислили наиболее популярные и ключевые. Все три упомянутых продукта могут быть самостоятельно установлены как обычные пакеты на практически любой linux/unix дистрибутив. Вы буквально можете сами создать свой собственный почтовый шлюз. Чем, как вы понимаете, пользуются многие компании. Вот наиболее популярные, готовые и бесплатные решения, собранные на основе упомянутых пакетов: - Proxmox Mail Gateway; - MailScanner; - MailCleaner; - и т.д. Несмотря на простоту и бесплатность подобных решений, огромное количество компаний продолжают игнорировать угрозу со стороны электронной почты. Естественно, эти бесплатные продукты уступают коммерческим, т.к. реже обновляются, имеют меньшую экспертизу, более скудную базу и не всегда могут интегрироваться со сторонними решениями (например с песочницей). Но если у вас проблемы с бюджетированием ИБ, то подобные варианты будут точно лучше, чем голый сервер “торчащий” в Интернет. Как минимум, у вас будет заложена грамотная архитектура, с выделенным почтовым шлюзом в DMZ. Добавлю, что даже такие бесплатные решения можно серьезно “прокачать” если добавить в состав коммерческий антивирус, например вышеупомянутые KLMS и Dr.Web Mail Security Suite. 75

5.9 Резюме по Email Security ● Почта до сих пор является главным вектором атаки на корпоративных пользователей. ● Ключевые угрозы через почту: СПАМ, вирусные вложения, ссылки на зловредные ресурсы, фишинг. ● Большинство NGFW решений не умеет фильтровать шифрованный трафик электронной почты. ● Для реальной защиты электронной почты требуются выделенные решения, которые работают в режиме Mail Transfer Agent. ● Типовое название таких решений - почтовый шлюз или SMTP шлюз. ● Существует для вида решений по защите почты: SEG (почтовый шлюз) для защиты собственного почтового сервера, CAPES для защиты облачной почты (Office 365, Google Workspace). ● В типовом дизайне сети SEG располагается в DMZ (формируется с помощью NGFW), почтовый сервер во внутреннем серверном сегменте. ● Популярные зарубежные решения на российском рынке: Cisco ESA, FortiMail, Microsoft Defender, Trend Micro, Check Point. ● Существующие отечественные решения по защите почты: Kaspersky (KSMG). Dr.Web (Mail Security Suite), F.A.C.C.T (BEP). ● На отечественном рынке нет решений CAPES, которые интегрировались бы отечественными сервисами облачной почты. Как и нет облачных сервисов, которые бы предоставляли возможность подобной интеграции. ● Для решений Email Security крайне важна интеграция с решениями класса Sandbox.

76

6. WAF Что такое современная сеть Интернет? Если спросить об этом сетевого инженера, он вам без промедление ответит, что это просто объединение огромного количества локальный сетей, которые могут друг с другом взаимодействовать. Чисто технически - абсолютно верно. Это могут быть гигантские сети (ЦОД-ы) или небольшие (сервера небольших компаний, сети пользователей). Сети разных городов, стран и даже континентов. Да, есть публичные сети, а есть приватные. Причем приватные сети формируются как раз с помощью межсетевых экранов или, в идеале, с помощью NGFW, которые мы обсуждали в первую очередь. Но если задать тот же самый вопрос обычному человеку, то скорее всего он начнет говорить что-то про веб-сайты или приложения смартфона. То, с чем он чаще всего взаимодействует. И в целом, он будет тоже прав. Просто он рассматривает Интернет на уровень выше - уровень приложений, а если точнее, то уровень веб-приложений. Современный Интернет это набор практически бесчисленного количества веб-сайтов или веб-сервисов. Мы каждый день читаем новости на различных новостных порталах, проверяем почту, заказываем еду или товары, переписываемся в мессенджерах, смотрим смешные видео на youtube. И делаем это на компьютере, так и на смартфонах. Все это базируется на веб-технологиях, а в качестве протокола передачи данных часто используется именно HTTP/S (помним, что HTTPS это все тот же HTTP, который просто шифруется). Помимо нас, пользующихся различными веб-сервисами ежедневно и в личных целях, есть огромное количество компаний, чей бизнес очень сильно завязан на свои собственные веб-сервисы. Иногда веб-сервис и есть бизнес образующий эту компанию. Приведем примеры. - Интернет-банк. Трудно представить современный банк, который не имел бы веб-сайт с личным кабинетом или приложение для смартфона. - Интернет-магазин. Многие компании продают свои товары не только в физических магазинах, но и через Интернет. Более того, некоторые продают только через Интернет. - Государственный портал. Веб-сервисы, которые позволяют обслуживать огромное количество людей. Принимать и выдавать документы, заявления, справки и прочее. - Страховая компания. Веб-сайт с личным кабинетом клиента, где он может загружать документы, оплачивать полис и многое другое. Это лишь малая часть примеров, когда веб-сервис является важным или даже ключевым бизнес активом компании. Простой, утрата или компрометация такого актива как правило влечет за собой серьезные финансовые или 77

репутационные потери. Простой интернет-банка может привести к потери денег (комиссии за переводы, открытие новых вкладов) или даже потере клиентов. Аналогично с интернет-магазином. Взлом и последующая утечка данных с государственного портала или страховой компании может серьезно повлиять на репутацию сервиса или вылиться в огромные штрафы. Публичность подобных веб-сервисов подразумевает доступность абсолютно для каждого, в том числе и для злоумышленников. Согласно отчету компании Positive Technologies, в 2022 году число успешных атак на веб-ресурсы компаний в среднем возросло на 56%. Ниже на рисунке отражены доли инцидентов связанных именно с атаками на веб-ресурсы (по российскому рынку):

Все это отражает чрезвычайную важность защиты веб-активов. Как ни странно, NGFW для этого НЕдостаточно и требуется отдельный класс средств защиты - Web Application Firewall (WAF).

6.1 WAF vs NGFW Для новичка в сфере ИТ/ИБ довольно просто запутаться в понятиях. Next Generation Firewall и Web Application Firewall. Слово Firewall встречается в обоих случаях и именно поэтому может возникнуть подобная путанция, хотя устройства абсолютно разные и даже устанавливаются на разных участках сети. Так в чем же разница и почему NGFW недостаточно для защиты веб-ресурсов? Давайте разбираться. Если попытаться максимально лаконично изобразить разницу между NGFW и WAF, то получится следующая картинка:

78

-

Как видно из картинки, NGFW защищает всю сеть компании, формируя доверенные и недоверенные зоны (ставим забор вокруг крепости с воротами), но больше нацелен на глубокую проверку трафика (DPI), который генерируют внутренние пользователи или сервисы при выходе в Интернет. Помогает ограничить их действия и проверить безопасность любого (независимо от протокола) возвращаемого трафика. При этом любой нелегитимный, т.е. неразрешенный трафик, который инициируется из внешней сети, будет заблокирован. - WAF же как раз предназначен для проверки трафика от внешних интернет-пользователей до внутренних веб-ресурсов, которые чаще всего располагаются в DMZ (почему так, обсудим позже). И проверяется не любой трафик, а исключительно веб-трафик и чаще всего протокол HTTP, т.е. уровень приложений (L7). Безусловно, NGFW тоже может и должен работать на L7 уровне. Но это используется для детектирования приложения, с возможностью его блокировки или разрешения. Правильность работы этого приложения NGFW не проверяет (хотя и есть исключения для некоторых конкретных приложений). WAF же разбирает HTTP трафик до последнего винтика и может проверить, а те ли винтики используются. Давайте попробуем рассмотреть разницу WAF и NGFW на более жизненном примере все той же крепости. В чем ключевая задача NGFW? Да, он безусловно будет запрещать вход просто посторонним людям или караванам (блокировать нежелательный трафик извне). С этим справится любой портовый межсетевой экран. NGFW не просто сформировал забор вокруг крепости и организовал ворота - единственная точка, где может кто-то проходить (сетевой трафик). NGFW дополнительно ставит на ворота охрану, которая досконально проверяет вас и ваш груз на входе и выходе. Это можно

79

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

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

80

-

Где был куплен товар? Возможно товары из этого города под запретом (black lists в терминологии NGFW). - А разрешено ли вообще в крепость заносить сундуки? (разрешен ли такой протокол передачи данных?) - А что внутри закрытого сундука? (DPI или глубокая проверка содержимого с расшифровкой трафика) - Не похожи ли предметы внутри на те, что запрещены к ввозу? (сигнатурный анализ на предмет обнаружения зловредов) - И т.д. Думаю это весьма понятная аналогия и в этом плане работа NGFW абсолютна понятна. Но представим, что у нас в крепости есть магазинчик местного жителя (веб-приложение или веб-сайт). Хозяин магазинчика дает рекламу за пределами крепости, что продает массу нужных товаров: книги, сувениры, фрукты, овощи. Хозяин магазинчика договаривается с охраной на воротах крепости, что если придут люди и скажут, что они к нему, то их надо пропустить. А еще им надо разрешить проносить с собой корзины для товаров. Если магазинчик заработает деньги, то заработает и вся крепость (налоги!). Охрана соглашается пропускать через ворота всех желающих посетить этот магазинчик. В технических терминах мы только что создали разрешающее правило доступа на NGFW, где указали, что всем из Интернета разрешен доступ к веб-сайту, пусть даже только по одному протоколу - HTTP/S (80 или 443 порт). А теперь представим следующую картину. Приходит покупатель в крепость, к воротам. Возможный диалог: - Охрана: Стой, кто идет? - Покупатель: Я иду, в магазин ваш. - Охрана: Ты с корзиной? - Покупатель: Да. - Охрана: Проходи. В технических терминах NGFW увидел трафик из внешней сети до внутреннего веб-сайта по HTTP/S протоколу. И согласно разрешающему правилу этот трафик пропустил. Безопасно ли это? Абсолютно нет. Более того, все современные веб-ресурсы работают именно с шифрованным HTTPS трафиком. Т.е. без инспекции на NGFW ничего и не проверить. Неизвестно кто, только что прошел в нашу крепость через всю охрану и мы его особо не проверяли. С собой у него возможно ничего нет. А вот что он будет делать уже внутри, в самом магазине, мы не знаем. И это ключевая опасность, как для магазина (веб-ресурса), так и для всей крепости (всей корпоративной сети). Чтобы нивелировать описанную угрозу, когда NGFW пропускает веб-трафик с минимальными проверками, был создан отдельный класс решений - Web Application Firewall (далее WAF). Продолжая аналогию с 81

крепостью, WAF создает некую буферную зону с охраной непосредственно перед нашим магазинчиком или внутри. Устанавливаются сканирующие рамки, камеры наблюдения, по магазину ходит охранник, которые следит за всеми действиями покупателя. Технически, WAF устанавливается в непосредственной близости к веб-приложению, а точнее перед ним и проксирует все запросы внешних пользователей. Терминирование и расшифровка HTTPS трафика происходит именно на нем, а значит WAF “видит” абсолютно все действия пользователя на защищаемом веб-ресурсе. Все клики мышкой, все запросы, все скачиваемые или загружаемые файлы. Кто-то может опять задаться вопросом: “а почему этого не делать на NGFW?” Там же тоже есть охрана и различные проверки. И тут все дело в трудозатратах. Если на воротах крепости выделять охранника под каждого нового посетителя нашего магазинчика, которого он лично проводит до нужного места, а затем будет следить за ним, то нам потребуются на воротах либо очень много охраны, либо пропускная способность ворот будет сильно ограничена, т.к. не хватает людей. Начнут собираться очереди и до магазина дойдут далеко не все. Технически, задача WAF на NGFW реализуема и чуть позже мы даже рассмотрим некоторых вендоров. Но это скорее исключение из правил. WAF потребует значительного увеличения системных ресурсов, которых и без того требуется немало для любого NGFW. Для примера, минимальные системные требования базовой версии PTAF (WAF от компании Positive Technologies) составляют 6 vCPU, 16 Гб RAM и 500 Гб HDD. И эта конфигурация всего для 1000 запросов в секунду. У многих NGFW схожие параметры для средних сетей в 500-800 пользователей. Функционал WAF будет существенно увеличивать стоимость NGFW, а нужен WAF далеко не каждой организации. Таким образом, ключевой тезис этой главы: WAF и NGFW не являются взаимозаменяемыми сущностями, служат для решения разных задач, размещаются в различных точках сети и в большинстве случаев администрируются разными командами.

6.2 Ключевые угрозы web-приложений Прежде чем перейти к описанию типового дизайна сети с WAF давайте рассмотрим ключевые угрозы для веб-приложений. Исходя из этого будет более очевидно от чего же конкретно защищает WAF. Для начала определимся с терминологией. Что такое веб-приложение? Только его надо защищать с помощью WAF? А что на счет обычного сайта? Это частые вопросы от владельцев бизнеса, директоров и администраторов, которые никогда раньше не занимались этим вопросом. Думаю вы уже заметили, что ранее я употреблял несколько понятий: веб-сайт,

82

веб-приложение, веб-ресурс, веб-сервис. Все эти термины хоть и разные, но представляют собой одну сущность с точки зрения защиты - информация, к которой пользователь получает доступ используя веб-технологии (http/s, html, css, JavaScript) или веб-интерфейс (браузер). Т.е. клиент взаимодействует с веб-сервером с помощью браузера или же мобильного приложения. С инфраструктурной точки зрения, почти любой сайт или веб-приложение можно разделить на три составляющие: - Клиентская часть - отвечает за действия, выполняемые пользователем. - Серверная часть - отвечает за процессы, происходящие на сервере. - База данных - отвечает за хранение упорядоченной информации. Все три составляющие имеют собственные уязвимости и проблемы конфигурации, которые могут быть использованы злоумышленником для “взлома” веб-приложения и последующего уничтожения/подмены/кражи информации. Проблем с безопасностью было так много, а их критичность настолько высока, что была создана отдельная некоммерческая организация - Open Web Application Security Project (далее OWASP), которая занимается изучением всевозможных угроз для веб-приложений и регулярно публикует бесплатные отчеты, материалы, видео и инструменты по выявлению уязвимостей. Среди отчетов есть один, наиболее известный - OWASP Top 10. OWASP Top 10 - документ, в котором перечислены основные проблемы, связанные с безопасностью веб-приложений. Он регулярно обновляется, чтобы постоянно отображать 10 наиболее серьезных рисков, с которыми сталкиваются организации. Давайте их перечислим (отчет за 2021 год): 1. Нарушенный контроль доступа (Broken Access control); 2. Ошибки криптографии (Cryptographic Failures); 3. Инъекции (Injections); 4. Небезопасный дизайн приложения (Insecure Design); 5. Неправильная конфигурация безопасности (Security Misconfigurations); 6. Использование компонентов с известными уязвимостями (Vulnerable and Outdated Components); 7. Ошибки идентификации и аутентификации (Identification and Authentication Failures); 8. Программные ошибки (Software and Data Integrity Failures); 9. Недостаточно подробные журналы и слабый мониторинг (Security Logging and Monitoring Failures); 10. Подделка запроса на стороне сервера (Server-Side Request Forgery (SSRF). Повторюсь, это ключевые проблемы веб-приложений, которые очень часто приводят к успешному взлому. Они расположены по степени критичности, более того, их рейтинг меняется из года в год и появляются новые типы проблем. На картинке ниже различия между 2017 и 2021 годом: 83

Мы не будем подробно описывать технические особенности и механизм всех атак. Ключевой смысл этого списка - любой WAF должен уметь обеспечивать защиту от этих уязвимостей.

6.3 WAF vs WAAP Мы уже разобрались, что WAF это не NGFW и что WAF устанавливается непосредственно перед защищаемым веб-приложением. Казалось бы, можно переходить к обсуждению ключевых игроков и типового дизайна сети. Но, к сожалению, не все так просто и даже среди WAF есть уже два класса: классический WAF и более новый WAAP. Считается, что WAAP это некий Next Generation WAF, т.е. следующая эволюция. Здесь конечно же не обошлось без маркетинга, как и в истории UTM vs NGFW, которую мы обсуждали ранее. Но все же есть принципиальные архитектурные отличия этих двух классов, которые мы и рассмотрим.

6.3.1 Классический WAF Частично мы уже рассмотрели, что такое традиционный WAF. Как минимум он должен уметь защищать от уже упомянутого OWASP Top 10. Интегрируется, как правило, в виде отдельной “железки” (ПАК - программно-аппаратный комплекс) или виртуальной машины. Естественно поддерживается отказоустойчивая кластерная конфигурация. Как мы уже обсуждали, с точки зрения прохождения веб-трафика WAF всегда устанавливается перед веб-приложением. Один WAF может защищать несколько веб-приложений, но все запросы придется “завернуть” именно него, даже если веб-приложения находятся в разных ЦОД-ах. Я попытался схематично отобразить прохождение трафика на рисунке ниже:

84

Естественно, это всего лишь логическая схема без учета того же NGFW. Подробную схему мы рассмотрим в следующем параграфе. Важный момент. У большинства традиционных WAF решений нет выделенной сущности сервера управления. Т.е. и проверка/фильтрация трафика, и управление политикой осуществляется на одном устройстве. Такой подход часто называют standalone вариантом. Традиционно считается, что WAF это исключительно сигнатурный анализ трафика. Т.е. WAW разбирает HTTP трафик и находит там паттерны вредоносного поведения, попытки эксплуатации какой-либо уязвимости. Как и в случае с антивирусом или IPS, сигнатурного анализа уже давно недостаточно. В современном мире для приемлемого уровня детектирования атак мы просто обязаны использовать алгоритмы машинного обучения (далее ML, от англ. Machine Learning). И многие вендоры традиционных WAF естественно пытаются их применить и в своих решениях. Но иногда это весьма проблематично, т.к. ML алгоритмы требуют больших системных ресурсов и гораздо большего объема информации, чем может сгенерировать сам WAF. Поэтому часто функционал ML в традиционных WAF решениях является либо маркетинговым трюком, либо используется “не в полную силу” из-за ограниченности системных ресурсов.

6.3.2 WAAP Прежде, чем дать определение WAAP, давайте рассмотрим небольшой пример. Думаю не для кого не секрет, что веб-приложения могут располагаться не только в локальной серверной (или мини ЦОДе) компании, но и у облачных провайдеров, таких как AWS, Azure, Google Cloud (GCP) и т.д. Подавляющее большинство веб-сервисов, которыми вы пользуетесь, развернуто именно в публичных облаках. Этим пользуются многие компании. Можно долго рассуждать о плюсах и минусах использования публичных облаков, но для веб-приложений есть два ключевых преимущества: 1) Масштабируемость. Увеличить “мощность” веб-приложения проще простого. Можно в пару кликов развернуть дополнительные ресурсы или

85

вообще это автоматизировать. А если нагрузка спала, то также просто уменьшить количество этих ресурсов и экономить на инфраструктуре. На мой взгляд, возможность быстро “разворачиваться” и также быстро “сворачивать” - одно из ключевых преимуществ облака. В своей серверной так не получится. Может потребоваться покупка нового сервера, что НЕ быстро. А при спадающей нагрузке этот сервер будет простаивать, хотя деньги на него уже были потрачены. 2) Отказоустойчивость. Любое важное веб-приложение должно работать 24 часа в сутки и 365 дней в году, с минимально возможными простоями. Достичь этого в облаке гораздо проще, т.к. отказоустойчивость (а иногда и катастрофоустойчивость) там заложена изначально. Бесперебойный Интернет, электропитание, надежная система охлаждения серверов, непрерывный мониторинг, автоматическое восстановление и т.д. И самое главное - наличие независимых зон доступности. По сути, вы можете в рамках одного облачного провайдера использовать несколько независимых серверных и для вас это будет совершенно прозрачно. Нам сейчас интересен именно второй пункт - отказоустойчивость. Давайте рассмотрим самый простой пример, на картинке ниже:

Как видно из картинки, здесь одно и то же веб-приложение (копии) разворачивается в публичном облаке, в трех разных зонах. Запросы пользователя попадают на сетевой балансировщик, который распределяет их между тремя копиями одного и того же приложения. Это сильно упрощенный пример (мы не рассматриваем контейнеры или Kubernetes), но он отражает суть. Таким образом мы получаем:

86

-

Распределение нагрузки, что увеличивает доступность и производительность веб-приложения. - Отказоустойчивость. Если будет проблема в одной зоне, то две других продолжат работать и пользователь ничего не заметит. Как говорится “одним выстрелом двух зайцев”. Но что здесь делать с безопасностью? Конечно мы можем развернуть виртуальный WAF и все запросы “завернуть” через него. А если он откажет? У нас отвалятся все три зоны. Т.е. мы получаем единую точку отказа. Для большинства это недопустимо. Логично напрашивается вариант, когда мы разворачиваем WAF в КАЖДОЙ зоне. А если этих зон больше? А если мы еще и разные облака используем? А если нам иногда нужно уменьшать количество зон, а потом вновь увеличивать? Первый жирный минус использования традиционного WAF в такой схеме - стоимость. Это будет банально дорого. Но даже если мы готовы с этим смириться, то есть еще одна важная проблема - настройка WAF. В нашем примере мы получим три независимых друг от друга WAF, настройка которых должна быть идентична. Каждое малейшее изменение нужно будет повторять для каждой зоны. А если сюда наложить еще то, что у нас могут динамически меняться количество зон, количество веб-приложений (иногда несколько раз за день), то это превращается в сущий ад для администратора. Было очевидно, что нужно другое решение для защиты облачных веб-приложений, которое быстрее разворачивается (желательно автоматически) и моментально настраивается (автоматически или с минимальными настройками). Решение появилось довольно быстро - Web Application and API Protection (далее WAAP). Давайте рассмотрим его ключевые отличия от классического WAF, по возможности откинув маркетинг. Архитектурная особенность WAAP создавался в первую очередь для защиты облачных веб-приложений и API сервисов. При этом не важно, где находится инфраструктура - в коммерческом облаке (AWS, Azure, GCP) или в локальном (виртуальные машины, контейнеры, Kubernetes). Главный смысл в том, что веб-сервисы могут быстро создаваться, изменяться, мигрировать и удаляться. При этом надо обеспечивать нужный уровень безопасности. Достигнуто это вполне очевидным способом - разделением решения на две сущности: 1. Фильтрующая нода. Виртуальная машина или контейнер, который проксирует все запросы пользователей. Т.е. через эту сущность идет веб-трафик. Обычно нода выполняет следующие функции: - Анализирует весь проходящий трафик (до L7 уровня); - Блокирует вредоносные запросы и пропускает легитимные; - Собирает нужные метрики трафика и передает их на Сервер управления;

87

-

Загружает правила или политику обработки трафика с Сервера управления. С точки зрения управления Фильтрующая нода максимально “тупая”, т.к. все настройки хранятся на Сервере. Это позволяет максимально быстро и практически в любом количестве разворачивать эти ноды (автоматически). Все что нам нужно - подключить их к Серверу управления, что тоже можно автоматизировать. 2. Сервер управления. “Мозг” всего решения. Как правило “управлялка” предоставляется как сервис в облаке, т.е. SaaS. У клиента есть личный кабинет, где он: - Подключает фильтрующие ноды (если это не было сделано автоматически); - Выполняет централизованную настройку этих нод; - Создает и применяет политику; - Видит всю телеметрию и логи с фильтрующих нод. Количество фильтрующих нод теперь не имеет значение. Управлять сотней нод также просто, как и одной. Однако, бывают решения, которые позволяют разворачивать Сервер управления в собственной инфраструктуре компаний. Но это весьма редко. Если вернуться к нашему примеру с тремя зонами, то защищенный вариант с помощью WAF будет выглядеть следующим образом:

88

Фильтрующая нода разворачивается перед веб-приложением в каждой зоне, а управление, применение политик и сбор телеметрии осуществляется единой облачной “управлялкой”. Ресурсная особенность Т.к. Сервер управления предоставляется как сервис, то мы вообще не ограничены в системных ресурсах. Обработка/анализ логов и телеметрии с фильтрующих нод осуществляется в облаке вендора. Это позволяет ему применять наиболее современные алгоритмы ML или даже AI (искусственный интеллект, от англ. Artificial Intelligence). Это значительно повышает уровень детектирования атак и уменьшает необходимость ручной настройки фильтрующих правил. WAAP пропагандирует подход “включил и забыл”. ML и AI должны все сделать за вас. На практике это конечно же не так, но ручного труда администратора действительно значительно меньше, в сравнении с классическим WAF. Как уже писал выше, фильтрующие ноды в этой архитектуре максимально “тупые”, т.к. от них не требуется какая-либо аналитика или машинное обучение. Это существенно снижает потребность в системных ресурсах для таких нод. В зависимости от вендора, системные параметры могут быть ниже чем 2-4 vCPU, 1-4 Гб RAM и 5-50 Гб HDD. Сравните с минимальными требования классического WAF, которые привели выше. Если вы используете публичное облако, то WAAP поможет существенно сэкономить на оплате арендуемых мощностей облака. Функциональная особенность В самом определении WAAP заложено еще одно важное отличие - “API Protection”. Мы уже много раз упоминали этот термин в книге, но давайте попробуем коротко его объяснить. API (Application Programming Interface) - это некий посредник между приложениями (клиентская часть) и серверами. Существует огромное количество серверов, которые написаны на разных языках программирования, имеют разную архитектуру и логику работы. Все это еще усложняется тем, что один сервер могут использовать разные приложения, также написанные на разных языках, разными командами. Было бы очень трудно “объяснять” каждому приложению, как функционирует тот или иной сервер. Для этого и был придуман API, как некий стандарт обращения к серверу за нужной информацией или нужной функцией. А в качестве протокола передачи данных чаще всего используется старый добрый HTTP/S. Если взять жизненный пример, то API можно сравнить с официантом, который принимает заказы посетителей (пользователь и его приложение) и передает их на кухню (сервер). Чтобы сделать заказ посетителю не надо знать рецепт этого блюда и как его готовят. Достаточно обратиться к официанту. 89

На сколько важен API в современном мире? Согласно отчету Akamai за 2019 год более 83% всего HTTP трафика это именно API запросы. API используется почти везде, где есть клиент-серверная архитектура. В веб-приложениях, в мобильных приложениях и т.д. Это настолько обширная и популярная тема, что OWASP даже выпустил отдельный рейтинг по проблемам безопасности API (OWASP API Security Top 10). Как тогда обеспечить безопасность API? С помощью WAAP решений, которые могут проксировать все запросы и проверять их легитимность. Это одна из ключевых функций, которая была заложена изначально. Стоит отметить, что многие классические WAF уже тоже обзавелись функцией защиты API, которая изначально полностью отсутствовала. Если не вдаваться в остальные детали и резюмировать преимущества WAAP, то можно выделить следующее: 1. Архитектура, которая больше подходит для облачных сред, за счет разделения на Фильтрующую ноду и Сервер управления. 2. Использование более современных ML и AI алгоритмов, за счет обработки телеметрии трафика в облаке. 3. Изначально заложенная защита API. Из описанного выше может показаться, что WAAP однозначно лучше, чем WAF. И это будет ошибка. У каждого решения есть свои достоинства и недостатки. Для многих компаний является неприемлемой отправка даже телеметрии трафика в какое-то внешнее облако, по этой причине они выбирают классический WAF. А еще из описания WAAP может показаться, что его используют ТОЛЬКО в облаках, что тоже будет ошибкой. Фильтрующая нода в виде виртуальной машины или контейнера может легко разворачиваться и в локальной серверной заказчика, как правило в DMZ. О типовом дизайне мы поговорим буквально в следующем параграфе.

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

90

В нашем примере, трафик вашего веб-приложения “заворачивается” в облако F5, где происходит весь анализ и уже очищенный трафик направляется к вашему веб-приложению, которое может быть расположено как локальной инфраструктуре (через VPN), так и в публичных облаках (AWS, Azure, GCP и т.д.). Это максимально быстрый вариант внедрения WAF, который ограничивается лишь правкой DNS записей. Как правило такой Cloud WAAP предоставляют облачные CDN операторы, которые могут аккумулировать и фильтровать гигантские объемы трафика. Подробное рассмотрение Cloud WAAP выходит за рамки нашей книги, т.к. в большинстве случаев это зарубежные решения, которые сейчас недоступны российским компаниям.

6.3.4 NGFW с модулем WAF Мы уже говорили о том, что WAF это не NGFW и они не заменяют друг друга. Так же мы проговорили, что функционал WAF довольно требователен к системным ресурсам и именно поэтому большинство вендоров NGFW не включают эту функцию на своем решении. Но все же есть несколько NGFW производителей, которые позволяют использовать WAF в рамках единой платформы. Наиболее заметные игроки - Sophos и Sangfor (продается в России). Примечательно, что оба вендора изначально позиционировались как решение для SMB и Medium клиентов, т.е. небольшой бизнес, где ограничен штат администраторов или ИБ специалистов. Практически во всех WAF тестах оба вендора (Sophos и Sangfor) уступают специализированным решениям, которые будут рассмотрены далее. Именно поэтому модуль WAF в составе NGFW не пользуется популярностью.

6.4 Типовой дизайн сети с WAF Ранее, мы уже рассмотрели логическую схему применения WAF. Теперь попробуем отобразить это на структурной схеме все той же типовой архитектуры корпоративной сети. Получается следующая картина:

91

Как видно из картинки и как мы уже много раз говорили, WAF устанавливается в непосредственной близости к веб-сервису и проксирует все внешние запросы. Вообще говоря, почти каждый WAF имеет как минимум два основных режима работы: 1. Reverse Proxy Mode. Самый распространенный вариант, когда WAF полностью проксирует на себе все внешние запросы, в том числе раскрывает https трафик. Данный режим имеет наибольшую функциональность с точки зрения проверки трафика и является рекомендуемым. 2. Bridge Mode. Все запросы идут через WAF в прозрачном режиме, без непосредственного терминирования сессий. Является менее

92

рекомендуемым режимом работы, т.к. обеспечивает меньше функций безопасности. Т.к. WAF является публичным ресурсом, он обязательно должен располагаться в DMZ сегменте, а трафик до него должен предварительно проходить через NGFW, чтобы отсечь атаки на сетевом уровне или попытку эксплуатации уязвимостей на самом WAF (а такое случается!). После WAF трафик поступает на защищаемый веб-сервис, поэтому его также лучше располагать в DMZ сегменте, т.к. WAF не дает 100% гарантии защиты от взлома. В случае успешной компрометации веб-сервиса, злоумышленник не сможет быстро распространить атаку на внутренние сервисы, т.к. ему придется “пройти” через NGFW. Это яркая демонстрация эшелонированной защиты. Сам WAF, как уже упоминалось, может быть в виде ПАКа или же виртуальной машины. Если резюмировать по дизайну, то получим следующие тезисы: - WAF “прячется” за NGFW; - WAF располагается в DMZ; - Рекомендуемый режим работы WAF - reverse proxy mode; - Веб-сервис “прячется” за WAF, но также в DMZ. Напомню, что в этой схеме может использоваться не только классический WAF, но и WAAP. Разница здесь будет только в том, что управлять своим WAAP вы будете из облачного Сервера управления. Дизайн сети в публичных облаках выходит за рамки данной книги.

6.5 Ключевые игроки рынка Обзор мирового рынка мы как всегда начнем с рейтинга Gartner. Самый “свежий” рейтинг, который мне удалось найти на момент написания главы это отчет за август 2022 года и он включает в себя только Cloud Web Application and API Protection решения. Вообще, согласно Gartner, только Cloud WAAP способен обеспечить приемлемый уровень защиты в современном мире, особенно если учесть необходимость борьбы с ботами и DDoS атаками. Могу согласиться только относительно аргумента с DDoS, т.к. для эффективной очистки трафика требуется распределенная сеть вендора (как правило CDN оператора). В остальном же обычный WAAP ничем не уступает, а зачастую является просто частью Cloud WAAP. Рейтинг на картинке ниже:

93

Согласно Gartner лидирующие позиции занимает Cloudflare, Akamai и Imperva. Есть и другой рейтинг - G2 Grid for Web Application Firewall. Отчет за 2023 год представлен на картинке ниже:

Здесь уже среди лидеров значатся AWS WAF, Azure WAF, Azure Application Gateway, Imperva WAF, Cloudflare и Symantec WAF.

94

Если говорить о зарубежных решениях в рамках Российского рынка, то в нашей стране, до введения санкций, были очень популярны такие решения как FortiWeb, Wallarm, Cloudflare, F5, Barracuda WAF. На текущий момент ни один из этих вендоров не работает в России. Поэтому сразу перейдем к знакомству с отечественным рынком.

6.6 Отечественный рынок Как было обозначено выше, одними из самых популярных WAF в России (до введения санкций) были Imperva, FortiWeb, Wallarm, Cloudflare, F5, Barracuda WAF и т.д. Как и с предыдущими классами средств защиты, рынок сильно изменился и многие отечественные решения получили второе дыхание. Рассмотрим наиболее заметных игроков.

6.6.1 PTAF Positive Technologies Application Firewall (PTAF) - классический WAF от лидирующей ИБ компании России. Это в принципе один из первых отечественных WAF, разработка которого ведется уже ни один год. Продукт является весьма зрелым (разрабатывается с 2013 года) и занимает лидирующие позиции на российском рынке. В 2016 году PTAF даже попал в квадрант Gartner по решениям WAF. Поставляется как в виде виртуальной машины или в виде ПАКа. Ключевыми преимуществами решения являются: - Глубокая экспертиза вендора. - Богатая экосистема. PTAF может нативно интегрироваться с решением по анализу кода (PTAI), с системой автоматического пентеста (PT BlackBox) и “песочницей” (PT Sandbox). Этим не может похвастаться ни один из конкурентов. - Присутствует в маркетплейсе Yandex Cloud, что ускоряет развертывание виртуальной машины в облаке (это просто виртуальная машина в облаке, не путать с WAAP). - Имеется ФСТЭК сертификат. На текущий момент есть только классический WAF, который лицензируется по количеству запросов в секунду (RPS). По слухам, ведется разработка WAAP варианта.

6.6.2 WebmonitorX Отечественный вендор WAAP решения, которое появился совсем недавно. На самом деле, это ни что иное, как “форк” (копия исходного кода с дополнительными доработками) всеми известного решения Wallarm, который разрабатывался с 2013 года российской компанией “Онсек” (ONsec). Wallarm

95

является одним из лидирующих мировых решений в сегменте WAAP. Штаб-квартира на текущий момент находится в Сан-Франциско и бизнес в большей степени нацелен на западный рынок. После введения санкций в 2022 году появились юридические и репутационные проблемы с продажей Wallarm в России (несмотря на российское происхождение). Так и появился WebmonitorX, который дублирует функционал Wallarm и нацелен на продажи исключительно в России. Если честно, я даже не знаю на сколько это публичная информация. “Пишу вам по секрету…” Ключевые особенности: - WebmonitorX предоставляет Сервер управления исключительно в российских облаках (Yandex Cloud). - Фильтрующая нода может разворачиваться как виртуальная машина или контейнер. Присутствует в маркетплейсе Yandex Cloud (Валарм WAF). - Есть бесплатный триальный режим на 15 дней. - Из интересных “киллер фич” - наличие встроенного облачного сканера уязвимостей вашего веб-приложения или API-сервиса. - Как и любое WAAP решение лицензируется по количеству запросов в месяц или год (начиная от 15 млн запросов в месяц), независимо от количество фильтрующих нод. - Несмотря на то, что это WAAP, есть возможность развертывания Сервера управления (вычислительный кластер в терминологии WebmonitorX) в локальной инфраструктуре. Доступно только для очень больших инсталляций. “Фишка” российского рынка. Среди клиентов Wallarm такие компании как Тинькофф, Юлмарт, HeadHunter, QIWI и многие другие.

6.6.3 SolidWall WAF Классический WAF от российской компании “СолидСофт”. Первый релиз SolidWall WAF вышел в 2016 году. В решении делается упор на машинное обучение (ML). Поставляется в основном в виде виртуальной машины или ПАКа. Отличительные особенности решения: - SolidWall WAF можно назвать гибридным решением, т.к. существует вариант распределенной установки: Сервер управления и Узел анализа. Пример на картинке ниже:

96

Несмотря на архитектуру SolidWall не является WAAP решением в чистом виде. - Имеется сертификат ФСТЭК. - Присутствует в маркетплейсе Yandex Cloud. - Имеет партнерство с распределенным облачным провайдером NGENIX (CDN провайдер), который занимается ускорением доступа к веб-приложениям. Это позволяет использовать SolidWall WAF как сервис, без необходимости установки фильтрующих нод в своей инфраструктуре. - Аналогичная нативная интеграция с провайдерами Anti-DDoS решений QRator и StormWall. - Последние два пункта позволяют считать SolidWall решением класса Cloud WAF (не WAAP!), который предоставляется как сервис (SaaS). Среди клиентов SolidWall WAF такие компании, как М.Видео-Эльдорадо, FixPrice, Экспресс Банк и т.д.

6.6.4 Nemesida WAF Отечественный WAF от одной из самых известных пентест компаний (тест на проникновение) России - Pentestit. Ключевые особенности: - Одно из самых бюджетных решений на рынке (от 250 тысяч рублей). - Есть собственный сканер уязвимостей веб-приложений (отдельный модуль). - Есть бесплатная Community версия - Nemesida WAF Free (без модуля машинного обучения). - Присутствует в маркетплейсе Yandex Cloud. Nemesida WAF относится к классическим WAF, несмотря на активное использование ML и возможность разделения на Сервер управления и Фильтрующую ноду. Весь анализ и вычисления осуществляются в инфраструктуре компании (или их виртуальной машины в облаке). Поставляется в виде программного обеспечения - образ, контейнер или дополнительный модуль для веб-сервера Nginx.

97

6.6.5 Континент WAF WAF от компании “Код Безопасности”, который создан в партнерстве с уже описанным продуктом SolidWall WAF и развернутый на платформах шлюзов Континент. Практически полностью повторяет функционал SolidWall WAF. Естественно имеется сертификат ФСТЭК. Поставляется в виде ПАКов или виртуальных машин.

6.6.6 Check Point AppSec Первый зарубежный вендор в нашем списке из “дружественной страны” Израиль от лидирующего ИБ вендора в мире - CloudGuard AppSec. Это полноценное WAAP решение появилось в портфеле Check Point после покупки израильского стартапа ForceNock в начале 2019 года. Сам продукт был основан в 2017 году. Архитектурно очень схож с подходом Wallarm. Может разворачиваться как виртуальная машина, как docker контейнер, как модуль (addon) для NGINX или как Ingress в рамках Kubernetes:

Из ключевых особенностей: - Сервер управления находится в облаке Check Point (Infinity Portal), в зарубежных дата-центрах (Европа, США, Индия). - Как любой WAAP, лицензируется по количеству запросов, начиная от 100 млн запросов в год (до 100 фильтрующих нод). - Интегрируется в экосистему Check Point - Infinity Portal. Это позволяет централизованно администрировать все продукты Check Point, включая NGFW, EDR и т.д. Возможно использование единой системы анализа событий безопасности (в рамках Infinity Portal).

98

-

В решении делается упор на ML и AI алгоритмы, которые позволяют автоматизировать настройку WAAP, с минимальными трудозатратами администратора. - AppSec интегрирован с Check Point Threat Cloud, что позволяет использовать репутационные фильтры без необходимости покупки дополнительных “фидов”. - Имеется бесплатная версия Open-AppSec. Решение активно набирало популярность в России, до событий 2022 года. На текущий момент многие заказчики либо не могут продлить/приобрести решение (из-за санкций), либо опасаются возможных проблем в будущем, в частности доступность зарубежных сервисов в России, т.к. Check Point в большинстве случаев использует западные “облака”. Проблема частично решается использованием дата-центров Индии.

6.7 Бесплатные решения Как и Email Security, рынок WAF изобилует наличием бесплатных решений, причем даже при поддержке известных ИБ производителей. Естественно мы не сможем перечислить все проекты, но я попытался обозначить наиболее интересные и заметные, учитывая специфику нашего рынка. 1. ModSecurity WAF - один из самых известных и популярных WAF для таких веб-серверов как Apache, NGINX, IIS и т.д. Был разработан в далеком 2003 году. В большинстве случаев используется в режиме reverse proxy. Обеспечивает только сигнатурный анализ. 2. Nemesida WAF Free - бесплатная версия коммерческого продукта с главным отличием - отсутствие модуля ML. Несколько преимуществ перед ModSecurity: - Возможность использования собственных сигнатур. - Возможность “прикрутить” антивирусный модуль ClamAV. - Возможность использования графического интерфейса. 3. Open-AppSec - open source версия Check Point Cloud Guard AppSec. Одно из немногих WAAP решений, которое имеет ML модуль в бесплатной версии. Отсутствуют “фиды” Threat Cloud, антивирусный модуль, автоматическое обновление IPS сигнатур и т.д. С полным перечнем различий можно ознакомиться здесь. В целом, довольно интересное и полезное решение, которое, как минимум, позволит выстроить правильную защищенную архитектуру веб-приложений. Как и всегда, бесплатные и коммерческие решения отличаются количеством защитных механизмов, скоростью обновления сигнатур и репутационных баз. Естественно, что бесплатное решение будет обеспечивать более низкий уровень предотвращения. Но при ограниченном бюджете это

99

“лучше, чем ничего” и позволяет хотя бы выстроить ИБ процесс и сформировать правильную защищенную архитектуру.

6.8 Ключевые проблемы WAF Мы обсудили архитектурные различия WAF и WAAP, рассмотрели типовые угрозы для веб-приложений (OWASP Top 10) и познакомились с ключевыми игроками рынка, в том числе с бесплатными решениями. Независимо от продукта или класса, у любого WAF есть две ключевые проблемы. И качество WAF определяется в первую очередь тем, как продукт справляется с этими проблемами: 1. True Positive Rate - уровень блокировки реальных угроз. На сколько WAF способен справляться со всеми типами атак, в том числе новыми, ранее неизвестными (так называемые Zero Day - атаки или уязвимости нулевого дня). Разные вендоры по разному достигают высокого уровня блокировок реальных угроз. Кто-то по прежнему рассчитывает на сигнатуры и свою экспертизу, кто-то полностью надеется на ML и AI алгоритмы, кто-то совмещает все вместе и даже подключает дополнительные средства, например “песочницу”, которую мы обсудим в следующей главе. 2. False Positive Rate - уровень блокирования ложных угроз. На сколько адекватно WAF определяет угрозы, чтобы НЕ блокировать легитимный пользовательский трафик. Данные параметр, на мой взгляд, еще критичнее, чем True Positive, т.к. частые ложные срабатывания могут негативно сказаться на пользователях, которые работают с вашим веб-приложением. А это, в свою очередь, может повлечь к прямым финансовым или репутационным потерям. Получается, что производитель WAF решений должен всегда балансировать между максимальной безопасностью и комфортом пользователей при работе с веб-приложениями. Это почти всегда оказывается весьма трудно и после внедрения WAF почти всегда требуется какое-то время на устранение ложных срабатываний. Субъективно, с решениями, которые работают на основе ML и AI, данная процедура проходит чуть быстрее. Также стоит отметить, что сложность внедрения WAF напрямую зависит от сложности защищаемого веб-приложения. Подавляющее большинство внедрений начинаются с режима Detect, без блокировки даже реальных атак. Это позволяет изучить все события безопасности и выявить ложные срабатывания заранее. Лишь после этого WAF переводят в режим Prevent, т.е. предотвращения атак и блокировки НЕлегитимного трафика.

100

6.9 Резюме по WAF ● NGFW не заменяет WAF, также как WAF не может заменить NGFW. Это дополняющие друг друга модули безопасности периметра сети. ● Ключевые угрозы для веб-приложений обозначены в OWASP Top 10. ● WAF можно разбить на два больших класса: традиционный WAF и WAAP. ● Отличительная особенность WAAP - разделение на Сервер управления и Фильтрующую ноду. Возможность автоматизировать развертывание и настройку. Более актуально для облачных веб-приложений, где ресурсы очень динамичны. ● WAF устанавливается как можно ближе к веб-приложению (в DMZ) и “прячется” за NGFW. ● Наиболее заметные игроки российского рынка: PTAF, WebmonitorX (Wallarm), SolidWall WAF, Nemesida WAF, Континент WAF (он же SolidWall) и Check Point AppSec.

101

7. Sandbox Мы подошли к заключительному классу решений в данной книге - Sandbox (с английского - песочница). По ходу книги мы уже не раз упоминали это понятие, причем как в главе про NGFW, так и в Email Security, и в WAF. Я поместил этот класс в конец книги и это неспроста, т.к. песочницы (далее уже без кавычек), должны внедряться на периметре в последнюю очередь (хотя песочницы могут использоваться не только на периметре!). Почему так? Разберемся буквально в следующих параграфах. Давайте начнем с определения. Можно привести кучу формулировок, особенно если учесть тот факт, что понятие Sandbox существует не только в сфере кибербезопасности, но и в программировании, и в играх, и в электронике и даже в таких естественных науках как химия, биология, физика и т.д. Если отбросить специфику каждой из областей, то определение песочницы сводится к максимально простому понятию - изолированная и безопасная среда тестирования. Такое определение лучше всего передает главную суть выделенное место, где можно “поиграться” с тем, что может нанести вред. Если вернуться к специфике кибербезопасности, то песочница это специально выделенная среда, где можно запустить подозрительные файлы или открыть подозрительные ссылки, а затем посмотреть, что же случится. Сам концепт песочниц зародился очень давно. Есть множество примеров, но мы рассмотрим наш традиционный - крепость. Давайте вспомним историю с жителем, который: 1. Отправился в другой город с тележкой для товаров (пользователь инициирует подключение к веб-сайту по протоколу HTTPS); 2. Охрана проверила документы, узнала куда он собирается и разрешила выйти с телегой (NGFW идентифицировал пользователя, проверил разрешающие правила, как по url, так и по приложению); 3. Житель закупился товарами, в том числе продуктами, сложил все в сундук, закрыл на замок и вернулся в крепость (пользователь инициировал скачивание файла по шифрованному каналу - HTTPS); 4. Охрана остановила жителя с телегой, снова проверила все документы и заставила открыть сундук с товарами и овощами (NGFW убедился, что это трафик существующей сессии и выполнил HTTPS инспекцию, для проверки шифрованного соединения); 5. Охрана внимательно проверила, откуда товар (url фильтрация), безопасна ли телега и лошадь (IPS) и нет ли запрещенных товаров в сундуке согласно их “ориентировкам” (потоковый антивирус проверяет скачиваемые файлы сигнатурным анализом); 6. Ничего запрещенного не нашли, жителя впускают в крепость с товарами (NGFW разрешает пользователю скачать файл). 102

Вроде все логично, все проверки пройдены. Безопасны ли овощи, которые привез житель? Огурцы, картошка, помидоры. Такое разрешено. Запрещенных товаров (сигнатуры) вроде мухоморов, волчьей ягоды или бледной поганки найдено не было. Остался ли риск? Безусловно. Разрешенные овощи могут быть отравлены и по внешнему виду вы этого никак не узнаете. Не узнаете, пока кто-то не попробует. А вдруг эти продукты или напитки предназначены для Короля? Решение было найдено довольно быстро - появились дегустаторы, которые пробовали любые продукты и напитки перед тем, как они подавались Королю. Это один из первых примеров “песочницы”, когда пища “безопасно” тестировалась на других специальных людях (как бы кощунственно это не звучало). Если овощ или напиток был отправлен, это сразу замечали на тех, кто дегустировал, а Король оставался в безопасности. Это сильно упрощенный пример, но отражает суть. В кибербезопасности песочница исторически начала использоваться у вирусных аналитиков, которые изучали различные зловреды. Им требовалась безопасная среда, где можно было бы запустить образец (сэмпл) вируса, посмотреть на его активность, действия и на основе этого создать сигнатуру для традиционных средств, таких как IPS или Antivirus. Т.е. “сигнатура” простыми словами это выявления некой характерной черты или свойства. Это может быть частью трафика (последовательность пакетов определенного типа) или же частью файла (фрагмент кода, текста или последовательность бит). Сигнатура вируса это практически синоним успешной атаки. Где-то произошел инцидент - кибер аналитики изучили вирус, сформировали сигнатуру и распространили ее как обновление базы. С этого момента конкретный экземпляр вируса (или семейство вирусов) стал известен. Такая модель “вирус-сигнатура-блокировка” существовала довольно долго и вроде бы всех устраивала. Но это до поры до времени. Главный вопрос - что делать с первыми атаками, когда нужная сигнатура еще не сформирована? Такие атаки (вирусами или эксплойтами, которых еще никто не “видел”) стали часто применять против конкретных компаний, чтобы обойти традиционные сигнатурные средства защиты. Назвали эти атаки “таргетированными” или “целенаправленными”. В их основе лежит использование ранее неизвестных уязвимостей в операционной системе или программном обеспечении - те самые Zero Day (уязвимости нулевого дня). Невозможно создать сигнатуру для угрозы, про которую ты ничего не знаешь. Очень долго считалось, что угроза Zero Day актуальна только для больших корпораций. Поиск новой уязвимости и разработка нового вируса стоили довольно дорого, поэтому к ней прибегали только в крайних случаях. Для массового рынка гораздо проще использовать уже известный вирус и лишь слегка его модифицировать.

103

Но технологии не стоят на месте. Методы создания новых вирусов или модификации существующих стали гораздо проще и доступнее даже для начинающих хакеров. Понятие “таргетированной атаки” уже не так актуально, т.к. Zero Day уязвимости используются практически везде. Шанс “поймать” новый вирус одинаков как для кофейни в вашем дворе, так и для международной компании со штатом в десятки тысяч человек. На этом фоне, начиная с 2010-х годов песочницу стали продвигать на массовый рынок корпоративного сегмента, как единственно возможное средство защиты от таргетированных атак. И отчасти это правда. Ничего умнее ИБ специалисты пока не придумали. Есть подозрительный файл, который пришел по почте или пользователь скачивает с какого-то сайта? Можно взять и просто запустить его в изолированной среде (обычно виртуальной машине), а потом посмотреть, что же произойдет. Такая процедура называется эмуляцией. Это в прямом смысле детонация вируса. Пусть он неизвестен, но после его запуска будет очевидно (на самом деле не всегда), что он наносит вред. Сигнатурными методами этого не добиться. Тут сразу стоит сделать акцент на том, что решения класса Sandbox это не панацея и не исключает использования традиционных механизмов защиты. Песочница это, как правило, последний рубеж защиты и используется только тогда, когда все другие классические (сигнатурные) средства ничего не выявили. Почему так? Для запуска потенциально зловредных файлов требуется изолированная среда - виртуальная машина с операционной системой и набором нужного программного обеспечения (MS Word, Adobe и т.д.). Если у вас много файлов на проверку, то требуется много таких виртуальных машин. “Песочить” (т.е. запускать в изолированной среде) файлы это очень ресурсоемкая задача. Если мы будем проверять в песочнице все подряд, то нам потребуются гигантские ресурсы, что весьма и весьма дорого. Именно поэтому на периметре должны быть инструменты, которые сначала позволяют: 1. Максимально уменьшить площадь атаки. NGFW определяет разрешенные ресурсы и приложения, Email Security отбрасывает весь СПАМ, WAF определяет разрешенные запросы к вашему веб-приложению. 2. Проверить уже разрешенный трафик традиционными механизмами. IPS, Anti-Virus, Anti-Bot - в большинстве случаев это стандартный сигнатурный анализ, который позволяет быстро, надежно и с минимальными ресурсными затратами заблокировать все известные зловреды. Уже после того, как отработали традиционные инструменты мы можем подключать “тяжелую артиллерию” - песочницы. И вышеупомянутые NGFW, Email Security или WAF являются лишь источниками файлов для песочниц. Типовую схему сети мы рассмотрим чуть позже.

104

В следующих главах мы чуть подробнее рассмотрим технологии песочниц, архитектурные особенности и ключевых игроков рынка. От себя лишь могу добавить, что имел честь наблюдать за развитием этого класса решений с самого начала и прошел вместе с ними путь от “диковинки, которую покупают кому уже нечем заняться” до “обязательное средство для полноценной и комплексной защиты”. Это подтверждается различными аналитическими отчетами. На картинке ниже представлено исследование компании Reports and Data по объему рынка к 2026 году (прогноз).

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

7.1 Типы Sandbox и варианты интеграции Практически все современные песочницы, вне зависимости от вендора, можно разбить на два больших класса: 1. Локальные. Песочница устанавливается непосредственно в инфраструктуре заказчика и может быть развернута в виде виртуальной машины или в виде ПАКа (appliance). Некоторые вендора для локального варианта могут предоставлять только ПАКи (Check Point, к примеру, не предоставляет виртуальных машин). Как мы уже писали выше, песочницы весьма требовательны к ресурсам. Вот например минимальные требования для песочниц от компании Positive Technologies: - Минимальные требования: 16 vCPU, 32 ГБ RAM и 500 Гб HDD; - Рекомендуемые требования: 52 vCPU, 256 ГБ RAM и 8 Тб HDD. Если вы планируете использование виртуального варианта локальной песочницы, то ваша серверная инфраструктура должна быть готова к таким нагрузкам. В противном случае вы можете выбрать вариант ПАК,

105

который представляет из себя обычный мощный сервер с х86 процессором (чаще несколько процессоров). 2. Облачные. Песочница предоставляется как сервис (SaaS) в облаке вендора. Данный вариант является наиболее выгодным и с финансовой точки зрения, и с точки зрения скорости внедрения. Нет необходимости развертывания решения в собственной инфраструктуре, однако требуется бесперебойное подключение к сети Интернет, т.к. файлы будут отправляться на эмуляцию в облако, что дополнительно грузит каналы связи. Стоит отметить, что не у всех производителей песочниц есть облачный вариант. Особенно у отечественных. Некоторые это решают с помощью гибридного варианта, когда Партнер разворачивает обычную локальную песочницу на своих мощностях (или мощностях публичных облаков) и предоставляет доступ другим компаниям. Можно заметить, что у каждого типа есть свои достоинства и недостатки. Вариант с локальной песочницей является наиболее дорогим и чаще применяется там, где по политике безопасности есть запрет на отправку файлов в публичные облака. В сетях с закрытым контуром, т.е. без доступа в Интернет, также нет возможности использовать облачный вариант. Не менее важную роль в выборе песочницы и варианта исполнения играют возможности по интеграции. Для любой песочницы нужны источники, которые будут передавать файлы на эмуляцию. Ниже приведен список возможных и наиболее распространенных опций: 1. NGFW. Устройство на периметре, передает в песочницу файлы, которые скачиваются пользователями. Технологии передачи могут быть разными. Это может быть стандартный ICAP, либо собственный проприетарный протокол, который требует, чтобы NGFW и песочница были от одного вендора. 2. Email Security. Почтовый шлюз передает на эмуляцию файлы или ссылки из электронных писем. Протоколом передачи может быть стандартный SMTP (песочница становится участником почтового тракта), либо собственный проприетарный протокол, который требует, чтобы почтовый шлюз и песочница были от одного вендора. 3. EDR. Специальные агенты на рабочих станциях позволяющие отправлять файлы пользователей на эмуляцию в песочницу. Для подобной связки практически всегда используется проприетарный протокол, т.е. подразумевается использование одного вендора для EDR и песочницы. Подробное описание EDR выходит за рамки данной книги, но возможно будет рассмотрено в одной из следующих. 4. Сетевой сенсор. Если вспомнить наш фреймворк, то три основных уровня защиты это Perimeter, Network и Endpoint Layer. Связка NGFW/Email Security + Sandbox усиливает уровень периметра. Связка 106

EDR + Sandbox усиливает Endpoint Layer. А как же Network Layer? Там тоже необходима возможность обнаружения Zero Day угроз. Для решения этой задачи используется сетевой сенсор, на который заворачивается копия трафика, обычно с коммутаторов ядра. Этим сенсором может быть сама песочница, выделенный сенсор песочницы (виртуальный или аппаратный) или же решение класса NTA/NDR, подробное описание которого выходит за рамки нашей книги. Ключевой посыл, что анализировать трафик внутри сети (Запад-Восток) нужно как традиционными средствами (IPS), так и более современными, когда файлы из трафика передаются на анализ в песочницу, либо обрабатываются ML/AI алгоритмами. Стоит упомянуть, что иногда вместо обработки копии трафика, песочницу ставят в разрыв. Это весьма редкий сценарий. 5. API. Все современные песочницы поддерживают API. Теоретически, это позволяет интегрировать песочницу с чем угодно, было бы желание разработчиков. Любое программное обеспечение может иметь функционал отправки файлов на эмуляцию через API. Но требуется доработка самого ПО. Естественно, в зависимости от вендора, существуют и другие варианты интеграции песочниц. Но перечисленные выше являются минимально необходимыми опциями. Отмечу, что в последнее время также набирает популярность интеграции песочницы с: - WAF, что позволяет анализировать файлы, которые пользователи загружают в какое-то веб-приложение, защищаемое WAF-ом; - файловым хранилищем. Здесь песочница либо напрямую подключается к файловому серверу и проверяет все файлы, либо ставится в разрыв и проверяет протоколы передачи (smb, ftp и т.д.). Отдельным пунктом стоит отметить особенности подбора конкретной модели песочницы с учетом требуемой производительности - “сайзинг”. Пожалуй два ключевых фактора это: - Количество эмулируемых файлов в час. От этого зависит количество запускаемых одновременно виртуальных машин и соответственно производительность платформы. Проще всего эти цифры получить из пилотного проекта. - Количество и скорость портов (1, 10, 100 Гбит/с). Важная характеристика, если песочница используется и для анализа копии трафика со SPAN порта коммутатора ядра. Данный режим не является рекомендуемым. С выбором вендора песочницы все намного сложнее, т.к. требуется учитывать все вышеперечисленные факторы и особенности. Нужно продумать тип песочницы, вариант интеграции и самое главное - системы, которые будут отправлять файлы на анализ. В большинстве случаев выгоднее и технологичнее оказывается не конкретный продукт, а именно экосистема, где 107

несколько продуктов нативно интегрируются друг с другом. Наиболее заметных игроков рынка мы рассмотрим чуть позже.

7.2 Типовой дизайн сети с Sandbox Исторически, одни из первых средств защиты, которые стали интегрироваться с песочницей, были NGFW и Email Security. Но прогресс не стоит на месте и почти все ключевые ИБ решения уже поддерживают работу с песочницей, причем как с локальной, так и облачной. На примере ниже мы рассмотрим всё ту же типовую схему корпоративной сети, где изображены уже рассмотренные нами классы средств защиты, плюс парочка новых (EDR и NTA/NDR). Все они интегрируются с локальной песочницей, тем самым существенно повышая защищенность трех основных уровней защиты: Perimeter, Network и Endpoint Layer.

108

Как уже упоминалось выше, все эти решения могут в автоматическом режиме отправлять файлы на эмуляцию в песочницу. Протокол отправки файлов может быть каким-то стандартным (ICAP для NGFW, SMTP для Email Security), либо проприетарным, что требует использования одного вендора. К расположению самой песочницы в инфраструктуре нет особых требований. Все что нужно - обеспечить сетевую связность с устройствами, которые будут отправлять файлы на эмуляцию. Чаще всего песочница, как ПАК, устанавливается в локальном серверном сегменте, либо поднимается как виртуальная машина. Исключение составляет лишь тот случай, когда песочница используется и как сенсор для копии трафика. Мы не будем рассматривать применение облачной песочницы. С точки зрения сетевой топологии, все аналогично, с одной единственной разницей песочница предоставляется как сервис в облаке производителя.

7.3 Ключевые технологии песочниц Как мы уже обозначили выше, песочница использует виртуальные машины для детонации (т.е. эмуляции) файлов или гиперссылок. В случае ПАК-а на серверной платформе используется какой-то гипервизор (в подавляющем большинстве это бесплатный KVM), который запускает специально подготовленные виртуальные машины с предустановленным софтом, типа MS Office, Adobe Reader и т.д. В зависимости от качества песочницы могут запускаться разные типы операционных систем с разным набором софта: - Windows Server 2012/2016/2019… - Windows 7,8,10,11… - Linux (Ubuntu, Astra, CentOS)... - и т.д. Вид операционных систем и количество предустановленного софта напрямую влияет на количество типов поддерживаемых файлов, которые могут быть проанализированы в песочнице. К примеру, Check Point поддерживает более 80 типов файлов и вы сами можете определять, что эмулировать:

109

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

7.3.1 Типовая архитектура песочницы В простейшем случае архитектура любой песочницы выглядит следующим образом:

110

Все довольно прозрачно - поддерживаемые типы файлов отправляются в песочницу, где попадают в одну из виртуальных машин, где и происходит весь анализ. Эта картинка, кстати, из моего курса “Основы виртуализации” и если вы плохо разбираетесь в виртуализации, то крайне рекомендую к прохождению. Система, отправившая файл на анализ (ngfw, waf, edr, сетевой сенсор и т.д.) ждет вердикта от песочницы, на основе которого пропускает или блокирует этот файл.

7.3.2 Виды анализа Практически любая песочница поддерживает два типа анализа файлов и ссылок: 1. Статический анализ. Позволяет обнаружить вирусы с наименьшими ресурсными затратами. “Статика” обычно выполняет следующие действия: - объекты сканируются антивирусным ядром (т.е. сигнатурный анализ), иногда их может быть несколько. Такой механизм часто называют мультисканером. - распаковываются архивы, в том числе запароленные. Пароль может браться из собственной базы или же перехватываться из источника файла (например когда в письме прикладывают архив и пароль к нему). - отправка файлов во внешние аналитические и репутационные ресурсы (например можно запросить вердикт в virustotal). - более детальный анализ структуры и содержания файла (позволяет определить тип файла, даже если используется “подмена” расширения - pdf вместо exe). - некоторые песочницы на данном этапе могут применять ML/AI алгоритмы для определения вирусного содержимого. Эта функция хорошо помогает, когда злоумышленник использует так называемую обфускацию. Обфускация это “запутывание” или шифрование кода уже известного вируса, после чего он может выглядеть “нормальным” и не попадаться на сигнатурном анализе. 2. Динамический анализ. Непосредственный запуск файлов в песочнице с последующим мониторингом активности. Используется уже после статического анализа, с целью отфильтровать “простые” вирусы и снизить нагрузку на песочницу, т.к. эмуляция весьма затратна с точки зрения ресурсов. Что именно мониторится при динамическом анализе мы подробно рассмотрим в следующем параграфе.

111

7.3.3 Динамический анализ Если кратко описать предыдущую картинку, то песочница это обычный сервер с набором виртуальных машин, где запускаются потенциально вредоносные файлы. Но как песочница определяет, что файл вирусный? Для этого используется непрерывный мониторинг ключевых элементов после запуска файла: 1. Процессы. Любой вирус для работы должен либо создать новый процесс, либо изменить существующий, а иногда и остановить другой процесс (например антивирус). Песочница позволяет отслеживать эти активности и составлять подробное “дерево” процессов после запуска файла. Аномальная активность естественно будет свидетельствовать о вирусной природе файла. Эта же опция позволяет проводить последующее изучение зловреда и оценить возможную угрозу или последствия атаки. Для автоматического определения аномальности этих процессов естественно требуется высокая экспертиза от создателей песочницы. На картинке ниже представлен пример отрисовки дерева процессов в песочнице Kaspersky:

112

2. Сеть. Все более менее современные вирусы редко являются абсолютно самостоятельными. Для полноценной работы им может потребоваться связь с командным центром (C&C), где они могут получить команду к определенным действиям (ждать, шифровать, уничтожать и т.д.) или же “докачать” дополнительное ПО. Активный мониторинг всех сетевых соединений позволяет выявить все подозрительные активности. Согласитесь, весьма странно будет выглядеть создание нового сетевого подключения к китайским серверам при открытии обычного текстового файла. Песочница позволяет отслеживать все сетевые активности и осуществлять репутационную проверку ресурсов, к которым инициируется подключение. Естественно, для этого вендор должен иметь богатую репутационную базу, свою или же получаемую как фиды от партнеров. 3. Память. Для работы любого ПО, в том числе вирусного, требуется память - оперативная (RAM) и постоянная (HDD, SSD). Песочница активно мониторит любое создание файлов, как временных, так и постоянных. Любое изменение файлов на диске (создание, удаление, модификация) или в “оперативке” не останется незамеченным. Открытие PDF файла не должно приводить к удалению или изменению системных файлов. Песочница позволяет отслеживать подобные инциденты. Это также критически необходимо при последующем анализе и оценке угроз. 4. Реестр и системные настройки. Аналогично предыдущим пунктам, песочница может мониторить любые изменения системных настроек, которые могут повлечь за собой опасные последствия. Подобные изменения могут быть следствием попытки “закрепиться” в системе или же повышения привилегий. Для определения аномальной и вредоносной активности естественно требуется хорошая экспертиза вендора. Мы перечислили лишь наиболее важные компоненты мониторинга. Безусловно, современные песочницы осуществляют более сложный анализ гораздо большего количества параметров. Внимательный и подкованный читатель может сказать: “Антивирус же делает тоже самое? Каких-то реальных инноваций здесь не видно”. И отчасти будет прав. Классический антивирус тоже мониторит процессы, диск, реестр и все сетевые подключения. Но есть одна большая разница - антивирус не имеет права на ошибку. Он должен обнаружить вредоносную активность до того, как случится что-то плохое (потеря, изменение или удаление информации). Ведь исправить последствия не всегда возможно. Песочница лишена подобной проблемы, т.к. все действия происходят в изолированной среде, где нет никакой ценной информации. Более того, срабатывание вируса и есть главная задача. В этом случае его можно подробно изучить и уменьшить количество ложных срабатываний.

113

7.3.4 Техники обхода песочниц Злоумышленники прекрасно понимают, что песочницы гораздо точнее детектируют их вирусы, поэтому всячески пытаются их “обойти”. Для этих целей появились специальные “техники обхода” песочниц, которые стали активно применяться в современных вирусах для таргетированных атак. Ключевой смысл любой техники обхода - понять, что вирус находится в песочнице (виртуальной машине), а не на реальном компьютере пользователя. Поняв это, вирус может “затаиться”, т.е. не выполнять свою зловредную активность и ждать, когда песочница пропустит его. Лишь попав на реальный компьютер вирус активизируется. Давайте рассмотрим наиболее популярные техники обхода песочниц (по сути - техники выявления средств виртуализации): - Проверка запущенных процессов. Некоторые вирусы в принципе не запускаются, если в системе запущено менее 15 процессов, т.к. это в явном виде может свидетельствовать о том, что мы находимся в специально подготовленном образе, где для экономии ресурсов “вырезали” все лишнее. Плюс многие гипервизоры могут добавлять в виртуальную машину специальные процессы. Для VMware это vmtoolsd, для VirtualBox - vbox.exe. Обнаружив эти процессы вирус поймет, что он находится в песочнице и не будет себя выдавать какой-то зловредной активностью. - WMI-запросы. С помощью WMI-запросов можно получить огромное количество информации, например: температуру процессора, модель материнской платы, скорость вращения вентилятора, время работы системы и т.д. Если попытаться выполнить эти запросы в обычной виртуальной машине, а не на физическом ПК, то вы получите ошибку. Вирусы также используют эти методы для детектирования песочницы. - Проверка значений ключей реестра. Большинство средств виртуализации или программ анализа кода вносят некоторые изменения в ключи реестра. Вирусы умеют читать этот реестр и определять, что находятся в песочнице. - Проверка наличия особых файлов. Аналогично с реестром, песочница может оставлять “след” в виртуальной системе в виде особых файлов или дополнительных библиотек, которые используются для анализа кода и отладчиков. - Проверка системных параметров. Как вы помните, эмуляция это весьма ресурсоемкая задача. Многие производители пытаются оптимизировать образы виртуальных машин и выделять им как можно меньше ресурсов, чтобы их можно было запустить гораздо больше на том же сервере. Больше виртуальных машин, больше файлов можно проанализировать. В результате под виртуальную машину могут

114

выделять 1-2 vCPU, 1 Гб RAM и 15-20 Гб HDD. Если вирус обнаружит подобные параметры системы, то это однозначно идентифицирует песочницу, т.к. реальных ПК с такими параметрами уже давно не существует. - Проверка времени. Вирусы способны проверять не только актуальное время системы, но и время выполнения тех или иных задач. Производители песочниц давно стали использовать “перемотку времени”, т.к. некоторые вирусы использовали временную задержку, чтобы не запускаться сразу. Т.е. вы скачиваете файл, а он начинает зловредную активность лишь через неделю. Песочница может “перемотать” время на месяц или год вперед, чтобы попытаться сдетонировать вирус. Тот в свою очередь может увидеть подобный процесс и понять, что находится в виртуальной среде. Повторюсь, мы перечислили лишь малую часть существующих техник обхода, но уже по ним вы можете понять, на сколько серьезная задача стоит перед производителями песочниц, которые должны все это учитывать и разрабатывать противодействия этим техникам. Расставлять ловушки, подменять файлы, симулировать процессы, скрывать файлы и т.д. Все это похоже на непрерывную гонку вооружений. Злоумышленники постоянно создают новые техники или комбинируют уже известные. На картинке ниже представлена интересная инфографика от Positive Technologies, где показана эволюция методов обхода песочниц, которые были замечены у различных зловредов:

115

Из интересных техник обхода можно привести пример из категории “детектирование человека”. Вирус ожидает определенные действия при открытии файла, которые характерны исключительно для человека. Например на второй странице документа располагается картинка с голой женщиной (это пример реального вируса). Человек при просмотре подобного документа практически со 100% вероятностью задержится на этой странице. Песочница же обычно “проматывает” документы с одинаковой скоростью и, следовательно, “выдает” себя. Данный пример показывает, насколько сложно бороться с современными зловредами.

7.3.5 Очистка содержимого Если убрать всю маркетинговую “шелуху”, то можно понять, что песочницы тоже используют своего рода “сигнатуры”, но просто на другом уровне. Типовые процессы, типовые сетевые подключения, типовые действия с реестром и т.д. Песочница так или иначе все равно использует определенные шаблоны “нормального” и “ненормального” поведения. Эти шаблоны позволяют определять вирусы гораздо точнее и существенно усложняют жизнь злоумышленникам. Но все же это шаблоны… которые естественно можно обойти. А еще все мы помним, что ни одно средство защиты не может дать 100% гарантии защищенности. Даже песочница. Учитывая вывод предыдущего параграфа, появилась интересная идея “А что если взять и вырезать из файла все активное содержимое? Ссылки, макросы, скрипты и т.д.”. В этом случае не придется надеяться на антивирусный модуль или на динамический анализ песочницы. Вы берете документ и удаляете все, что может содержать зловредную активность, т.е. делаете его стерильным. Тут обычно есть два варианта: 1. Конвертация исходного файла в PDF. Самый надежный вариант. Вы фактически распечатываете документ на виртуальном принтере и получаете абсолютно стерильный файл. Исходник же не передается пользователю, либо предоставляется по запросу. 2. Удаление активного содержимого с сохранением формата файла. Можно удалить ссылки, скрипты, макросы из doc или xls. Очищенный файл будет по прежнему доступен к редактированию (в отличии от pdf). Стоит понимать, что эти технологии доступны в основном для текстовых файлов и естественно не применимы к исполняемым. Очистка активного содержимого в том числе используется для ускорения доставки файлов пользователю. Процесс эмуляции в песочнице может занимать длительное время - до нескольких минут. Все это время пользователь будет ждать оригинальный файл. Как альтернатива, ему может моментально отправляться очищенная версия файла, которой иногда вполне достаточно

116

(для текстовых документов). Если же ему потребуется оригинал, то он может запросить его после завершения эмуляции. Подобной технологией очистки активного содержимого обладают все более менее современные решения. Вот как это называются у разных вендоров: - Threat Extraction (Check Point); - Content disarm and reconstruction (Fortinet); - И т.д. Большинство вендоров рекомендуют совмещать эмуляцию и очистку активного содержимого для более надежной защиты и ускорения доставки файлов.

7.4 Ключевые игроки рынка Как и в любой сфере, среди песочниц тоже есть лидеры, законодатели “моды” и даже родоначальники сегмента в целом. Удивительно, но найти какие-то более менее “свежие” аналитические отчеты по песочницам оказалось не так уж просто. В большинстве случаев sandbox участвует как один из элементов тестируемых комплексов - например совместно с NGFW или с EDR. Почему так? Обсудим чуть позже. Давайте рассмотрим несколько доступных отчетов: 1. The Forrester Wave: Automated Malware Analysis, Q2 2016

117

Как следует из названия это отчет по системам автоматического анализа зловредов. Согласно рейтингу среди лидеров находятся такие вендоры как: - Palo Alto Networks; - Check Point; - Blue Coat; - FireEye; - Trend Micro; - Cyphort; - Lastline; - Intel Security. Если говорить о российском рынке, то до введения санкций особенной популярностью пользовались Check Point (Sandblast), Palo Alto (WildFire), Trend Micro (Deep Discovery), FireEye и Fortinet (Forti Sandbox). Все эти вендоры, на момент 2016 года, уже имели собственные песочницы. Что примечательно в этой рейтинге? Среди лидеров почти нет вендоров, которые весьма сильны в защите рабочих станций (endpoint). Тут нет ни Kaspersky, ни McAfee, ни Bitdefender. Все этого говорит о существенной разнице в технологиях детектирования вирусов. Сделать свою песочницу не так уж просто даже для лидирующих антивирусных компаний. 2. NSS Labs: Breach Detection Systems, 2017

118

Внизу картинки отражено тестируемое оборудование и их версия. Тут же вы можете сразу увидеть, что некоторые вендоры тестировались в комплексе, т.е. NGFW + Sandbox. Среди лидеров оказались: - Trend Micro; - Check Point; - Fortinet; - Palo Alto Networks; - Lastline.

119

Чем же примечателен этот график и вообще 2017 год для сегмента песочниц? FireEye “вывалился” из лидеров. Для понимания, FireEye в мире песочниц это как Palo Alto в мире NGFW. FireEye одни из первых начали разработку песочницы и в целом сформировали новый сегмент рынка в ИБ. Долгое время они были лидирующим решением и законодателем моды в плане технологий. В 2017 году уже все изменилось. В сегмент песочниц ворвались новые вендоры (Check Point, Fortinet, Palo Alto) с относительно молодыми решениями и сразу потеснили таких мастодонтов, как Lastline, FireEye и Trend Micro. И это было уже в 2017 году. Сейчас, в 2023 году, узкоспециализированные решения занимают унизительно маленькую долю рынка. Почему так? Объяснение довольно простое - песочница (или защита от таргетированных атак) стала всего лишь одной из функций, а не отдельным решением. Как это произошло когда-то с NGFW (все мы помним историю с UTM vs NGFW). Большинство рынка уже НЕ интересуют песочницы, как отдельный класс решений. Рынку интересна экосистема, предоставляющая комплексную защиту и нативную интеграцию нескольких решений (NGFW, Sandbox, EDR, NDR, SIEM и т.д.). Такая синергия в большинстве случаев позволяет добиться гораздо лучшего результата, как с технической, так и с финансовой точки зрения. В итоге выживают те вендора, которые быстрее адаптируются под условия и требования рынка. Точечные решения практически со 100% вероятностью становятся либо частью чей-то экосистемы (например Lastline был поглощен компанией VMware), либо стремительно теряют рынок, когда все вендоры принимают ту или иную функцию как новый стандарт, который должен быть у всех. FireEye были безусловными лидерами рынка. Как когда-то Cisco PIX, а потом и Cisco ASA царствовали в сегменте межсетевых экранов. И те и другие не успели адаптироваться под реалии рынка. Но это мое субъективное мнение. Т.к. большинство вендоров из списка лидеров мы уже рассматривали ранее, то не будем еще раз на них заострять внимание. Вместо этого более подробно рассмотрим отечественный сегмент и что сейчас доступно на нашем рынке.

7.5 Отечественный рынок Как и в случае с NGFW, российский сегмент песочниц тяжело пережил (и до сих пор переживает) санкционные ограничения. Как говорилось выше, наиболее популярными вендорами песочниц в России были: Check Point, Fortinet, Palo Alto, FireEye и Trend Micro. Наиболее сильны были позиции Check Point и Fortinet, т.к. обладали нужной экосистемой - NGFW + Sandbox + EDR. Нативная интеграция нескольких классов решений позволяла добиваться высочайшей

120

эффективности. Проще администрирование, выше общий уровень блокировки угроз, дешевле закупка и продление. И Fortinet, и Check Point, и Palo Alto обладают как локальным вариантом песочницы, так и облачным (NGFW и EDR посылают файлы на эмуляцию в облако). Облачный вариант делает доступным технологии песочниц даже для маленьких компаний с небольшими ИБ бюджетами. После введения санкций из зарубежных решений у нас остался только Check Point. Многие компании стали рассматривать отечественные решения как альтернативу ушедшим и первое, что большинство обнаружили российские производители NGFW не имеют решения класса Sandbox (на лето 2023 года). Ни UserGate, ни Континент, ни VipNet. Логичным было посмотреть на решения от других отечественных вендоров, которых мы обсудим буквально в следующих параграфах. Как мы скоро выясним, отечественные песочницы существуют, но пока не могут предоставить ту же экосистемность (хотя бы нативная интеграция с NGFW) и, самое главное, не предоставляют облачный вариант. Т.е. требуется покупка либо ПАКа, либо лицензии на виртуальную машину. Это существенно удорожает применение песочниц для маленьких компаний и сильно повышает порог входа в эту технологию. Справедливости ради, стоит отметить, что отечественный рынок ИБ еще никогда так быстро не менялся. Конкуренция очень высока. Производители NGFW озадачены созданием собственной песочницы (уже есть слухи о песочнице от UserGate), а некоторые производители песочниц уже активно разрабатывают NGFW (например Positive Technologies). Думаю первые результаты подобных трудов мы увидим уже в начале 2024 года. А пока давайте рассмотрим какие российские песочницы наиболее заметны на нашем рынке.

7.5.1 PT Sandbox Мы уже описывали саму компанию Positive Technologies и часть их продуктов. Портфель решений весьма богатый и покрывает сразу несколько классических уровней защиты: - Perimeter Layer: WAF и NGFW (ближайший релиз в 2024 году). - Network Layer: PT NAD (NTA/NDR класс решений). - Endpoint Layer: EDR. Песочница PT Sandbox отлично вписывается в данную экосистему. Positive Technologies может стать первой отечественной компанией которая реализует нативную связку NGFW+NTA+EDR+Sandbox из собственных решений. Исторически у компании сначала появился такой продукт, как PT Multiscanner, который выполнял исключительно статический анализ, т.е.

121

проверку файлов сразу несколькими антивирусами и собственными сигнатурами. В скором времени в PT Multiscanner был добавлен динамический анализ, т.е. реализованы классические функции песочницы. Так появился PT Sandbox. Ключевые “фишки” решения: - Возможность настройки виртуальных машин с добавлением собственного ПО. Далеко не все песочницы позволяют Заказчикам персонализировать запускаемые образы. - Ретроспективный анализ - повторная проверка прошедших файлов с помощью обновленных сигнатур. - Расширенные возможности по защите от техник “обхода” песочниц. - Проверка файловых хранилищ. - Уникальная экспертиза с учетом специфики российского рынка. Наличие собственной команды вирусных аналитиков. - Возможность использования дополнительных антивирусов для статического анализа (Kaspersky, Avast, Dr.Web, Symantec). - Возможность ручной проверки файлов (через загрузку в web или через специально выделенный почтовый адрес) для самостоятельного анализа зловредов. PT Sandbox может поставляться в виде ПАКа или в виде виртуальной машины, отдельно или же в составе платформы PT Anti-APT. Может интегрироваться с любыми NGFW, которые поддерживают технологию ICAP. Одно из немногих решений, которое может проверять файловое хранилище. Поддерживает интеграция с почтовыми шлюзами и может работать в режиме предотвращения (prevent), а не только детектирования. Дополнительным плюсом является наличие у PT собственного SIEM решения, сетевого сенсора (PT NAD) и сканера уязвимостей (PT VM). Как уже упоминалось ранее, идет активная разработка PT NGFW. Все это позволяет выстроить действительно комплексную защиту корпоративной сети. PT активно развивает собственную экосистему под названием Max Patrol 10, а также экосистему с автоматическим расследованием - MaxPatrol O2.

7.5.2 Kaspersky Sandbox Традиционно компания Kaspersky специализировалась на защите рабочих станций и надо признать, что они занимают лидирующие позиции в этом сегменте, даже на мировой арене. Однако их портфель богат решениями и других классов. Это и почтовые шлюзы, и прокси сервера, и защита контейнеров, и sd-wan, и SIEM системы, и даже песочницы. Песочница от компании Kaspersky входит в состав комплексной технологии KATA (Kaspersky Anti Targeted Attack). На сколько мне известно, решение от Kaspersky вышло чуть раньше, чем от PT и являлось эволюцией

122

собственного инструмента для изучения вирусной активности и последующего написания сигнатур. Решение было довольно популярно на нашем рынке и до введения санкций в 2022 году. Сейчас объемы рынка только растут. Регулярно выходят новые версии. Вот несколько “киллер фич” песочницы от Kaspersky: - Нативная интеграция песочницы с собственным EDR клиентом, который является одним из лучших на мировом рынке. - Нативная интеграция с собственным почтовым шлюзом KSMG (его мы рассматривали ранее). - Одна из лучших экспертиз на рынке, гигантская команда вирусных аналитиков. - Проверка android приложений. - Интеграция с облачным репутационным сервисом KSN (Kaspersky Security Network) - репутационные фиды мирового масштаба. - Отличная визуальная аналитика и отчетность по проверке файлов. На момент написания статьи (лето 2023) отсутствовала возможность модификации или создания собственных образов. Это делает невозможным установку специфичного для Заказчика ПО. Но данная опция в дорожной карте решения. Дополнительно можно отметить наличие собственного сетевого сенсора, что позволяет проверять файлы не только с уровня периметра и эндпоинтов, но и с сетевого. Песочница Kaspersky может интегрироваться с любым NGFW, НО пока только через собственное proxy решение - KWTS (Kaspersky Web Traffic Security). Интеграция KWTS и песочницы осуществляется с помощью проприетарного протокола. Поддержка ICAP должна быть реализована до конца 2023 года. После введения санкций KWTS (как и KSMG) обрел второе дыхание и пользуется большой популярностью среди клиентов, перед которым стоит задача фильтрации веб-трафика (по категориям, url или репутационной базе). Нативная интеграция с песочницей Kaspersky значительно повышает безопасность периметра. Ходит слух, что Kaspersky в ближайшем будущем планирует отказаться от KWTS в пользу собственного NGFW, разработка которого возможно уже ведется (более менее серьезных фактов этой разработки пока нет). В целом, это будем довольно логичное решение, особенно если учесть выводы из предыдущего параграфа - “на рынке выигрывают вендоры со своей экосистемой”. Kaspersky очень активно работает над собственной экосистемой продуктов, которая объединяет множество их ИБ продуктов в единую систему защиты на всех уровнях. Рабочее название экосистемы - Kaspersky Symphony XDR, где песочница в составе KATA занимает одну из ключевых ролей.

123

7.5.3 Group-IB TDS / Polygon Мы уже затрагивали компанию Group-IB и ситуацию вокруг ее разделения на мировое и российское подразделение (F.A.C.C.T). Сейчас довольно трудно предположить, как будет дальше развиваться судьба их продуктов на российском рынке, которые однозначно стоили внимания. Если смотреть каталог на сайте facct.ru (летом 2023 года), то песочница там отсутствует как решение. Возможно еще не прошла “локализация” продукта. Group-IB одни из первых выпустили отечественную песочницу (Polygon), которая пользовалась популярностью в банковском и государственном сегменте в виду специфики и экспертизы компании. Также Group-IB обладали довольно хорошой экосистемой, которая включала в себя (помимо песочницы): - Собственный SOC. - Собственный сетевой сенсор. - Собственные агенты (EDR). - Собственная репутационная база. - Собственный отдел расследования инцидентов (на мировом уровне). - И т.д. Из того, что мне известно (а мне известно далеко не все), российские владельцы песочниц от Group-IB сейчас в основном мигрируют на альтернативные решения - PT и Kaspersky.

7.5.4 AVSOFT ATHENA Еще одно заметное отечественное решение от не сильно известной компании “АВ Софт”. “Не сильно известная” - исключительно моя субъективная оценка и основана лишь на моем опыте. За более чем 10 лет работы в системных интеграторах я столкнулся с их продуктами лишь после введения санкций в 2022 году. Хотя сама компания довольно взрослая - более 10 лет на рынке и имеет несколько решений в своем портфеле, а именно: - Athena - классическая песочница (функционал рассмотрим чуть дальше). - Crimelab - криминалистическая лаборатория, которая предназначена для детального анализа вирусов множеством инструментов и формирования подробного отчета. - Palitra - система менеджмента и мониторинга, которая способна собирать данные от отдельных инсталляций и централизованно управлять их настройками. - Защита IoT - куда входят такие продукты как LOKI, NFI, VEIL. - Octopus - проверку файлов и мобильных приложений в большом количестве различных антивирусных систем. Мультисканер в простонародье.

124

-

Bond - корпоративный мессенджер для безопасной и удобной коммуникации. - Kairos - система защиты от фишинга и спама KAIROS специализированное решение для анализа веб-ссылок и содержимого сообщений на предмет нелегитимности и необходимости пользователю. Т.е. это почтовый шлюз, который относится к классу Email Security. Продукт относительно новый, поэтому мы не рассматривали его в соответствующей главе. Вернемся к теме параграфа. Песочница Athena существует на рынке уже довольно давно (более 5 лет) и зародилась как внутренняя разработка в крупной компании, а в последствии была выведена в отдельную команду. Athena как любая другая песочница поддерживает статический (более 20 антивирусов) и динамический анализ файлов. Из интересных особенностей: - Множество вариантов доставки файлов на эмуляцию: веб-трафик, почтовый трафик, мобильные устройства, съемные носители, ручное добавление файлов, telegram бот. - Эмуляция файлов предназначенных для Android. - Наличие экспертного режима, где администратор может гибко настраивать среду эмуляции и действия имитирующие пользователя (открытие файла, скроллинг, переход по ссылкам и т.д.). - Относительно скромные системные требования, в сравнении с основными конкурентами (PT, KATA). Песочница естественно умеет интегрироваться со сторонними NGFW решениями и почтовыми шлюзами. Поставляется в виде виртуальной машины. Среди представленных ранее конкурентов “АВ Софт” обладает наименьшей экосистемой и соответственно меньшей популярностью на нашем рынке. На мой взгляд, будет весьма логично, если это решение будет поглощено другим более крупным игроком в сфере ИБ (возможно одним из отечественных NGFW вендоров).

7.6 Бесплатные решения Мы рассмотрели наиболее заметные коммерческие решения на отечественном рынке. Также обозначили, что из зарубежных у нас все еще продается песочница от компании Check Point (SandBlast). Давайте теперь рассмотрим наиболее заметные бесплатные проекты. Их не так много: 1. Cockoo Sandbox (“кукушка”) - лидирующее open source решение в мире сетевых песочниц. Может разворачиваться практически на любой платформе в собственной инфраструктуре, имеет множество дополнений и интеграций. Стоит отметить, что многие коммерческие решения или сервисы основаны именно на “кукушке”. Поддерживает эмуляцию файлов как для Windows, так и для Mac OS, Linux и даже

125

Android. Не самое простое решение с точки зрения развертывания, администрирования и интеграции, но точно работающее и точно дающее результат. 2. Any.Run - песочница как сервис, т.е. веб-портал, куда можно загружать файлы для получения подробного анализа и вердикта. Подходит скорее для ручного исследования вирусов (хотя есть автоматизация через REST API), но никак не для интеграции с локальными решениями типа NGFW, почтовый шлюз или EDR. 3. Kaspersky Threat Intelligence Portal (opentip.kaspersky.com) - еще один веб-портал, где можно “закинуть” файл на анализ в песочнице и получить подробный отчет. Также больше подходит лишь для самостоятельного исследования вирусов. Существует платная подписка, которая позволяет уже автоматизировать процесс проверки файлов. 4. Hybrid Analysis (hybrid-analysis.com) - бесплатный портал для ручного анализа файлов в песочнице от известного мирового вендора CrowdStrike, который обладает коммерческой песочницей - Falcon Sandbox. На сегодняшний день доступ к порталу закрыт с российских ip-адресов. Есть и другие бесплатные и весьма похожие продукты, но перечисленные выше являются наиболее популярными (на мой субъективный взгляд). Что стоит сразу отметить? Практически все бесплатные решения подходят лишь для ручного анализа файлов, за исключением “кукушки”, которая весьма сложна в администрировании. Здесь сразу становятся очевидными плюсы коммерческих решений, которые могут интегрироваться с различными ИБ решениями и производитель автоматический анализ. Особенно ярко этот плюс проявляется у вендоров, которые способны предоставлять полноценную экосистему (Check Point, Fortinet, Palo Alto, возможно в будущем PT и Kaspersky).

7.7 Ключевые проблемы песочниц Как вы уже поняли, у любого решения или даже класса решений есть проблемы, с которыми “бьются” большинство вендоров и качество их продуктов как раз зависит от того, как они с этими проблемами справляются. Давайте рассмотрим ключевые проблемы для большинства песочниц: 1. Производительность Сама технология песочниц подразумевает большие затраты системных ресурсов. Поднятие виртуальных машин - необходимость. Чем больше файлов поступает на проверку, тем больше “виртуалок” нужно и тем мощнее нужен сервер, на котором разворачивается песочница. Бывали случаи, когда сервер стоил дороже, чем сама лицензия на песочницу.

126

Соответственно, чем лучше вендор способен оптимизировать эти виртуалки и чем больше файлов он сможет проверять, тем лучше. Повторюсь, что без облачного варианта песочниц стоимость входа в эту технологию сильно выросла и не по карману большинству небольших компаний. В том числе из-за стоимости вычислительных ресурсов под песочницу. Стоит быть весьма внимательным при подборе решения, а точнее модели (как аппаратной, так и виртуальной). В большинстве случаев вендоры измеряют производительность песочниц именно в количестве файлов в час (или в сутки), которые песочница способна проверить. Если вы планируете отправлять на эмуляцию не только файлы из электронной почты (которую посчитать гораздо проще), но и файлы с NGFW (web-трафик), то проведение пилотного проекта является абсолютно обязательным. Только реальный тест на вашей инфраструктуре сможет показать реальное количество файлов, которые нужно будет проверять в песочнице (и справится ли она с этим). 2. Источники файлов Еще одним важным параметром для любой песочницы является количество поддерживаемых источников файлов, т.е. решений, которые могут отправлять файлы на анализ. Ранее мы уже перечисляли наиболее популярные варианты. Наибольшую сложность, на мой взгляд, представляет интеграция песочницы с решениями по защите рабочих станций. Нет какого-то стандартного протокола типа ICAP для NGFW или SMTP для почтовых шлюзов. В связи с этим производители песочниц вынуждены разрабатывать собственные агенты для рабочих станций, которые обычно выливаются в такое решение как EDR. Не у всех это получается хорошо, а у некоторых такой агент вообще отстутствует. Интеграция же со сторонними агентами (например антивирусами) в большинстве случаев невозможна. Именно поэтому на рынке наибольшей популярностью пользуются вендора, которые способны предоставить свою экосистему, которая позволяет применять песочницу на всех уровнях защиты: Perimeter, Network и Endpoint Layer. Отдельным пунктом стоит отметить режим работы песочницы. Их, как правило два: 1. Prevent - блокирование вредоносного файла ДО того, как он попадает к пользователю. На примере NGFW - файл, который скачивает пользователь, должен забуферизироваться на шлюзе и по проприетарному, либо открытому протоколу (ICAP) передаться на анализ в песочницу. Шлюз сможет передать этот файл пользователю (или заблокировать) только после получения вердикта от песочницы. Для почтовых шлюзов примерно та же схема. Во всей этой схеме важно, чтобы и источник (NGFW или почтовый шлюзы) и песочница поддерживали возможность задержать файл, до получения вердикта. Надо признать, что не все вендора это умеют, а если и умеют, то 127

производительность NGFW или почтового шлюза может резко снижаться. И опять же, проприетарные протоколы обычно работают гораздо лучше и быстрее, т.е. когда источник файлов и песочница от одного вендора. 2. Detect - детектирование вредоносного файла, при этом сам файл доставляется пользователю. Естественно, данный режим не рекомендуемый, т.к. можно пропустить серьезную угрозу. Чаще всего этот режим используют на время тестирования, чтобы избежать ложных срабатываний и оценить адекватность срабатывания песочницы. Либо такой режим может использоваться когда Prevent в принципе невозможен - не поддерживается песочницей или источником файлов (NGFW или почтовый шлюз). Плюс, песочница может работать с копией трафика (на SPAN порте) или сетевым сенсором, который работает с копией трафика. Естественно, в таком режиме блокировка невозможна. При выборе решения стоит учитывать эти архитектурные особенности и четко понимать, что вы собираетесь проверять в песочнице, т.е. что будет являться источником файлов. Естественно, в идеальном случае, вы должны выполнять проверку на всех трех уровнях: Perimeter, Network и Endpoint Layer. 3. Противостояние техникам обхода Как мы обсуждали выше, перед производителями песочниц стоит серьезный вызов, т.к. в большинстве случаев именно песочница является последним рубежом защиты от попадания вредоноса в сеть. Все это значительно повышает требования к уровню детектирования вирусов. При этом нужно сохранять приемлемый уровень ложных срабатываний, когда по ошибке блокируются легитимные файлы (а такое тоже бывает). Но все эти проблемы меркнут перед главной задачей - противостоять техникам обхода песочниц. Если помните, исторически, песочницаа появилась именно как средство защиты от целенаправленных атак, когда вирус разрабатывается злоумышленниками под конкретную компанию или целую сферу (например банковскую). Хакеры прекрасно понимают, что серьезные компании могут иметь хорошую защиту, поэтому стараются делать более сложные вирусы, которые будет невозможно поймать традиционными средствами защиты типа антивируса или IPS. В каком-то смысле, песочница уже тоже стала традиционным средством защиты для средних и крупных компаний. Злоумышленники учитывают это и всячески пытаются их обходить с помощью различных техник. И здесь производители песочниц должны оправдывать возложенные на них надежды - блокировать даже самые сложные угрозы. Противостояние техникам обхода - одна из важнейших характеристик современных песочниц. При выборе решения следует уделить этому особое внимание.

128

7.8 Резюме по Sandbox ● Сигнатурный анализ не дает высокой надежности при таргетированных (ранее неизвестных) атаках. ● Концепт песочниц зародился очень давно. Один из примеров дегустаторы королевской еды и напитков. ● Ключевой смысл песочницы - создание безопасной зоны, где можно сдетонировать файл и посмотреть “что случится”. ● Песочница бывает облачная и локальная (виртуальная машина или ПАК). ● Процесс эмуляции в песочнице требует огромного количества ресурсов, т.к. запускается полноценная операционная система (Windows, Linux, Android). ● Песочница чаще всего интегрируется с NGFW, EDR, Email Security, Сетевым сенсором (NTA/NDR), WAF и т.д. ● Все песочницы обладают статическим (проверка сигнатурами, репутационными базами или ML/AI алгоритмами) и динамическим анализом (запуск и анализ в виртуальной машине). ● Существует огромное количество техник обхода песочниц, когда вирус пытается понять, что он находится в виртуальной среде и “затаивается”. ● Лидирующие вендоры имеют собственные разработки для противодействия техникам обхода. ● Очистка активного содержимого в файлах является хорошим дополнением к песочнице. ● Наибольшей популярностью пользуются песочницы от вендоров, которые предлагают экосистемный подход - нативная интеграция с NGFW, EDR и т.д. ● Наиболее заметные игроки отечественного рынка: Check Point (все еще продается), PT Sandbox, Kaspersky Sandbox (в составе KATA), AVSOFT ATHENA. ● Бесплатные решения: Cockoo Sandbox, Any.Run, Kaspersky Threat Intelligence Portal, Hybrid Analysis. ● Песочница это больше не “диковинка”, а абсолютно необходимая функция комплексной защиты. ● Ключевые проблемы песочниц: производительность, количество поддерживаемых источников файлов и противостояние техникам обхода.

129

8. Другие средства защиты на Perimeter Layer Давайте резюмируем, какие классы средств защиты мы рассмотрели в рамках этой книги: Network Firewall (он же UTM или NGFW), Email Security, WAF и Sandbox. Причем описали мы их именно по порядку востребованности и объемов рынка. У любопытного читателя может возникнуть вопрос: “А есть ли другие классы средств защиты на уровне периметра?”. Безусловно есть. По хорошему в эту книгу можно было бы включить еще как минимум такие классы средств защиты, как: ● DLP (Data Loss Prevention) - защита от утечек данных. Данные системы более эффективно работают на уровне рабочих станций, но все же многие вендоры имеют и более комплексные варианты развертывания, в том числе проверку трафика на периметре. На российском рынке существует огромное количество взрослых и зрелых вендоров в сфере DLP: InfoWatch, SearchInform, Zecurion, Гарда Технологии и т.д. Интересный факт - даже до введения санкций на российском рынке были более популярны именно отечественные DLP решения. Это еще один факт в подтверждение зрелости этого сегмента. ● Anti-DDoS - защита от DDoS атак. Здесь стоит понимать, что существуют два типа атаки: - Атака на переполнение канала. Здесь классические локальные Anti-DDoS решения вряд ли помогут. Что толку фильтровать трафик, если интернет канал все равно забит и легитимный трафик все равно будет страдать. В этом случае нужна помощь уже облачных Anti-DDoS решений, чтобы блокировать вредоносный трафик еще до попадания в интернет канал компании. По нашему концепту это уже средства защиты из Internet Layer. Хороший пример решения из этой сферы - Qrator Labs. - Атака на отказ сервиса. Даже небольшой, но правильно сформированный вредоносный трафик может “положить” ваше приложение. Облачные Anti-DDoS решения в этом случае справляются гораздо хуже и нужно уже локальное Anti-DDoS решение, которого осуществляет DPI трафика и способно отбросить враждебные запросы. Одно из лучших российских решений в этом сегменте - Mitigator. ● BAS (Breach Attack Simulation) - система, которая непрерывно тестирует ваш периметр на предмет защищенности. Специальный агент установленный внутри сети симулирует действия зараженного хоста и постоянно пытается получить доступ к вредоносным ресурсам или 130

“протащить” в сеть свежий вирус. Если это получается, то система сигнализирует администратору о недостаточной защищенности периметра. Это может быть из-за несвоевременного обновления средств защиты (NGFW, Email Security) или же из-за плохой настройки (открыли лишние порты, забыли включить проверку архивов и т.д.). Это очень молодой класс средств защиты и на российском рынке (до санкций) он был представлен двумя основными игроками: Cymulate и Threat Simulator (KeySight). Отечественные аналоги пока отсутствуют, либо я про них не знаю. ● PenTest системы - непрерывная проверка периметра на предмет наличия известных уязвимостей или открытых портов. Подобные системы обычно сканируют периметр из публичной сети, т.е. позволяют увидеть нашу сеть глазами хакера и подсветить слабые места. В качестве такого решения может использоваться классический сканер уязвимостей, который чаще используют внутри локальной сети. Достаточно лишь развернуть его в публичном облаке и начать сканирование нужных вам IP-адресов. Однако сейчас активно появляются целые сервисы по внешнему сканированию ваших ресурсов, пример: PT BlackBox (сканирует только веб-приложения) и ScanFactory (сканирует любые сервисы). Почему мы подробно не рассмотрели данные классы решений? На это две причины: 1. Я просто не являюсь экспертом в этих областях и пока не готов делиться знаниями. Их просто недостаточно. 2. Книга получилась бы слишком объемной и нудной (как мне кажется). Но могу с уверенностью сказать, что мы рассмотрели наиболее популярные классы, которые обеспечивают защиту периметра сети. И именно с них, чаще всего, компании начинают построение ИБ с технической точки зрения. Что, на самом деле, не совсем правильно! Мы частично затрагивали этот вопрос в предыдущей книге - Азы Кибербезопасности.

131

Вместо заключения Заключение принято писать там, где история закончена. В моем же случае история только началась. Если вы помните наш концепт из начала книги, то мы рассмотрели всего лишь один уровень - Perimeter Layer. Что касается других уровней защиты - надеюсь заняться продолжением цикла “Архитектура защищенных сетей” в самое ближайшее время. Если вам показалась интересной данная книга, то ждите продолжения… От себя хотел бы добавить, что все написанное является лишь моей точкой зрения и в некоторых случаях я конечно же могу ошибаться. Но совершенно точно могу сказать, что не пытался ввести кого-то в заблуждение или рекламировать какое-то отдельное решение. Книга писалась абсолютно беспристрастно, основываясь на своем личном опыте, а также на материалах уважаемых мной изданий и авторов. Я искренне надеюсь, что эта книга действительно кому-то пригодилась, т.к. было потрачено довольно много времени на ее написание - более 100 часов. Для меня же это была отличная возможность стандартизировать и разложить по полочкам собственные знания и поделиться ими прежде всего со своими коллегами в компании TS Solution. Если вы дочитали до самого конца, то могу сказать только одно - больше спасибо за проявленный интерес! Оставайтесь такими же любознательными и делитесь своими знаниями с другими. До новых встреч!

132