Раздается недавно звонок:
— Добрый день! Я бы хотел получить спецификацию на межсетевой экран Cisco ASA. У меня уже есть спецификации от компании <имярек> и я хочу сравнить их и выбрать подходящую. Вы можете мне помочь в этом?
— Да, конечно. А для чего вам нужна Cisco ASA?
— Мне необходимо заблокировать Tor.
— А вам нужна именно Cisco ASA для этого?
— Ну а как? Вот компания <имярек> говорит, что ее межсетевой экран блокирует Tor. Поэтому я хочу сравнить стоимость их экрана с вашим.
— То есть вам нужно заблокировать Tor и вы ищите для этого нужное вам решение?
— Да-да (раздраженно). Так вы можете мне составить спецификацию? Какие исходные данные вам нужны?
— Для решения именно этой вашей задачи, если другие перед вами не стоят, необязательно использовать Cisco ASA. Блокировать работу с Tor вы можете с помощью различных наших решений — Cisco Web Security Applaince, Cisco Umbrella Security Internet Gateway, Cisco Cloud Web Security, Cisco Meraki MX, Cisco Firepower, Cisco AMP for Endpoints… В конце концов вы можете с помощью скрипта подгружать адреса узлов сети Tor в маршрутизатор Cisco ISR и блокировать их с помощью ACL. В последнем случае вам и тратить ничего не придется.
— Да? Вот блин. Мне надо тогда подумать…
— Давайте мы с вами вместе составим перечень задач, которые вам надо решить, и угроз, с которыми надо бороться, и тогда уже выберем наилучшим образом подходящий продукт?
— Хорошо, давайте. Вы сможете к нам подъехать завтра к 10-ти утра?
— Конечно.
Схожие по сути звонки мы получаем достаточно часто и они отражают сложившуюся практику не решения своих задач, а закрытия текущих проблем с помощью лучше всего известных продуктов. Это как со строительством дорог. Можно их изначально строить правильно (пусть и первоначальные затраты будут подороже), а можно каждый год перекладывать пришедший в негодность асфальт или ставить заплатки на образовавшиеся ямы (что в итоге обходится дороже). Таких “ям” в какой-то момент становится слишком много и наступает коллапс — все приходится переделывать, а человек, начавший эту “заплаточную” историю теряет свое место (а может он и сам давно покинул свою должность, предвосхитив возможные проблемы). Так и с построением системы информационной безопасности на предприятии. Мы слишком привыкли мыслить продуктовыми категориями. Тут мы купим Cisco ASA (наверное, потому что других межсетевых экранов у Cisco мы не знаем), тут поставим Cisco Web Security Appliance (хотя можно было бы обойтись и Cisco Umbrella), тут нужен антивирус <имярек> (хотя заказчик столкнулся с безфайловыми атаками), тут поставим сертифицированный криптошлюз (хотя можно обойтись и встроенной в маршрутизатор или операционную систему VPN-функциональностью)… Все это началось очень давно, когда на рынке присутствовали игроки с одним продуктом, который решал определенную задачу. Так произошла подмена понятий — “решение задачи” было заменено на “продукт”. Но время шло, портфолио производителей расширялось, функциональность продуктов тоже, а подход “хочу продукт” остался.
Я иногда завидую нишевым вендорам по кибербезопасности. Чем хороша работа у них? Небольшим набором продуктов, решающих вполне конкретные задачи. Нужен, например, заказчику межсетевой экран, — вот вам межсетевой экран. Никаких разночтений и разногласий — все предельно понятно. Максимум, по чему может выйти спор, это какая модель нужна — на 250 или 600 мегабит в секунду? Нужно заказчику, например, блокировать Skype в своей сети — опять же вот вам межсетевой экран с соответствующей функцией (если она в МСЭ есть, конечно). Все довольны. Вендор, который штампует коммерческие предложения пачками (продукт-то один — не разгуляешься). Заказчик, который на свой запрос получает готовое предложение с конкретной ценой. Партнер, которому не надо иметь компетенции по разным решениям.
В Cisco ситуация немного иная. Начнем с того, что у нас тех же самых межсетевых экранов семь:
- Cisco ASA 5500-X
- Cisco Firepower
- Cisco ASAv
- Cisco Virtual Security Gateway
- Cisco IOS Firewall
- Cisco Meraki MX
- Cisco ASA SM for Catalyst.
И это если не рассматривать снятый с производства 10 лет назад, но до сих пор используемый некоторыми заказчиками, Cisco Pix, а также различные “прикладные” МСЭ, например, DNS-фильтр Cisco Umbrella, HTTP-фильтр Cisco Web Security Appliance и т.п., которые с некоторой натяжкой, но тоже могут носить гордое звание межсетевых экранов для определенных задач.
И поэтому даже на обычный запрос “да нам бы обычный межсетевой экран” мы ответить просто так не можем. Да и не правильно это. Очень важно выбирать средства защиты не из его названия или типа (например, NGFW есть у многих производителей, но вот понимание того, что такое NGFW, у всех разное) или своего представления о продукте, а из решаемой задачи и детального изучения характеристик и функций имеющегося у производителя портфолио. В случае с Cisco, в наших продуктах используется немало перекрестных или схожих по своей сути технологий и правильный их выбор лучше обсуждать с представителями производителя или квалифицированного партнера. Тем более, что мы всегда открыты для консультаций и готовы помогать нашим заказчикам и партнерам.
Поэтому при звонках, аналогичных приведенному выше, мы начинаем “занудствовать” и уточнять, для решения какой задачи заказчику нужен межсетевой экран. Ему нужен межсетевой экран для разграничения доступа на сетевом уровне? Для защиты виртуализированных сред? Для контроля приложений? С привязкой правил к учетным записям пользователей или нет? Для установки на магистральных каналах или на удаленной площадке? А все потому, что портфолио наше по кибербезопасности достаточно широко и банального ответа “купите наш межсетевой экран и будет вам счастье” мы дать поэтому не можем. Мы руководствуемся принципом, что решаемая задача определяет используемый продукт, а не наоборот. Если у других производителей всего один межсетевой экран или одна система обнаружения атак и поэтому они убеждают заказчиков, что “гонять весь трафик, даже внутренний, через периметровый МСЭ — это нормально” или что “поставьте периметровую IDS на каждом транке или SPAN-порту и вы решите свою задачу”, то мы так не работаем. Сначала определяется решаемая задача и (или) модель угроз, а потом уже выбирается под них соответствующее решение, которое может отличаться от изначально предполагаемого заказчиком.
Но давайте попробуем выйти за рамки только межсетевого экрана? У нас ведь номенклатура решений по кибербезопасности гораздо шире и далеко не все можно и нужно решать только с помощью межсетевого экрана. Возьмем, к примеру, задачу контроля доступа к Web-ресурсам. В случае с Cisco решаться она может по-разному. Как минимум 4 продукта позволяют нам контролировать доступ к Интернет-ресурсам:
- аппаратный или виртуальный Cisco Web Security Appliance (WSA)
- облачный Cisco Cloud Web Security (CWS)
- облачный Cisco Umbrella (бывший OpenDNS Umbrella) или Secure Internet Gateway (SIG)
- аппаратный или виртуальный межсетевой экран Cisco Firepower (или Cisco ASA и Cisco Meraki MX) с функцией URL Filtering.
Каждое из данных решений позволяет нам фиксировать попытки доступа к тем или иным сайтам, и блокировать их по необходимости. Но делают они это по-разному. Например, Cisco Umbrella мониторит все DNS-запросы из корпоративной сети или с мобильного устройства. А CWS (или его новая реинкарнация Cisco Securу Internet Gateway) пропускает все HTTP/HTTPS-запросы через ближайшее облако, что особо полезно для мобильных сотрудников. WSA и Firepower действуют по схожей с CWS технологии (база категорированных URL), но должны быть установлены на периметре защищаемой сети. Однако этим отличия четырех названных продуктов не ограничиваются. Тот же Firepower помимо URL-фильтрации может обнаруживать вредоносные файлы, загружаемые с посещаемых страниц, а WSA к этому добавляет еще функции анализа и разбора Web-страниц на лету (при их отсутствии в базе URL), а также возможность сканирования страницы до предоставления к ней доступа пользователю и вырезания вредоносного контента или рекламы. А если задача контроля доступа к Web-ресурсам трансформируется в задачу контроля доступа к облачным сервисам (Amazon, Google.Doc, Azure и т.п.) с личных устройств сотрудников, находящихся за пределами корпоративной сети, то тут вступает в игру еще одно решение Cisco — CloudLock, относящееся к классу Cloud Access Security Broker (CASB). Иными словами, решения Cisco по контролю Web-доступа, помимо своей основной функции обладают еще и расширенным функционалом, который и отличает их друг от друга. И именно весь спектр функций решения и стоящая перед заказчиков задача будут влиять на его выбор.
Возьмем другой пример — борьбу с программами-вымогателями, которые пытаются соединиться с командными C2-серверами для подгрузки новой функциональности, получения команд или организации утечки данных. В Cisco такой защитной функциональностью обладают разные решения:
- Система мониторинга сетевых аномалий Cisco Stealthwatch, которая анализирует телеметрию NetFlow и может обнаруживать попытки коммуникаций с командными серверами, идущими даже в обход периметра (через незащищенный Wi-Fi или 3G/4G-модемы).
- Уже упомянутое решение Cisco WSA, которое мониторит исходящие из сети и проходящие через WSA коммуникации на всех 65000 с лишним TCP-портах с целью идентификации попыток соединения с известными C2-серверами.
- Также уже упомянутый Firepower (или ASA, или Meraki MX) контролирует все сетевые соединения и за счет встроенной технологии предотвращения вторжений NGIPS, а также регулярно обновляемых списков C2-серверов, позволяет блокировать соединения с ними.
- Облачный сервис Cisco Umbrella, пропуская через себя весь DNS-трафик, идентифицирует в нем соединения с вредоносными узлами, осуществляемыми как изнутри корпоративной сети, так и за ее пределами — с мобильных устройств или удаленных площадок, неоснащенных вообще никакими средствами защиты.
- Система борьбы с вредоносным кодом Cisco Advanced Malware Protection (AMP) for Networks и for Endpoints контролирует аномальное поведение файлов и их попытки соединиться с посторонними, в т.ч. и вредоносными узлами.
- Решение Cisco Cognitive Threat Analytics позволяет детектировать работу вредоносных программ по следам в Web-логах с прокси или межсетевых экранов.
- Наконец, средство защиты электронной почты Cisco Email Security Appliance не допускает попадания шифровальщика на компьютер пользователя через почтовый ящик (а это до сих пор один из основных каналов заражения пользователей, даже несмотря на историю с WannaCry).
Какое из названных семи решений выбрать для блокирования заражения шифровальщиками и взаимодействия с управляющими серверами вредоносного ПО? Опять же все зависит от того, какие еще задачи с точки зрения информационной безопасности мы хотим решить. Нужна ли нам только борьба с программами-вымогателями или нам нужно решение для защиты периметра “все в одном” (тут лучше подходит Firepower)? А может нам нужна защита мобильных устройств? Тогда Cisco Umbrella будет лучшим выбором. Наконец, если мы не уверены, что весь трафик ходит только через периметр, то нам не обойтись без Cisco Stealthwatch. А скорее всего одним решением тут и вовсе не обойтись и понадобится комплекс из нескольких технологий.
Возьмем еще один пример, с которым пришлось разбираться некоторое время назад. Заказчик приобрел Cisco Web Security Appliance для контроля доступа к сети Интернет, а потом высказал ряд замечаний, которые очень хорошо продемонстрировали описанное выше. Заказчик выбирал продукт, а не решение своей задачи. В процессе “разбора полетов” выяснилось, что заказчику нужна была функция блокирования Skype и Cisco WSA с ней справлялся не очень хорошо. Давайте попробуем разобраться, почему заказчик оказался неудовлетворенным?
Начнем с того, что на момент разбора ситуации Skype был построен по принципу Peer-to-peer и не использовал никаких центральных серверов для своей работы (хотя Microsoft и движется в эту сторону). Поэтому блокировать Skype как это делается при доступе к обычным Web-сайтам (что WSA делает на отлично) нужно умеючи и с пониманием различных методов коммуникаций в Skype:
- использование UDP-соединения с другими абонентами на случайно выбранных номерах портов
- использование TCP-соединения с другими абонентами на случайно выбранных номерах портов
- использование TCP-соединения с другими абонентами на портах 80/443
- туннелирование пакетов через Web-прокси, используя метод HTTP CONNECT на 443-м порту.
Так вот в 1-3 случаях трафик обычно не идет через Cisco WSA и, как следствие, не может быть им блокирован. И это не недостаток WSA, а особенности места его установки в корпоративной сети. В 4-м же сценарии тоже есть свои сложности, связанные с тем, что Skype не передает в рамках HTTP CONNECT никаких деталей о клиенте (нет строки HTTP User-Agent). Поэтому сложно отличить Skype от другого протокола, использующего метод HTTP CONNECT. Мы можем попробовать заблокировать такие соединения, но тогда “под раздачу” попадут все пользователи Skype, а также, возможно, и иные протоколы, использующие схожие методы коммуникаций.
Что же тогда делать? Как нам решить задачу, стоящую перед заказчиком? Как я написал выше, надо отталкиваться именно от задачи, а не продукта, который “вроде как по описанию” решает ее. Опираясь на описанные выше способы коммуникаций, применяемые Skype, у нас есть три кандидата для решения поставленной задачи:
- Cisco Stealthwatch
- Cisco Firepower
- Cisco ISR с функцией NBAR2.
NBAR2 (Network-based Application Recognition) — это функция маршрутизаторов Cisco с операционной системой IOS, которая позволяет распознавать приложения, проходящие через маршрутизатор. С ее помощью можно легко идентифицировать различные виды трафика, в том числе и использующие пиринговые технологии с динамичными портами для соединений (к ним относится и Skype). Для того, чтобы блокировать Skype на обычном маршрутизаторе достатно ввести следующие команды (указав вместо “GigabitEthernet 0/2” правильный интерфейс для контроля трафика):
(config)#class-map match-any blockskype
(config-cmap)#match protocol skype
(config)#policy-map blockskype
(config-pmap)#class blockskype
(config-pmap-c)#drop
(config)#interface GigabitEthernet 0/2
(config-if)#service-policy input blockskype
(config-if)#service-policy output blockskype
Удостовериться в правильности работы включенной вами политики можно командой show policy-map (или show class-map):
1#show policy-map interface g0/2 input
GigabitEthernet0/2
Service-policy input: blockskype
Class-map: blockskype (match-any)
994 packets, 327502 bytes
30 second offered rate 43000 bps, drop rate 43000 bps
Match: protocol skype
994 packets, 327502 bytes
30 second rate 43000 bps
drop
Class-map: class-default (match-any)
195253 packets, 51828774 bytes
30 second offered rate 7282000 bps, drop rate 0 bps
Match: any
У данного метода, правда, есть всего один, но существенный недостаток, — он блокирует весь трафик Skype без разбора. На практике же вам может понадобиться быть более гибким. Например, вы хотите разрешить пользоваться Skype только отдельным пользователям в своей сети, а всем остальным запретить. Или необходимо запретить отдельные функции внутри самого Skype (чаты, голос, видео, передача файлов) и также привязать эти политики к конкретным учетным записям пользователей. Помочь решить задачу в такой постановке не сможет ни Cisco WSA, ни Cisco NBAR2 — только технологии Cisco Firepower (в виде надстройки над МСЭ Cisco ASA, в виде самостоятельного аппаратного или виртуального устройства, или в виде надстройки над маршрутизатором Cisco ISR). Именно это решение позволяет наиболее гибко решить задачу фильтрации Skype по различным атрибутам — время, пользователь, операция в Skype, направление и т.п. Но если пойти еще дальше, то можно запретить запускать приложение Skype на компьютере пользователя, а это можно попробовать сделать и групповыми политиками, и самостоятельными средствами защиты информации, например, Cisco AMP for Endpoints.
Возьмем последний пример, который часто всплывает в разговоре с заказчиками и с которого начинается эта заметка. Заказчики говорят: “Мы хотим блокировать Tor. Ваш МСЭ умеет это делать?” Да, умеет. Только вот Tor блокировать можно не только с помощью МСЭ, хотя это и самый очевидный вариант. Дать на вход МСЭ регулярно обновляемый перечень выходных узлов сети Tor или адреса серверов каталогов и все, можно считать, что проблема решена. Но… Единственный ли это вариант? Конечно нет. Можно блокировать Tor с помощью маршрутизатора Cisco ISR, подав ему на вход список соответствующих адресов, которые затем транслируются в набор ACL. Автоматизировать эту задачу можно с помощью обычного скрипта — https://github.com/RealEnder/cisco-tor-block. А, например, Cisco Stealthwatch может мониторить взаимодействие не только с выходными, но и с входными узлами сети Tor. И на Cisco AMP for Endpoints можно повесить эту задачу. Вариантов масса — нужно понять, что из них лучше будет удовлетворять исходным условиям.
Именно поэтому мы всегда призываем и наших партнеров, и заказчиков четко формулировать свою задачу и говорить не о том, какой продукт Cisco им нужен (хотя бывает и так, что заказчик прекрасно разбирается в нашем портфолио и сам отлично знает, что ему надо), а о том, с какой проблемой они хотят бороться. Иначе у заказчика/партнера может возникнуть неудовлетворенность от решений Cisco, которые якобы неэффективно решают поставленную задачу. Но задачу-то никто и не ставил :-( Часто бывает так, что компания исходя из своего видения приобретает какое-либо решение, а потом оказывается, что оно не справляется с поставленной задачей. Кто в этом случае виноват?
Иными словами, надо отталкиваться от того, что иностранцы называет модным термином “use case” (сценарий использования). Я бы выделил четыре типа таких сценариев, которые имеют место в кибербезопасности:
- нейтрализация определенной угрозы (утечка информации, программы-вымогатели, DDoS-атаки, фишинг и др.)
- защита/блокирование определенной технологии (например, виртуализированный ЦОД или Skype или облако или периметр)
- реализация требований какого-либо нормативного акта или стандарта, включающего требования по кибербезопасности (например, 31-го приказа ФСТЭК или нового ГОСТа Банка России)
- реализация какого-либо процесса в ИБ (например, реагирования на инциденты или security awareness или мониторинга ИБ).
В каждой из этих четырех категорий существует множество сценариев, универсального списка которых не существует (хотя есть наиболее популярные сценарии).
Подходя к концу заметку, я вновь хотел бы вернуться к тому, с чего начал. Чтобы правильно выстроить систему обеспечения информационной безопасности на предприятии необходимо не бежать искать продукт А, Б или В, а сначала составить список исходных данных — решаемые задачи (включая защищаемые процессы, поддерживаемые протоколы и системы, производительность и т.п.), отражаемые угрозы, требования нормативных актов, то есть отталкиваться от сценариев использования. И только поняв это, можно переходить к процессу выбора соответствующего решения (и вновь — не продукта, а именно решения). Удачного вам выбора! А чтобы раскрыть тему use case чуть шире, в следующих статьях мы рассмотрем несколько типовых сценариев.
Автор: alukatsky
