Валерий затронет следующие вопросы:
Хакеры каждый год придумывают что-то новое. Они прошли большой путь от простых атак, червей, от атак на приложения, дальше были различные зараженные вложения и теперь они перешли к глобальному этапу.
Сейчас злоумышленники используют сразу множество различных векторов для того, чтобы достигнуть своих целей. И в ответ на это у Check Point есть решения для защиты от большинства векторов сетевых атак на инфраструктуру заказчика.
Это объединено под неким общим термином Infinity. Это некая архитектура, которая позволяет защитить данные в любой точке, где бы они ни находились. Будь они внутри периметра, либо на мобильном устройстве, либо на рабочей станции, или в ЦОДе. Т.е. в каждой точке можно защитить заказчика, и можно предотвратить следующую атаку. Или сделать эту атаку максимально дорогой для злоумышленника с тем, чтобы вероятность того, что эта атака вообще будет совершена, была минимальной.
Что такое Infinity и из чего она состоит. Начнем с защиты периметра сети. Это самая базовая защита. Это та часть инфраструктуры, где у нас есть полный контроль. Одним из центральных элементов защиты периметра сети у Check Point является шлюз безопасности. Это некий межсетевой экран следующего поколения, в котором у Check Point в одной коробке содержится множество различных функций, призванных защитить от известных и неизвестных угроз.
Это сам по себе межсетевой экран, который фильтрует трафик на сетевом уровне. Это IPS, система предотвращения вторжений, которая ищет различные атаки и их шаблоны в трафике и старается предотвратить эти известные атаки. Это и контроль приложений. Вы можете контролировать, какие пользователи и куда, к каким сайтам они обращаются, к каким категориям сайтов. Например, если имеется в компании отдел кадров, то можно разрешить ему доступ к социальным сетям. При этом всем остальным пользователям в рабочее время запретить такой доступ, дабы это не вредило производительности. Конечно, кроме таких стандартных элементов у шлюза следующего поколения, есть еще интеграция с песочницами, т.е. с некими устройствами, которые позволяют бороться уже с неизвестными угрозами.
Если посмотреть на сами устройства, которые есть у Check Point, т.е. шлюзы сетевой безопасности, шлюзы защиты от угроз, то здесь очень широкая линейка. На слайде представлена линейка устройств под любые нужды. Есть совсем маленькие железки, т.е. 14-й серии, там даже есть Wi-Fi, которые удобно поставить в маленький офис для защиты небольшого количества пользователей. Есть и очень большие в виде больших шкафов (6 юнитов), которые позволяют предотвращать атаки на очень высоких скоростях.
Причем, если у заказчиков есть потребности в более гибкой защите, в более гибком подходе к обработке трафика на разных скоростях, то у Check Point есть архитектура, которая называется Maestro, когда, например, сегодня вам нужно 300 Мбит/c защиты трафика, а завтра внезапно необходим защитить 600 Мбит/c. Дабы не сдавать неудовлетворяющие скоростям шлюзы в Trade in, и не заменять их на более мощные, можно установить архитектуру таким образом, что вы ставили два шлюза на текущие 300 Мбит/c плюс некий оркестратор, который распределяет трафик по шлюзу. И если завтра внезапно появилось требование обработать 600 Мбит/c, то мы просто добавляем новые шлюзы и подключаем их к оркестратору. Далее оркестратор сам разбирается с тем, как балансировать трафик и как сделать так, чтобы ваши текущие требования были удовлетворительными с точки зрения безопасности и чтобы вся инфраструктура была защищена от современных угроз. Т.о. если мы, например, берем новые устройства 6800, то соединив их в архитектуру Maestro мы можем получить очень большие скорости.
Это то, что касается борьбы с известными угрозами на уровне периметра сети. Сейчас же злоумышленники понимают, что нет смысла тратить большое количество своих ресурсов для того, чтобы запускать различные угрозы, если эти угрозы будут обычными вирусами, IBS и т.п.
Поэтому они проверяют угрозы на антивирусах и стараются удостовериться в том, что эти угрозы антивирусы не смогут распознать, и угрозы смогут попасть в сеть. Для того, чтобы закрыть такой вектор, вектор защиты от неизвестных угроз, у Check Point есть песочница, которая относится к семейству SundBlast, это очень мощный выделенный физический сервер. Он не может быть виртуальным, поскольку там совершается огромное количество проверок, и мы даже отслеживаем различные поведения вредоносов на уровне ОС, и на уровне самого центрального процессора. Поэтому выделен физический сервер, в котором огромное количество механизмов пытается понять, насколько тот или иной неизвестный для антивирусов, для IBS, для всех остальных классических механизмов файлов, насколько этот файл может совершать вредоносные или потенциально вредоносные действия. И, если этот файл окажется действительно вредоносным, то песочница скажет об этом шлюзу безопасности, этот файл будет отброшен, и пользователь не заразится. Причем само семейство продуктов SundBlast призвано защитить заказчиков от неизвестных угроз в различных средах. Т.е. от сетевого периметра до защиты в облаках. Наша песочница может быть либо локальным аппаратом, физическим сервером, который стоит у заказчика, либо это такой же аппаратный сервер, но находится он в облаке Check Point.
Либо же этот аппаратный сервер может находиться в облаке наших партнеров. И тогда, если, например, заказчик не хочет отправлять файл за пределы РФ, то он может обратиться к нашим партнерам, и эмуляция файлов, поиск неизвестных угроз, неизвестных файлов, новых файлов будет происходить уже на территории РФ в облаке наших партнеров. Либо, если заказчик совсем не хочет отправлять файлы за пределы своего периметра, то он может поставить локальное устройство SundBlast, локальный физический сервер. Кроме того сами SundBlast - это достаточно развитые устройства, поэтому у них есть современные методы обращения к ним. Например, если есть какие-то программные среды, самописные среды, и необходимо проверять файлы в этих самописных средах, то, например, можно отправить эти файлы по различным ABI, т.е. по различным виртуальным и программным интерфейсам внутрь нашего SundBlast для того, чтобы понять, насколько тот или иной файл в данной системе потенциально вредоносен. Причем, недостаточно просто получить некий вердикт о вредоностности или невредоносности данного файла. Потому что непонятно, что это было, действительно критическая угроза или просто мусор.
А может действительно очень опасная критическая угроза, которая является Zero day. Так вот, для того, чтобы это понять, песочница SundBlast формирует отчеты об эмуляции после обнаружения каждой угрозы. Они предоставляются автоматически и кроме того, песочница Check Point говорит, например, что обнаружились 57 угроз, для большего понимания о том, что это за угрозы, мы даже обнаруживаем различные ДНК этих вредоносов. Т.е. мы понимаем, из чего состоят эти вредоносы. И тогда вы не просто обнаруживаете 57 угроз, а вы обнаруживаете, например, 5 определенных семейств вредоносов. Исходя из этого, вы сможете понять, насколько эти вредоносы опасны для вашей инфраструктуры, т.е. какую опасность они несут и что они могли бы сделать, если бы они не были остановлены песочницей.
Причем мы это делаем благодаря нашему облаку, нашему МО, поскольку многие вещи сейчас уходят в сторону МО, т.к. писать сигнатуру руками уже просто невозможно. Злоумышленников становится все больше. Все больше становится экземпляров угроз, которые появляются тысячами каждый день. Поэтому все эти файлы, весь трафик, который анализируется нашими устройствами, скармливается в механизм МО, который уже сам автоматически формирует сигнатуры. И как раз он может проанализировать миллионы различных угроз. Скоррелировать информацию между собой. И поэтому эту информацию вы как раз сможете увидеть в отчетах песочницы.
Сейчас никто не хочет ждать. Поэтому для того, чтобы соблюсти баланс безопасности и удобства, мы создали технологию Threat Extraction. Т.е. если пользователь получает какое-то вложение, которое необходимо проверить в песочнице, и для того, чтобы пользователь не ждал, мы можем очистить это вложение от потенциально вредоносного содержимого, т.е. от ссылок, макросов, и сразу же доставляем пользователю.
А если пользователю нужен оригинал, то перенаправляется на некую Web страницу, где он подтвердит, что ему действительно нужен оригинал этого документа, написав какое-то обоснование и запросив этот файл. Причем, мы не доверяем пользователю и отдаем ему только те файлы, которые песочницей были признаны как не вредоносные. Тем самым наш пользователь защищен от заражения, потому что неизвестные и небезопасные файлы мы ему никогда не отдаем. Эта технология работает в связке с песочницей, в связке со шлюзом и позволяет как раз не отключать средства безопасности, не понижать уровень безопасности и снизить нагрузку на отдел ИБ для того, чтобы они не выдавали оригиналы вручную, не перепроверяли их. Это некий шаг к полной автоматизации ИБ.
Если посмотреть на общую архитектуру, то увидим, что самая базовая архитектура защиты периметра сети состоит из шлюзов, которые разграничивают доступ в Интернет и во внутренние сети. Т.е. для того, чтобы разграничить уже внутренние различные периметры. Эти шлюзы, например, перехватывают почту, т.е. некие наши MX-записи. Они смотрят на антиспам, а уже после антиспама есть запись на Check Point. Сначала почта приходит из Интернета на антиспам. Там она фильтруется от большинства мусора из Интернета, затем отфильтрованные письма попадают на шлюзы Check Point. Если есть в письмах какие-то вложения, то они вытаскиваются из писем и перенаправляются в песочницу. После того, как песочница скажет нам, что с этим файлом, мы можем доставить оригинал пользователю. А параллельно мы мгновенно доставляем вложение пользователю для того, чтобы ему не приходилось ждать. Эта же технология работает и на агентах.
После того, как мы защитили периметр, т.е. защитили самые базовый актив, мы можем перейти к защите облачной инфраструктуры. Понятно, что бизнес трансформируется, что сейчас все больше и больше заказчиков так или иначе используют облака. Причем, неважно, какие это облака, частные облака, например, VMware, NSX, AWS и т.п. Это могут быть и публичные облака. Например, Amazon, либо Ager, либо Oracle Cloud, либо Google Cloud либо многие другие. И в этих облаках точно такая же инфраструктура, и там тоже необходимо обеспечивать безопасность. Для этого у Check Point есть решение под названием CloudGuard, которое делится на несколько составных частей.
Первая часть - CloudGuard IaaS - сервис для защиты публичных облаков. Другая часть - для защиты частных облаков. Т.е. это различные NSX, ACI и прочие.
Следующая вещь это CloudGuard Dome9. Это тоже часть семейства CloudGuard, которая позволяет проверять настройки, делать некий постоянный комплайнс, т.е. эта штука позволяет вернуть контроль над публичным облаком, над которым нет прямого контроля в отличие от частного облака.
И последней частью является CloudGuard SaaS - это защита облачных приложений. Т.е. приложений, которые живут только в облаке. Например, salesforce, либо Офис 365, либо Dropbox, либо другие облачные диски. Т.е. те сервисы, где вы ничего не можете установить. Не можете установить никакой шлюз, который бы полностью находился под вашим контролем. Однако, если это Офис 365, то все равно необходимо защищать почту, потому что тут также могут приходить различные вредоносные письма с вложениями, с различными фишинговыми ссылками, фишинговые письма. Потому что фишинг - рабочий инструмент злоумышленника.
Причем, если рассматривать CloudGuard IaaS, то это некий виртуальный шлюз в облаке. Причем, не важно в каком облаке, публичном или частном, который обладает всеми теми же функциями по защите от современных угроз, которые находятся и в железе. Т.е. у Check Point нет разницы между железным и виртуальным шлюзом с точки зрения функций. Единственная разница состоит в том, что когда вы покупаете устройство, вы точно знаете, сколько она сможет обработать трафика, и что это устройство будет заниматься только обработкой трафика, а не чем-то еще, как это происходит в виртуальной среде. Однако в любом случае, если у вас есть какой-то виртуальный ЦОД, и в нем необходимо разграничивать потоки трафика для того, чтобы, например, компрометация одной виртуальной машины не привела к компрометации вообще всего виртуального ЦОДа, то как раз можно использовать CloudGuard IaaS, в котором активируются все функции по защите от современных угроз.
Причем, поскольку мы понимаем, что облако довольно динамичная среда, там машины могут, например, переезжать из одного облака в другое. Например, была машина в частном облаке, потом она и репроицируется в публичное. Конечно же, для того, чтобы поддерживать такую структуру, необходимо понимать, что находится в облаке, какие виртуальные машины, с какими функциями, какими IP-адресами и т.д., для того, чтобы политика безопасности, политика доступа действительно была актуальна на текущий момент. И, если, например, наша виртуальная машина переезжает из одного облака в другое, то для того, чтобы политика все равно была актуальна, и ее не нужно было бы править каждый раз, то если машина была в частном облаке с таким-то IP-адресом, потом она переезжает в публичное облако, и ее IP-адрес меняется, то в обычном случае нам необходимо менять политику и менять настройки этого объекта. Т.е. указывать, что изменилось. У Check Point же CloudGuard IaaS подключается к облачной инфраструктуре, и считывает эти данные. И, когда машина переезжает, CloudGuard IaaS уже об этом знает, при этом не нужно менять политики или какие-либо настройки, защита итак будет действовать. Т.е. уровень защиты снижаться не будет. И при этом администраторам ничего не нужно делать в случае каких-то перемещений.
Поговорим теперь про некий комплайнс, некое получение контроля над публичным облаком. У Check Point появился теперь сервис, который называется CloudGuard Dome9, и он решает такие проблемы, которые мы все часто видим в новостях. Например, произошла утечка каких-то конфиденциальных данных. Или в каком-то облаке обнаружились внутренние виртуальные машины доступные cнаружи.
Почему так происходит? Во многом из-за того, что когда у вас есть некое публичное облако, со многими регионами доступности, то сложно понять, где, какие виртуальные машины находятся и какой уровень доступа к этим виртуальным машинам есть у пользователей в Интернете. И для того, чтобы решить эту проблему, для того, чтобы вернуть контроль над публичными облаками, у Check Point есть CloudGuard Dome9. Это сервис, который постоянно сканирует все ресурсы, которые развернуты в публичном облаке, и пытается понять, насколько те или иные настройки этих ресурсов корректны с точки зрения политики ИБ.
Например, если какой-нибудь администратор создает новую виртуальную машину, которая будет, например, обслуживать какой-нибудь Web-сервис, применил ли администратор на эту виртуальную машину, например, настройки по безопасности? Чтобы у виртуальной машины был доступен наружу только один порт. И при этом были запрещены обращения к портам управления. CloudGuard Dome9 сканирует постоянно настройки, проверяет настройки виртуальных машин на различных ресурсах. Например, если мы говорим про Amazon, то настройки различных хранилищ данных должны быть такими, чтобы вы были уверены, что эти настройки этих ресурсов именно те, которые вы ожидаете. При этом у данного сервиса есть одна интересная фича, она проверяет именно доступ с точки зрения сети до различных ресурсов. И эта карта сети, карта безопасности в публичном облаке формируется автоматически. Если у нас есть какой-то ресурс, балансировщик нагрузки, который должен быть доступен извне, и при этом, кроме него больше ничего не доступно, то можно быстро понять, что происходит в публичном облаке, и если неожиданно снаружи оказался какой-то ресурс, то прекратить доступ к ресурсу и поменять настройки.
Причем, это можно делать либо вручную, либо в автоматическом режиме. Т.е. задать некую политику, политику Best Practice и эта политика будет постоянно проверяться. И если кто-то что-то настроил не так, то настройки будут возвращены в безопасное начало. Например, если администратор создал сервер базы данных, либо Web-сервер и разрешил к нему доступ, то через пару секунд этот доступ будет отозван и возвращены стандартные настройки безопасности. Т.е. администратор не сможет нарушить ни случайно, ни умышленно безопасность инфраструктуры публичного облака. При этом, если есть несколько различных облаков, то CloudGuard Dome9 подключается сразу ко всем облакам заказчика и затем в единой консоли можно видеть, где, в каком облаке и какие есть инциденты, какие проверки проходят или не проходят, и соответственно быстро среагировать на это.
Используя несколько различных средств облачной защиты можно получить полную защиту облака со всех сторон, применяя защиту от известных и неизвестных угроз на уровне облачных решений. Опять же, если есть такие вещи, как автоматизация, т.е. некий автоматический подход к защите инфраструктуры и вообще к управлению инфраструктурой, то это тоже все поддерживается облаками. Если у вас есть некое облачное приложение, например, Офис 365, G-drive, либо другие облака, то понятно, что злоумышленники, если они понимают, что данный сервис каким-то образом влияет на финансовую деятельность компании, то это можно каким-то образом нарушить, либо украсть какие-то конфиденциальные данные и нанести ущерб инфраструктуре.
Поэтому злоумышленники тоже пытаются эксплуатировать облачные приложения. И вот для того, чтобы защитить облачные приложения, у Check Point есть CloudGuard SaaS. Это взаимодействие облака с облаком. Вы уже не устанавливаете какую-то виртуальную ссылку как в случае CloudGuard IaaS, а вы используете облако Check Point, которое интегрируется с облаком, в котором крутится какое-то облачное приложение. (26:40) При этом используются все те же самые проверенные технологии.
Причем, Check Point постоянно проверяется различными внешними компаниями, насколько он хорошо выполняет свои функции безопасности.
Следующим компонентом CloudGuard SaaS является компонент защиты от фишинга. Поскольку облачное приложение доступно в любой точке мира, и доступно всегда, то злоумышленники могут постоянно пытаться найти какие-то слабые места этого приложения. Например, отправлять фишинговые письма, подбирать пароли, каким-то образом пытаться с помощью социальной инженерии ввести в заблуждение пользователя. Поэтому в CloudGuard SaaS есть защита от фишинга, которая помогает пользователю понять, насколько то или иное письмо фишинговое. Т.е. насколько оно в состоянии украсть какие-то конфиденциальные данные у пользователя. Причем, понятно, что невозможно писать постоянно какие-то решающие правила с точки зрения таких писем, которые будут тем или иным образом отбивать фишинг. Поэтому мы анализируем миллионы различных писем через наше облако, и с помощью машинного обучения, с помощью специальных алгоритмов помогаем пользователю защититься от фишинга и сделать так, чтобы пользователь не заразился.
Другой момент - это защита учетных записей пользователя. Понятно, что облако доступно в любой точке нашей планеты, и поскольку злоумышленники могут просто аккуратненько и потихонечку подбирать пароли, то от этого необходимо защититься. Иначе пользователь может либо забыть свой пароль, либо злоумышленник может каким-то образом скомпрометировать его учетную запись, и таким образом получить из любой точки доступ к облачному приложению. Чтобы такое не могло произойти, в CloudGuard SaaS есть специальный механизм, который предотвращает такие вещи. Например, сегодня вы залогинились из Москвы в облачное приложение, а через секунду откуда-нибудь из Нигерии. Скорее всего такой логин небезопасен, и его нужно предотвратить. Но это простой вариант. А что, если злоумышленник пытается залогиниться из той же самой локации? Тогда, для того, чтобы предотвратить такие вещи, есть специальное приложение, которое устанавливается на рабочую станцию, либо на мобильник, которое позволяет удостовериться в том, что пользователь пытается зайти в облачное приложение с доверенного устройства. А если это устройство каким-либо образом заражается, например, пользователь каким-то образом схватил вредонос на свою рабочую станцию, то доступ к облачному приложению блокируется до тех пор, пока инцидент не будет разрешен. Это делается для того, чтобы защитить пользователей и для того, чтобы они не смогли скомпрометировать облачное приложение. Все управление этими механизмами доступно в единой консоли, которая находится в Интернете, и доступна в виде Web-приложений.
У нас есть какой-то злоумышленник, который отправляет письмо через облачную почту пользователя. Это письмо попадает в CloudGuard SaaS и далее работают те же самые механизмы, как если бы у вас это письмо пришло в периметр, защищенный Check Point шлюзами и с помощью песочницы SandBlast. Т.е. из письма вытаскивается вложение, которое отправляется в SandBlast для того, чтобы понять, насколько оно вредоносное.
Оно эмулируется дальше в песочнице, при этом параллельно пользователю доставляется очищенное вложение. Пользователь мгновенно получает безопасную копию письма. При этом, если вдруг письмо оказалось вредоносным, то оно пользователю не доставляется. Оно либо вообще удаляется, либо доставляется в карантин. А пользователю приходит уведомление о том, что было заблокировано вредоносное письмо. И это работает для различных облачных сервисов, для различных облачных приложений