— Добрый день! Я бы хотел получить спецификацию на межсетевой экран 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 Virtual Security Gateway
- Cisco ASA SM for Catalyst.
И поэтому даже на обычный запрос “да нам бы обычный межсетевой экран” мы ответить просто так не можем. Да и не правильно это. Очень важно выбирать средства защиты не из его названия или типа (например, NGFW есть у многих производителей, но вот понимание того, что такое NGFW, у всех разное) или своего представления о продукте, а из решаемой задачи и детального изучения характеристик и функций имеющегося у производителя портфолио. В случае с Cisco, в наших продуктах используется немало перекрестных или схожих по своей сути технологий и правильный их выбор лучше обсуждать с представителями производителя или квалифицированного партнера. Тем более, что мы всегда открыты для консультаций и готовы помогать нашим заказчикам и партнерам.
Поэтому при звонках, аналогичных приведенному выше, мы начинаем “занудствовать” и уточнять, для решения какой задачи заказчику нужен межсетевой экран. Ему нужен межсетевой экран для разграничения доступа на сетевом уровне? Для защиты виртуализированных сред? Для контроля приложений? С привязкой правил к учетным записям пользователей или нет? Для установки на магистральных каналах или на удаленной площадке? А все потому, что портфолио наше по кибербезопасности достаточно широко и банального ответа “купите наш межсетевой экран и будет вам счастье” мы дать поэтому не можем. Мы руководствуемся принципом, что решаемая задача определяет используемый продукт, а не наоборот. Если у других производителей всего один межсетевой экран или одна система обнаружения атак и поэтому они убеждают заказчиков, что “гонять весь трафик, даже внутренний, через периметровый МСЭ — это нормально” или что “поставьте периметровую IDS на каждом транке или SPAN-порту и вы решите свою задачу”, то мы так не работаем. Сначала определяется решаемая задача и (или) модель угроз, а потом уже выбирается под них соответствующее решение, которое может отличаться от изначально предполагаемого заказчиком.
Но давайте попробуем выйти за рамки только межсетевого экрана? У нас ведь номенклатура решений по кибербезопасности гораздо шире и далеко не все можно и нужно решать только с помощью межсетевого экрана. Возьмем, к примеру, задачу контроля доступа к Web-ресурсам. В случае с Cisco решаться она может по-разному. Как минимум 4 продукта позволяют нам контролировать доступ к Интернет-ресурсам:
- аппаратный или виртуальный Cisco Web Security Appliance (WSA)
- облачный (CWS)
- облачный Cisco Umbrella (бывший OpenDNS Umbrella) или Secure Internet Gateway (SIG)
- аппаратный или виртуальный межсетевой экран Cisco Firepower (или Cisco ASA и Cisco Meraki MX) с функцией URL Filtering.
Возьмем другой пример — борьбу с программами-вымогателями, которые пытаются соединиться с командными C2-серверами для подгрузки новой функциональности, получения команд или организации утечки данных. В Cisco такой защитной функциональностью обладают разные решения:
- Система мониторинга сетевых аномалий , которая анализирует телеметрию NetFlow и может обнаруживать попытки коммуникаций с командными серверами, идущими даже в обход периметра (через незащищенный Wi-Fi или 3G/4G-модемы).
- Уже упомянутое решение Cisco WSA, которое мониторит исходящие из сети и проходящие через WSA коммуникации на всех 65000 с лишним TCP-портах с целью идентификации попыток соединения с известными C2-серверами.
- Также уже упомянутый Firepower (или ASA, или Meraki MX) контролирует все сетевые соединения и за счет встроенной технологии предотвращения вторжений NGIPS, а также регулярно обновляемых списков C2-серверов, позволяет блокировать соединения с ними.
- Облачный сервис Cisco Umbrella, пропуская через себя весь DNS-трафик, идентифицирует в нем соединения с вредоносными узлами, осуществляемыми как изнутри корпоративной сети, так и за ее пределами — с мобильных устройств или удаленных площадок, неоснащенных вообще никакими средствами защиты.
- Система борьбы с вредоносным кодом (AMP) for Networks и for Endpoints контролирует аномальное поведение файлов и их попытки соединиться с посторонними, в т.ч. и вредоносными узлами.
- Решение позволяет детектировать работу вредоносных программ по следам в Web-логах с прокси или межсетевых экранов.
- Наконец, средство защиты электронной почты не допускает попадания шифровальщика на компьютер пользователя через почтовый ящик (а это до сих пор один из основных каналов заражения пользователей, даже несмотря на историю с ).
Возьмем еще один пример, с которым пришлось разбираться некоторое время назад. Заказчик приобрел 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-м порту.
Что же тогда делать? Как нам решить задачу, стоящую перед заказчиком? Как я написал выше, надо отталкиваться именно от задачи, а не продукта, который “вроде как по описанию” решает ее. Опираясь на описанные выше способы коммуникаций, применяемые Skype, у нас есть три кандидата для решения поставленной задачи:
- Cisco Stealthwatch
- Cisco Firepower
- Cisco ISR с функцией NBAR2.
(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. Автоматизировать эту задачу можно с помощью обычного скрипта — . А, например, Cisco Stealthwatch может мониторить взаимодействие не только с выходными, но и с входными узлами сети Tor. И на Cisco AMP for Endpoints можно повесить эту задачу. Вариантов масса — нужно понять, что из них лучше будет удовлетворять исходным условиям.
Именно поэтому мы всегда призываем и наших партнеров, и заказчиков четко формулировать свою задачу и говорить не о том, какой продукт Cisco им нужен (хотя бывает и так, что заказчик прекрасно разбирается в нашем портфолио и сам отлично знает, что ему надо), а о том, с какой проблемой они хотят бороться. Иначе у заказчика/партнера может возникнуть неудовлетворенность от решений Cisco, которые якобы неэффективно решают поставленную задачу. Но задачу-то никто и не ставил :-( Часто бывает так, что компания исходя из своего видения приобретает какое-либо решение, а потом оказывается, что оно не справляется с поставленной задачей. Кто в этом случае виноват?
Иными словами, надо отталкиваться от того, что иностранцы называет модным термином “use case” (сценарий использования). Я бы выделил четыре типа таких сценариев, которые имеют место в кибербезопасности:
- нейтрализация определенной угрозы (утечка информации, программы-вымогатели, DDoS-атаки, фишинг и др.)
- защита/блокирование определенной технологии (например, виртуализированный ЦОД или Skype или облако или периметр)
- реализация требований какого-либо нормативного акта или стандарта, включающего требования по кибербезопасности (например, 31-го приказа ФСТЭК или нового ГОСТа Банка России)
- реализация какого-либо процесса в ИБ (например, реагирования на инциденты или security awareness или мониторинга ИБ).
Подходя к концу заметку, я вновь хотел бы вернуться к тому, с чего начал. Чтобы правильно выстроить систему обеспечения информационной безопасности на предприятии необходимо не бежать искать продукт А, Б или В, а сначала составить список исходных данных — решаемые задачи (включая защищаемые процессы, поддерживаемые протоколы и системы, производительность и т.п.), отражаемые угрозы, требования нормативных актов, то есть отталкиваться от сценариев использования. И только поняв это, можно переходить к процессу выбора соответствующего решения (и вновь — не продукта, а именно решения). Удачного вам выбора! А чтобы раскрыть тему use case чуть шире, в следующих статьях мы рассмотрем несколько типовых сценариев.
