Отчет Cisco с результатами глобального опроса директоров по информационной безопасности 2020

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

Мы опросили 2800 руководителей служб ИБ и ИТ в различных индустриях, чтобы определить 20 основных факторов, которые будут влиять на информационную безопасность в 2020 году — ссылка

Другие отчеты по кибербезопасности по этой ссылке

Cisco AnyConnect — намного больше, чем VPN-клиент

На прошлой неделе вышла у меня дискуссия на тему удаленного доступа и различных VPN-клиентов, которые можно поставить на рабочее место сотрудника, отправляемого работать домой. Один коллега отстаивал «патриотическую» позицию, что надо использовать «абонентские пункты» к отечественным шифраторам. Другой настаивал на применении клиентов от зарубежных VPN-решений. Я же придерживался третьей позиции, которая заключается в том, что такое решение не должно быть придатком периметрового шифратора и даже не клиентской частью VPN-шлюза. Даже на производительном компьютере не совсем правильно ставить несколько защитных клиентов, которые будут решать разные задачи — VPN, идентификация/аутентификация, защищенный доступ, оценка соответствия и т.п. Идеально, когда все эти функции, а также иные, объединены в рамках единого клиента, что снижает нагрузку на систему, а также вероятность несовместимости между различным защитным ПО. Одним из таких клиентов является Cisco AnyConnect, о возможностях которого я бы и хотел вкратце рассказать.

image

Cisco AnyConnect является логичным развитием Cisco VPN Client, который за много лет не только был русифицирован, но и обогатился множеством различных функций и возможностей для защищенного удаленного доступа к корпоративной или облачной инфраструктуре с помощью одного из трех протоколов — TLS, DTLS и IPSec (поддерживается также FlexVPN). Первый из них является достаточно традиционным для VPN-клиентов и использует TCP как транспортный для своей работы. Однако туннелирование через TLS означает, что приложения, основанные на TCP, будут его дублировать (один раз для организации TLS, второй — для своей работы уже внутри TLS). А протоколы на базе UDP будут… все равно использовать TCP. Это может привести к определенным задержкам, например, для мультимедиа-приложений, которые являются очень популярными при удаленной работе. Решением этой проблемы стала разработка протокола DTLS, который вместо TCP задействует UDP для работы TLS. AnyConnect поддерживает обе реализации TLS — на базе TCP и UDP, что позволяет гибко их использовать в зависимости от условий удаленной работы. Обычно TCP/443 или UDP/443 разрешены на межсетевых экранах или прокси и поэтому использование TLS и DTLS не составляет большой проблемы. Но в ряде случаев может потребоваться применение протокола IPSec, который также поддерживается AnyConnect’ом (IPSec/IKEv2).

image

А на каких устройствах может терминироваться VPN-туннель, создаваемый AnyConnect? Я просто их перечислю:

  • Межсетевые экраны Cisco ASA 5500 и Cisco ASA 5500-X
  • Многофункциональные защитные устройства Cisco Firepower
  • Виртуальные МСЭ Cisco ASAv и Cisco ASAv в AWS и Azure
  • Маршрутизаторы Cisco ISR 800/1000/4000 и ASR 1000 c сетевой ОС Cisco IOS или Cisco IOS XE
  • Виртуальные маршрутизаторы Cisco CSR 1000v, а они развернуты в том числе и ряда российских облачных провайдеров.

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

image

Интересно, что в отличие от многих других VPN-клиентов, у вас существует множество вариантов инсталляции Cisco AnyConnect на персональный компьютер или мобильное устройство ваших работников. Если вы выдаете им такие устройства из собственных запасов или специально покупаете для сотрудников ноутбуки, то вы можете просто предустановить защитного клиента вместо с остальным ПО, требуемым для удаленной работы. Но что делать для пользователей, которые находятся далеко от корпоративных ИТ-специалистов и не могут предоставить им свой ноутбук для установки нужного ПО? Можно, конечно, задействовать и специализированное ПО типа SMS, SCCM или Microsoft Installer, но у Cisco AnyConnect есть и другой способ установки — при обращении к упомянутому VPN-шлюзу клиент сам скачивается на компьютер пользователя, работающий под управлением Windows, Linux или macOS. Это позволяет быстро развернуть VPN-сеть даже на личных устройствах работников, отправленных на удаленную работу. Мобильные же пользователи могут просто скачать Cisco AnyConnect из Apple AppStore или Google Play.

image

Но как я уже выше написал, Cisco AnyConnect, это не просто VPN-клиент, это гораздо больше. Но я бы не хотел переписывать здесь документацию на него, а попробовать описать ключевые функции в режиме вопросов и ответов на них (FAQ).

А как я могу гарантировать, что домашний пользователь не подцепит ничего в Интернет?

В AnyConnect есть такая функция — Always-On VPN, которая предотвращает прямой доступ в Интернет, если пользователь не находится в так называемой доверенной сети, которой может быть ваша корпоративная инфраструктура. Но обратите внимание, что данная функция работает очень гибко. Если пользователь находится в корпоративной сети, VPN автоматически отключается, а при ее покидании (например, если пользователь работает с ноутбука, планшета или смартфона), VPN опять включается; причем прозрачно и незаметно для пользователя. Тем самым пользователь всегда будет находиться под защитой корпоративных средств защиты, установленных на периметре, — межсетевого экрана, системы предотвращения вторжений, системы анализа аномалий, прокси и т.п. Многие компании, выдавая удаленным работникам корпоративные устройства, ставят условие использования их только для служебных целей. А чтобы контролировать исполнение этого требования включают в AnyConnect настройки, запрещающие пользователю ходить в Интернет напрямую.

image

А могу ли я шифровать не весь трафик, а только корпоративный?

Функция Always-On VPN очень полезна для защиты удаленного доступа с выданных вами устройств, но далеко не всегда мы можем заставить пользователя делать то, что хотим мы, особенно если речь идет о его личном компьютере, на котором мы не можем устанавливать свои правила. И пользователь не захочет, чтобы его личный трафик проходил через корпоративный периметр и ваши администраторы следили за тем, какие сайты пользователь посещает во время надомной работы. Как говорится, «сложно говорить о морали с администратором, который видел логи вашего прокси» 🙂

В этом случае на Cisco AnyConnect можно включить функцию split tunneling, то есть разделения туннелей. Одни виды трафика, например, до корпоративной инфраструктуры и рабочих облаков трафик будет шифроваться, а трафик до соцсетей или онлайн-кинотеатров будет идти в обычном режиме, без защиты со стороны AnyConnect. Это позволяет учесть интересы и компании и ее работников, вынужденных делить персональный компьютер сотрудника между двумя областями жизни — личной и служебной. Но стоит помнить, что функция split tunneling может снизить защищенность вашей сети, так как пользователь может подцепить какую-нибудь заразу в Интернет, а потом уже по защищенному каналу она попадет в внутрь компании.

image

А могу ли я шифровать трафик определенных, например, корпоративных, приложений?

Помимо разделения трафика по принципу «доверенный/недоверенный», Cisco AnyConnect поддерживает функцию Per App VPN, которая позволяет шифровать трафик отдельных приложений (даже на мобильных устройствах). Это позволяет шифровать (читай, пускать в корпоративную сеть) только определенные приложения, например, 1C, SAP, Sharepoint, Oracle, а тот же Facebook, LinkedIn или персональный Office365 пускать в обход корпоративного периметра. При этом для разных групп удаленных устройств или пользователей могут быть свои правила безопасности.

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

С одной стороны Cisco AnyConnect может проверять наличие у вас системы защиты Cisco AMP for Endpoints и устанавливать ее при отсутствии. Но возможно у пользователя уже установлен собственный антивирус или этот антивирус уже был установлен вами при переводе работников на удаленную работу. Однако все мы знаем, что антивирус сегодня ловит очень мало серьезных угроз и неплохо бы дополнить его более продвинутыми решениями по обнаружению вредоносных программ, аномалий и иных атак. Если в вашей корпоративной инфраструктуре развернуто решение Cisco Stealthwatch, то вы можете легко интегрировать с ним и агенты Cisco AnyConnect, установленные на домашних компьютерах ваших работников. В AnyConnect встроен специальный модуль Network Visibility Module (NVM), который транслирует активность узла в специально разработанный для этой задачи протокол nvzFlow, который дополняет ее дополнительной информацией и передает на Netflow-коллектор, которым может являться как Cisco Stealthwatch Enterprise, так и какой-либо SIEM, например, Splunk. Среди прочего NVM-модуль может передавать следующую информацию, на базе которой можно выявлять аномальную и вредоносную активность на домашнем компьютере, которая осталась незаметной для установленного антивируса:

  • данные сетевой активности в схожем с IPFIX формате
  • идентификатор, адрес и имя устройства
  • имя пользователя
  • тип учетной записи пользователя
  • имена и идентификаторы запускаемых процессов и приложений, включая и данные по их «родителям».

Данный функционал по сути представляет собой облегченную UEBA (User Entity Behaviour Analytics), новую технологию анализа поведения пользователей и приложений/процессов, запускаемых от их имени.

А как мне аутентифицировать пользователей?

Когда пользователи работают на корпоративных компьютерах, то они проходят аутентификацию обычно в Active Directory или ином LDAP-справочнике. Хочется получить такую же возможность и при удаленном доступе и Cisco AnyConnect позволяет ее реализовать за счет поддержки аутентификации по логину/паролю, включая и одноразовые пароли (например, LinOTP), пользовательским или машинным сертификатам, аппаратным токенам (например, смарт-картам или Yubikey), и даже биометрии и иным способам многофакторной аутентификации. Все эти варианты могут быть легко интегрированы с вашими решениями по управлению идентификацией и аутентификацией с помощью протоколов RADIUS, RSA SecurID, SAML, Kerberos и т.п.

image

А если я использую облачные платформы, например, Amazon AWS или MS Azure, то как мне защитить доступ домашних пользователей к ним?

У Cisco существует виртуальный маршрутизатор Cisco CSR 1000, который может быть развернут в облачных средах, например, в Amazon AWS или MS Azure, и который может терминировать на себе VPN-туннели, создаваемые Cisco AnyConnect.

Если пользователь работает с личного устройства, то как мне повысить защищенность своей сети при таком доступе?

Давайте попробуем прикинуть, что может плохого или неправильного сделать пользователь на компьютере при удаленной работе? Установить ПО, содержащее уязвимости, или просто не устранять их своевременно с помощью патчей. Не обновлять свой антивирус или вообще его не иметь. Использовать слабые пароли. Установить ПО с вредоносным функционалом. Это то, что может поставить вашу корпоративную сеть под угрозу и никакой VPN вас не защитит от этого. А вот Cisco AnyConnect может за счет функции оценки соответствия, которая позволяет перед предоставлением доступа удаленного компьютера к корпоративным ресурсам проверить все необходимые и требуемые ИТ/ИБ-политиками настройки — наличие патчей, актуальные версии ПО, обновленный антивирус, наличие средств защиты, правильную длину пароля, наличие шифрования жесткого диска, определенные настройки реестра и т.п. Реализуется данная возможность либо с помощью функции Host Scan (для этого нужна Cisco ASA в качестве шлюза удаленного доступа), либо с помощью функции System Scan, которая обеспечивается с помощью системы контроля сетевого доступа Cisco ISE.

image

А если я работаю с планшета или смартфона и постоянно перемещаюсь. У меня будет рваться VPN-соединение и мне надо будет каждый раз устанавливать его заново?

Нет, не надо. В Cisco AnyConnect встроен специальный роуминговый модуль, который позволяет не только автоматически и прозрачно переподключать VPN при переходе между различными типами подключений (3G/4G, Wi-Fi и т.п.), но и автоматически защищать ваше мобильное (ведь вряд ли вы будете носить с собой стационарный домашний компьютер) устройство с помощью решения Cisco Umbrella, которое будет инспектировать весь DNS-трафик на предмет доступа к фишинговым сайтам, командным серверам, ботнетам и т.п. Подключение к Umbrella потребуется в том случае, если вы разрешили пользователю функцию split tunneling и он может подключаться к различным ресурсам Интернет напрямую, минуя шлюз удаленного доступа. Модуль подключения к Cisco Umbrella будет полезен даже в том случае если вы не используете VPN — тогда весь трафик будет проверяться через этот защитный сервис.

image

А ваш AnyConnect не снизит качество видео- и голосовых телеконференций?

Нет. Как я уже описывал выше, Cisco AnyConnect поддерживает протокол DTLS, который специально ориентирован на защиту мультимедиа-трафика.

На самом деле Cisco AnyConnect обладает куда большим количеством возможностей. Он может работать в скрытом режиме, динамически выбирать наиболее оптимальный шлюз удаленного доступа, поддерживает IPv6, имеет встроенный персональный межсетевой экран, мониторится удаленно, обеспечивает контроль доступа, поддерживает RDP и т.п. А еще он русифицирован, чтобы у пользователей не возникало вопросов относительно тех редких сообщений, которые Cisco AnyConnect может выдавать. Так что Cisco AnyConnect — это не просто VPN-клиент, но гораздо более интересное решение для обеспечения защищенного удаленного доступа, который в последние недели начинает набирать популярность из-за пандемии коронавируса, заставляющего работодателей переводить отдельные категории своих работников на удаленку.


Источник: https://habr.com/ru/company/cisco/blog/493590/

Автор: Алексей Лукацкий


 

Правильный выбор СрЗИ: от рекламных листовок к use case

Раздается недавно звонок:
— Добрый день! Я бы хотел получить спецификацию на межсетевой экран 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 ситуация немного иная. Начнем с того, что у нас тех же самых межсетевых экранов семь:

И это если не рассматривать снятый с производства 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 чуть шире, в следующих статьях мы рассмотрем несколько типовых сценариев.


Источник: https://habr.com/ru/company/cisco/blog/337900/ 

Автор:


 

Как CISCO анализирует зашифрованный трафик без его расшифрования и дешифрования

В чем проблема?

Сейчас, по оценкам Cisco, 60% трафика в Интернет зашифровано, а согласно прогнозам Gartner к 2019-му уже 80% трафика будет таковым. С одной стороны это хорошо. Это надо для обеспечения приватности граждан, для выполнения требований законодательства, для сохранения тайн в секрете. Но у шифрования есть и обратная сторона. Его также используют и злоумышленники, скрывая взаимодействие с командными серверами вредоносных программ и для других задач. Согласно отчету Ponemon Institute за 2016 год, почти половина (41%) злоумышленников используют шифрование для обхода механизмов детектирования их несанкционированной активности.

 

Как решить эту проблему?

С одной стороны средства защиты не могут видеть, что происходит в зашифрованном трафике – по данным Ponemon Institute 64% компаний не могут детектировать вредоносный код в зашифрованном трафике. Но существует классический подход, который часто используется ИБ-производителями и государствами для проникновения в зашифрованные соединения. Речь идет об атаке Man-in-the-Middle (MITM), которую осуществляют в легальных целях. Обычно на периметре корпоративной или ведомственной сети или на границе государства устанавливает шлюз или кластер из шлюзов, которые и осуществляют “перехват” и расшифрование трафика. Такой способ применяется по данным Ponemon Institute только 38% компаний, но и у него есть проблемы. Это и его легальность (никто не давал вам права нарушать тайну переписки или иные требования законодательства по обеспечению конфиденцильности информации), и место внедрения (на MITM-шлюз надо направлять весь трафик, иначе этот метод дает сбой и не позволяет увидеть трафик), и стоимость (это существенно удорожает систему безопасности), и производительность (MITM-шлюзы должны работать на скорости потока, что не всегда возможно, так как криптографическая обработка сама по себе снижает пропускную способность).

А можно ли распознавать вредоносную активность, не прибегая к расшифрованию или дешифрованию (второе отличается от первого отсутствием ключей шифрования)? Оказывается можно. Мы разработали технологию под названием ETA (Encrypted Traffic Analytics), которая позволяет, опираясь на сетевую телеметрию, получаемую с сетевого оборудования, и алгоритмы машинного обучения, классифицировать зашифрованный трафик, попутно отделяя в нем чистый трафик от вредоносного.

 

Cisco ETA

Наша идея заключается в том, что мы оперируем не полем данных в зашифрованным пакете, а его заголовком. Казалось бы, как можно по заголовку понять, что внутри зашифрованного трафика действует какая-то вредоносная программа? Оказывается можно. Мы используем расширенную телеметрию в виде следующих данных, которые можно брать из сетевого трафика:

  • из Netflow – адреса и порты источника и получателя (SrcIP, DstIP, SrcPort, DstPort), информацию о протоколе, количество переданных пкетов и байтов;
  • внутрипотоковые – размеры пакетов & временные параметры, распределение байтов (встречаемость в потоке) и их энтропию (чем она выше, тем выше ожидание увидеть именно зашифрованный трафик);
  • из метаданных TLS – расширения, наборы криптографических алгоритмов, SNI, поля сертификатов;
  • из DNS – имена доменов, типы запросов, временные параметры запросов;
  • из HTTP – заголовки и сопутствующие поля, в том числе других http-запросов с этого же хоста.

Обратите внимание, данных для каждого потока мы берем достаточно много. В этом залог успеха классификации вредоносного трафика. Опираясь только на один из описанных параметров телеметрии, эффективность распознавания будет гораздо ниже, превращая саму идею “в тыкву”. Второй слагаемой успеха Cisco ETA является машинное обучение, на вход которого подавался трафик, используемый для классификации. Разработанные нами алгоритмы позволяли обучиться на десятках тысяч потоков как известного вредоносного кода, так и чистого трафика.

Вредоносный трафик мы брали с сервиса-песочницы Cisco AMP Threat Grid, который позволяет не только получать на выходе полноценный анализ вредоносного кода, но и сгенерить по нему pcap-файл (кстати, наше подразделение Cisco Talos разработало специальную open source утилиту file2pcap, которая транслирует любой файл в трафик HTTP/HTTP2/FTP/SMTP/IMAP/POP3 в виде pcap-файла). За основу мы брали стопроцентно вредоносный код с 100-балльным уровнем угрозы по 100-балльной шкале. Каждый pcap-файл содержал пятиминутную сессию, а всего таких файлов было подано на вход разработанных нами специальных алгоритмов несколько миллионов. Анализ продолжался с августа 2015 по май 2016 года.

Утилита, используемая при изучении зашифрованного трафика с помощью машинного обучения

На первом тестовом наборе данных мы опирались в первую очередь на размеры пакетов и временные параметры (SPLT, Sequence of Packet Lengths and Arrival Times), распределение байтов (BD, Byte Distribution) и их энтропию (BE, Byte Entropy) в заголовках сетевого трафика, а также на метаданные TLS. Результаты распознавания и классификации вредоносного ПО оказались неплохими, но явно недостаточными.

На втором тестовом наборе мы добавили контекстную информацию из трафика DNS (в том числе наличие домена в списке Alexa, длина имени домена и FQDN, суффикс, TTL, % цифр в имени домена, % не буквенночисловых символов в имени домена) и HTTP (в том числе поля заголовка запроса/ответа, Content-Type, User-Agent, Accept-Language, HTTP-сервер, код возврата). В итоге, комбинируя различные параметры, мы добились точности распознавания вредоносного кода в зашифрованном трафике на уровне трех девяток (99.9%).

Анализ большого объема данных вредоносных программ различных семейств с помощью технологии Cisco ETA показал, что они часто используют схожие свойства и параметры, которые и позволяют их идентифицировать с высокой точностью:

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

Распределение длин ключей шифрования в процессе исследования

  • используемые TLS-сервера (мы ориентировались в первую очередь на TLS-трафик, но для устаревшего SSL идея будет схожая);
  • тип сертификата (например, выяснилось, что самоподписанные сертификаты используются вредоносным ПО с вероятностью 0.7, в то время как у легальных приложений в корпоративной сети этот показатель равен 0.09);
  • самым часто выбираемым криптографическим набором является TLS_RSA_WITH_RC4_128_SHA;

Обнаруженные в процессе 1 часа исследования криптографические наборы (700+ тысяч потоков)

  • различное использование заглавных и прописных букв (иногда с опечатками) в заголовке HTTP (User-Agent vs user agent vs User-agent vs USER-AGENT vs User-AgEnt);
  • распространённые значения User-Agent (например, Opera/9.50(WindowsNT6.0;U;en) или Mozilla/5.0(Windows;U;WindowsNT5.1;en-US;rv:1.9.2.3)Gecko/20100401Firefox/3.6.1(.NETCLR3.5.30731));
  • значения TTL в DNS-запросах (чаще всего – 3600);
  • домены, к которым идет обращение (около 95% доменов отсутствует в списке Alexa top-1,000,000);
  • тип HTTP-сервера (чаще всего – nginx);
  • и т.д.

Да, эти параметры (и их комбинации) сильно зависят от того, какое вредоносное ПО их использует. И они могут меняться. Но применение машинного обучения на большой выборке (а через Cisco AMP Threat Grid ежедневно проходит около 18 миллиардов файлов, из которых 1,5 миллиона вредоносных) все равно позволяет находить общие классификационные признаки и закладывать это знание в Cisco ETA.

Визуализация обнаружения зашифрованного трафика

Также в процессе тестированы Cisco ETA мы получили и ряд побочных эффектов. Например, мы смогли распознавать TLS на нестандартных портах, отличающихся от обычного 443-го. Были и нестандартные находки. Например, с помощью нашего классификатора мы смогли распознать на выборке из 80 тысяч потоков (при увеличении выборки точност распознавания должна вырасти еще больше) TLS поверх DNS, что в обычной жизни бывает нечасто, но может использоваться тем же вредоносным кодом, скрывающим свою активность в рамках разрешенного на периметре DNS.

Машинное обучение помогло обнаружить TLS over DNS

 

Что надо для работы?

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

  • Сетевое оборудование, поддерживающее Netflow и технологию ETA. Сейчас это коммутаторы Cisco Catalyst 9000 (начиная с версии IOS XE 16.6.1) и маршрутизаторы Cisco ASR 1000, ISR 4000, CSR, ISRv (начиная с версии IOS XE 16.6.2), но поддержка ETA в скором времени появится и в других устройствах Cisco. Если ваша сеть уже построена на базе инфраструктуры Cisco, то возможно вам понадобится только проапгрейдить ПО на коммутаторах и маршрутизаторах.
  • Система мониторинга сетевых аномалий Cisco Stealthwatch (начиная с версии 6.9.2), которая получает данные Netflow от существующего сетевого оборудования и которая проводит анализ и классификацию трафика, распознавая в нем признаки вредоносного кода. Стоит отдельно отметить, что Cisco Stealthwatch работает с несемплированным Netflow-трафиком, который позволяет увидеть гораздо больше, чем решения, ориентированные только на семплированный Netflow. Разница между этими двумя видами Netflow, – это как читать книгу целиком (несемплированный трафик) или каждую 10-ю страницу (семплированный трафик).

Stealthwatch с ETA

  • Облачный движок Cisco Cognitive Threat Analytics (является частью решения Cisco Stealthwatch и не требует отдельной покупки), который дополняет анализ Netflow анализом метаданных TLS, HTTP и DNS. Нужные метаданные (не весь трафик) направляются в CTA, который после анализа возвращает ответ, используемый Cisco Stealthwatch для принятия финального вердикта и его отображения.

Интеграция Stealthwatch с CTA

Cognitive Threat Analytics проводит глубокий анализ Web-логов с помощью машинного обучения

 

Выводы

Процент вредоносного ПО, использующего шифрование, по данным Cisco AMP Threat Grid крутится сегодня вокруг отметки в 25% и это число растет. При этом по нашим наблюдениям от 7 до 13% вредоносного кода использует сегодня для шифрования протокол TLS. По оценкам Gartner к 2019-му году уже половина вредоносных кампаний будет использовать шифрование (как следствие возрастет и процент применения TLS). Традиционные средства сетевой безопасности (IDS/IPS/NGFW/Load Balancer) пасуют перед этой проблемой. В компании Cisco мы разработали новую технологию Cisco ETA, которая использует расширенную телеметрию и алгоритмы машинного обучения для обнаружения и классификации вредоносного кода без расшифрования зашифрованных коммуникаций с эффективностью выше 99%. Да, это не панацея. Но это метод снижения ложных срабатываний и повышения эффективности обнаружения вредоносов в корпоративной сети, что уже немало в современных условиях. Особенно учитывая, что данное решение не требует дополнительных инвестиций и уже встроено в наше сетевое оборудование.

Эффективность работы Cisco ETA на разных комбинациях телеметрических данных

Дополнительная информация:


Источник: http://cs.co/6275Dz8rP

Автор:


 

Новые гибкие платформы решили проблему нехватки процессоров и памяти

Уже ни для кого не секрет, что развитие любой технологии идет по спирали. С каждым новым витком решения становятся мощнее, надежнее, проще, решая при этом новые, «хорошо забытые старые» задачи. И очень хорошо, когда у производителя получается нащупать правильный баланс между новыми веяниями и зарекомендовавшими себя решениями. С этой точки зрения очень показателен 10-летний опыт компании Cisco на рынке вычислительных систем.

 

Гиперконвергенция – что это и зачем?

Первые серверы Cisco UCS появились на рынке в конце 2009 г., когда основным трендом была консолидация вычислительных ресурсов в ЦОД и активно внедрялись технологии виртуализации. Основная задача, на решение которой были тогда брошены все силы, заключалась в оптимизации подключений серверов к сетям (LAN, SAN, управления) и упрощении настройки пула серверов, выполняющих однотипные задачи. Решение получилось настолько мощным и элегантным, что всего за 5 лет блейд-решения Cisco UCS вышли на второе место в мире по объему продаж (это на полностью новом для компании рынке, на котором многие игроки присутствовали на тот момент более 10 лет!). Немалую популярность серверным решениям от Cisco обеспечил конвергентный подход, при котором в рамках одного инфраструктурного «кубика» объединялись серверы Cisco UCS, система хранения Netapp и универсальные коммутаторы для ЦОД семейства Nexus 5000. Такое совместное решение получило название FlexPod, оно и сегодня не теряет своей популярности, пережив смену пяти поколений серверов UCS и несколько поколений дисковых массивов NetApp.

Основное преимущество, за которое заказчики Cisco полюбили конвергентные решения (а на текущий момент их существует около десятка, с разными производителями дисковых массивов) – это простота, надежность и предсказуемость в эксплуатации. По данным одного из исследований компании IDC от 2016 г., когда конвергентные системы еще учитывались отдельно, более 70% продаваемых конвергентных решений для ЦОД были построены на серверах Cisco UCS.

Но прогресс не стоит на месте, и последние несколько лет рынок начал завоевывать новый подход к построению ИТ-инфраструктур – гиперконвергенция. Новое поколение молодых компаний предложило подход, при котором внешняя система хранения не нужна вообще. И хранение и обработка данных происходят на одних и тех же серверах, заполненных дисками, процессорами и оперативной памятью. Отказоустойчивость обеспечивается хранением нескольких копий одних и тех же данных на разных серверах, поэтому не страшно, если один их узлов выйдет из строя, данные не пропадут и виртуальная машина может быть перезапущена на соседнем сервере. Новый подход поначалу настороженно воспринимался традиционными производителями серверов (к числу которых к концу 2015 г. компания Cisco могла себя уверенно причислять). Однако заказчикам гиперконвергенция понравилась, в первую очередь за простоту внедрения и расширения. О производительности и удобстве эксплуатации тогда еще мало кто думал, предлагаемые на тот момент решения проигрывали по этим параметрам конвергентным аналогам. Компания Cisco вышла на рынок гиперконвергентных решений с продуктом Cisco Hyperflex в 2016 г. через партнерство с компанией SpringPath, производителя самой продвинутой на тот момент объектно-ориентированной программно-определяемой системы хранения. И тут выяснилось, что все преимущества аппаратной платформы Cisco UCS позволяют получить существенный выигрыш в производительности и простоте эксплуатации гиперконвергентных решений. Накопленный за два с небольшим года опыт продаж Hyperflex и более чем 3,5 тыс. заказчиков по всему миру свидетельствуют о зрелости этого подхода. Давайте разберемся, что же собой представляет Cisco Hyperflex и для каких задач его нужно применять уже сегодня.

 

Технологический обзор. А что нового?

Про внутреннее устройство платформы Cisco Hyperflex уже сказано немало, отметим лишь, что система состоит из двух обязательных компонентов и одного опционального:

Первый – кластер данных (Data cluster, обязательный компонент) – это набор узлов, обеспечивающих хранение данных и запуск виртуальных машин. Узлы строятся на базе серверов C220 и C240 и представляют собой фиксированные конфигурации указанных серверов с префиксом HX. Единственными параметрами, которые можно менять, являются процессоры, память и диски для хранения данных, то есть все, что определяет «вычислительные ресурсы» кластера. Минимальное количество таких узлов в рамках одного кластера данных – три. Начиная с версии HX Data platform 4.0, выход которой ожидается в апреле 2019 г., анонсировано уменьшение минимальной конфигурации кластера Hyperflex Edge до двух узлов.

Второй – вычислительная фабрика (Fabric interconnect, обязательный компонент, кроме конфигурации Hyperflex Edge) – это пара специализированных устройств, выполняющих функции сетевого ядра системы и, одновременно, модуля управления серверами и внешними подключениями. Это ключевой элемент инфраструктуры Cisco UCS, благодаря фабрике все серверы UCS, сколько бы их ни было, настраиваются по единому шаблону, в один клик мышки или один вызов API функции (да-да, управление аппаратной платформой UCS возможно через открытый API) и полностью автоматически. Более того, система сама следит за тем, чтобы все серверы в кластере имели идентичные настройки, сама по команде администратора в автоматизированном режиме обновляет прошивки и так далее. С Fabric Interconnect весь кластер серверов становится единым объектом управления, таких возможностей на сегодняшний день нет ни у одного производителя серверных решений. Сегодня доступны два семейства Fabric Interconnect 6300 серии с портами 40 Гбит/с и 6400 серии с портами 10/25 Гбит/с. Оба семейства имеют модели в портами FC для подключения к сетями SAN, это дает возможность использовать для хранения данных внешние дисковые массивы тоже.

Третий – вычислительные узлы (Compute-only nodes, необязательный компонент). Часто при расширении гиперконвергентной системы возникает ситуация, когда дискового пространства уже достаточно, а вот процессоров и памяти под текущие задачи не хватает. Бывает и наоборот, но эту проблему легко решить добавлением дисков в серверы или, если они заполнены – внешнего дискового массива к вычислительной фабрике. На случай нехватки в кластере вычислительных ресурсов предусмотрен режим расширения через добавление вычислительных узлов. В качестве таких узлов могут выступать любые серверы Cisco UCS, подключенные к фабрике, неважно – в стоечном или блейд-исполнении. Кроме гибкости в планировании ресурсов, основным преимуществом данного подхода является возможность дать «вторую жизнь» серверам, работавшим в традиционной, конвергентной системе, после того, как их вычислительная нагрузка мигрировала на Hyperflex. Вторым популярным сценарием является подключение в кластер 4-процессорного сервера C480, в который можно установить до шести графических ускорителей (GPU) для «тяжелых» VDI-решений.

Общая схема кластера Hyperflex с обозначением всех указанных компонентов

Важным свойством платформы Hyperflex является то, что без изменения архитектурного подхода и без перепроектирования, на этой платформе можно строить кластера виртуализации от трех до нескольких десятков серверов. Все необходимые процедуры по настройке нового сервера и включения его в кластер полностью автоматизированы, пользователю достаточно только включить сервер и подтвердить системе свое желание на ввод его в состав кластера. Это открывает перед системой самый широкий диапазон применений – от локальных серверных в удаленных офисах, складах, магазинах, до центральных дата-центров с основными сервисами компании. И все это – на базе единой платформы, единых принципах управления, автоматизации и, что немаловажно, – на базе решений единого вендора. Последний факт дает еще одно преимущество – техническая поддержка Cisco Hyperflex целиком и полностью обеспечивается компанией Cisco по схеме «единого окна». Даже если проблема будет связана с функционированием платформы виртуализации (на сегодняшний день поддерживаются VMware, Hyper-V и Docker), решением этой проблемы для заказчика будет заниматься техническая поддержка Cisco.

 

Для каких задач эта система?

Давайте рассмотрим, под какие задачи позиционируется сегодня Cisco Hyperflex. Изначально гиперконвергентные системы лучше всего показывали себя на задачах виртуализации рабочих мест (VDI). Это логично, учитывая архитектуру подсистемы хранения – множество отдельных дисков, распределенных по серверам. Если нагрузок тоже много и каждая из них сама по себе небольшая – получаем идеальное равномерное распределение операций ввода-вывода. Но инженеры Cisco пошли дальше! Основным фактором, ограничивающим производительность гиперконвергентной платформы является сетевое ядро. Ведь для обеспечения отказоустойчивости данных, как мы помним, используется хранение одного и того же блока данных на нескольких серверах. Поэтому при записи система не имеет права сказать приложению, что запись завершена, пока данные реально не будут скопированы на один или два сервера. А раз копирование производится по сети – сеть становится узким местом. В Cisco Hyperflex сетевое ядро построено, как мы помним, на Fabric Interconnect, устройствах, имеющих необлокируемые порты с самой низкой, и главное, предсказуемой задержкой среди подобных систем. Поэтому разработчики платформы HX Data Platform приняли решение писать данные сразу по сети на необходимое количество серверов, задействуя, таким образом, все доступные диски кластера для хранения данных всех виртуальных машин. Такое решение имеет еще одно важное преимущество – при отказе одного из узлов, не нужно отслеживать, где лежат резервные данные виртуальных машин, чтобы обеспечить им большую производительность, можно запустить их на любом оставшемся сервере и никаких проблем с производительностью машины не будет. Общая производительность кластера также «не проседает» – это позволяет использовать систему для бизнес-критичных нагрузок.

Все эти архитектурные особенности привели к тому, что система Cisco Hyperflex достаточно быстро перешла из сегмента «платформа для VDI» в сегмент платформ для любых виртуализированных нагрузок. Появление систем на базе твердотельных накопителей только ускорили этот переход. Если до появления All flash-систем максимальный размер виртуальных машин, которые заказчики запускали на Hyperflex, не превышал 2 ТБ (размер единичного диска), то на All flash-системах отлично работают базы данных Oracle и MS SQL до 10 ТБ. Подтверждением тому являются документы CVD (Cisco Validated Design, типовые дизайны Cisco), описывающие архитектуру таких решений.

Также Cisco Hyperflex является единственной гиперконвергентной платформой, сертифицированной одновременно на три основных компонента ландшафта SAP – Application, Data Hub и HANA.

Отдельно нужно сказать про поддержку контейнерной инфраструктуры – в мае 2018 г. компанией Cisco был выпущен продукт Cisco Container Platform (CCP), созданный в партнерстве с компанией Google. Это, по сути, готовая сборка кластера Kubernetes с контейнерной виртуализацией Docker. Container Platform полностью автоматизировано устанавливается на Cisco Hyperflex и включен в программу технической поддержки компании Cisco. Таким образом, ИТ-департамент получает возможность создать готовую платформу под контейнерную виртуализацию и брать на поддержку разработанные в компании сервисы без необходимости развивать у себя эту экспертизу.

Подытоживая сказанное, нужно отметить, что платформа Cisco Hyperflex представляет собой принципиально новое универсальное решение для задач построения вычислительной инфраструктуры. Решение, которое на единых принципах, с единым интерфейсом управления может масштабироваться от двух до нескольких десятков серверов и поддерживать широкий круг приложений, от базовой инфраструктурной нагрузки до среднего размера СУБД, ландшафта SAP, различных самописных приложений, алгоритмов машинного обучения и так далее.

 

А что с отказоустойчивостью?

Hyperflex может использоваться для самого широкого круга задач, а потому возникает вопрос – как обеспечивается отказоустойчивость решения, особенно если речь идет о критически важных сервисах?

Защита данных внутри кластера от потери одного из узлов обеспечивается хранением нескольких копий одних и тех же блоков данных. В Cisco Hyperflex может храниться две или три копии данных, это задается настройками кластера при его создании. В зависимости от этого, кластер может «пережить» полную потерю одного или двух узлов. Дополнительно существует возможность задавать «домены отказа» – эта настройка актуальна для кластеров большого размера – в десятки узлов. Если ее указать и, например, разнести серверы, находящиеся в трех разных стойках по трем доменам, то внутри каждой стойки никогда не будут храниться все копии данных. Поэтому, даже если вся стойка выйдет из строя целиком – например, в случае обрыва сетевых кабелей или выключения обоих лучей питания, – копия данных гарантированно будет доступна в оставшихся рабочими стойках.

Отдельно следует сказать об объеме необходимого для хранения данных дискового пространства. Поскольку для обеспечения отказоустойчивости система хранит несколько копий данных, нужен какой-то механизм, который бы оптимизировал дисковое пространство, иначе объем полезных данных будет в 2–3 раза меньше, чем «сырая» емкость дисковых накопителей. Для этих целей в традиционных системах хранения давно придумали использовать дедупликацию и компрессию данных. В Hyperflex также встроены эти механизмы, причем реализованы они на архитектурном уровне и встроены в общие процессы работы с данными. Этот механизм никак не нужно включать, он работает по умолчанию даже в самых младших моделях, и он не требует отдельного лицензирования – все уже включено в стоимость системы. Все данные, записываемые на диски серверов сначала дедуплицируются, то есть при совпадении двух и более блоков данных хранится только одна копия. Затем дедуплицированные данные дополнительно еще и сжимаются. Суммарно по статистике это дает экономию от 40% до 60% места на данных общего характера, но для отдельных категорий, например, дисков виртуальных десктопов, может достигаться кратная экономия дискового пространства.

Следующим уровнем защиты от сбоев кластера Hyperflex является репликация данных на удаленный кластер. Начиная с версии 3.5 доступны два режима репликации – синхронный и асинхронный. Оба этих режима могут работать по обычной IP-сети, для них не требуется ни сеть SAN, ни «темная оптика». Единственным ограничением синхронного режима репликации является скорость канала – 10G и длительность задержек между кластерами – не более 5 мс. Оба режима очень просты в настройке, выполняются из единого интерфейса и позволяют гибко контролировать, какие виртуальные машины будут реплицироваться между кластерами. Особое внимание нужно обратить на то, что контроль осуществляется именно на уровне виртуальных машин, а не дисковых разделов – в этом ключевое отличие от режима репликации традиционных конвергентных решений. Поскольку Hyperflex на удаленной площадке получает информацию о виртуальной машине, процесс восстановления тоже предельно прост – нужно просто запустить виртуальную машину на удаленной площадке. Не требуется никаких скриптов и кластерного ПО. В асинхронном режиме копирование производится с небольшой задержкой, которая зависит от пропускной способности канала и интенсивности ввода-вывода виртуальной машины. В синхронном режиме (он еще называется растянутый кластер) на обоих узлах хранятся полностью идентичные копии виртуальных машин.

Следующим после репликации данных уровнем защиты традиционно является резервное копирование и здесь в Cisco Hyperflex также есть, о чем поговорить. Во-первых, система имеет встроенный механизм создания мгновенных копий данных диска любой виртуальной машины. Этот механизм основан на работе с указателями на блоки данных, а значит работает очень быстро. Во-вторых, многие продукты для реализации резервного копирования имеют встроенную интеграцию с механизмом мгновенных копий Hyperflex, и при использовании этого механизма, окно резервного копирования существенно (в разы) сокращается по сравнению со стандартным режимом. В число таких продуктов входят решения по резервному копированию от Veeam, CommVault, Cohesity. Со всеми этими решениями у Cisco также есть типовые дизайны, которые позволяют значительно сократить время реализации системы и избежать распространенных ошибок. Также все эти решения можно приобрести через прайс-лист Cisco, чтобы получить законченное решение от одного поставщика.

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

 

Как внедрять гиперконвергенцию

После прочтения обо всех плюсах гиперконвергенции у многих читателей может появиться мысль: «Прекрасно, но у меня ведь есть традиционная система, что мне делать с ней?». Развитие любой системы должно учитывать инвестиции, сделанные в прошлом, и для перехода на гиперконвергентную платформу должны быть какие-то основания. Самое логичное – внедрение новых сервисов или вывод из промышленной эксплуатации устаревшего оборудования. В обоих случаях заказчик получает входные данные для расчетов – требуемый объем вычислительных мощностей, выраженный в процессорах, памяти и дисковом пространстве. В последнее время часто нехватка даже одного из этих параметров, например, дискового пространства, может привести к старту проекта по переходу на гиперконвергентную платформу. Всегда имеет смысл сравнить стоимость «апгрейда» традиционного дискового массива со стоимостью приобретения гиперконвергентной системы. И если цена не отличается более чем на 10–15%, то переход на Cisco Hyperflex однозначно выгоднее в долгосрочной перспективе, так как позволяет значительно упростить операционные затраты на поддержку в ближайшие 3–5 лет.

Вторым шагом необходимо определить, какие компоненты системы и в какой конфигурации нужно закупить, чтобы построить гиперконвергентную платформу. И тут, конечно, в выигрыше окажутся заказчики, которые уже используют серверную фабрику Cisco UCS. Ведь при наличии Fabric Interconnect их не нужно закупать отдельно – можно использовать существующие при условии наличия свободных портов. В этом случае можно просто купить минимум три узла Hyperflex и приступать к построению кластера. И главное – в этом случае можно рассчитывать в будущем использовать имеющиеся узлы в качестве вычислительных (Compute only) узлов гиперфлекса, то есть существующие инвестиции не пропадают. Да и существующий дисковый массив тоже можно подключить к кластеру, как описано выше и использовать для хранения архивных копий или другой нагрузки. Если же на текущий момент серверов Cisco UCS у заказчика нет, нужно закупать всю инфраструктуру целиком, включая Fabric Interconnect, но, во-первых, в любой другой платформе все равно будут требоваться коммутаторы и эту статью расходов все равно нужно учитывать, а во-вторых, по данным компании IDC (исследование от 2016 г.) переход на фабрику Cisco UCS в горизонте трех лет сокращает совокупную стоимость владения серверной инфраструктурой на 46%, поэтому эта инвестиция в развитие очень быстро окупится.

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


Источник: http://cnews.ru/link/a13391

CISCO K8/K9 — защита и шифрование

Применение шифрования при организации локальной сети несет в себе цель защиты сети, которая включает в себя обеспечение безопасности самого сетевого устройства, защиту передаваемой им информации от неавторизованного доступа или искажения. Для защиты компьютерных сетей применяются различные алгоритмы шифрования, которые могут быть стойкими и нестойкими к расшифровке. Часть алгоритмов поддается дешифровке, часть – практически не подлежит, ввиду отсутствия достаточной производительности и вычислительной мощности имеющихся на сегодня компьютеров. Протоколы шифрования обеспечивают реализацию следующих функций:
– защита файла конфигурации сетевого устройства;
– защиту управляющего канала сетевого устройства;
– обеспечение защиты сетевого подключения от перехвата информации.
Приставка K9 в артикуле любого устройства Cisco говорит о НАЛИЧИИ в этом устройстве ЛЮБЫХ алгоритмов шифрования, без конкретизации их стойкости. Именно поэтому почти во всех устройствах Cisco в артикуле присутствует окончание K9.

  • IP телефоны Cisco используют криптографию для безопасного подключения через публичную IP сеть к IP АТС и защите от перехвата речевой информации.
  • WI-FI точки доступа с помощью протокола WPA обеспечивают установление защищенного беспроводного подключения.
  • В маршрутизаторах Cisco и в межсетевых экранах Cisco ASA заложена функция создания шифрованного соединения через IP сети – IPSec VPN. Использование IPSec VPN в содружестве со стойким алгоритмом шифрования информации 3DES обеспечивает достаточно серьезную защиту сети на публичных каналах связи.

Продукция Cisco K9, имеющая в себе 3DES шифрование, запрещена к ввозу на территорию Российской Федерации без лицензии. Поэтому любой маршрутизатор Cisco является криптографическим средством, имея в арсенале протокол 3DES, наличие которого приравнивает его к шифровальному средству. Ввоз, обслуживание, реализация шифровальных средств на территории России – лицензируемая деятельность. Чтобы обеспечить пользователям свободный доступ к сетевым технологиям и современным решениям по защите сети, компания выпустила модель Cisco К8. Это технически и физически то же самое устройство, но с вырезанными функциями 3DES из операционной системы устройства IOS. Для создания защищенного соединения и удаленного доступа в устройствах Cisco K8, поставляемых российским потребителям, присутствует только DES или AES шифрование.

 

Cisco NPE

Дополнительный класс устройств, IOS которых получил суффикс NPE, был выпущен для упрощения процедуры ввоза интегрированных маршрутизаторов Cisco. Такие маршрутизаторы стали комплектоваться специальным IOS — NPE (no payload encryption). Это полностью функциональная операционная система, со всеми необходимыми функциями с тем ограничением, что полностью вырезана часть, обеспечивающая шифрование пропускаемого трафика. Т.е. версия NPE может иметь Advanced Security набор функций, Вы можете использовать Firewall, IPS, работать с расширенным количеством пользователей, однако функции шифования остаются недоступны.

 

Что такое Cisco PCI? Маршрутизаторы Cisco K9 как средство защиты информации в банковских сетях

Запрет к открытой поставке в Россию таких устройств сетевой защиты как маршрутизаторы и межсетевые экраны Cisco с 3DES шифрованием вызвал значительный резонанс. Подобные сетевые устройства защиты в большинстве своем использовались не частными лицами, а бизнес-структурами, финансовыми и производственными предприятиями. Наибольшая потребность в надежных VPN-устройствах у финансовых организаций – банков. Применение стойких алгоритмов защиты в банковских сетях гарантирует сохранение ценной информации – финансовых данных и личных данных клиентов. Нехватка сетевых средств защиты информации в продаже со вступлением новых законов в силу приостановила рост и развитие финансовых институтов, ввиду отсутствия необходимых устройств защиты сети на российском рынке. В значительной степени это было связано с расширением сети банкоматов – выросло потребление маршрутизаторов младшей серии СISCO881-K9, СISCO861-K9, которые в большинстве использовались банками для организации безопасного подключения мобильного терминала (банкомата) к банковской сети. Понимая сложность ситуации, правительство пришло на помощь. Устройства, специально разработанные для защиты финансовой информации платежных систем, имеют в артикуле сокращение PCI – Payment Card Industry, означающее, что данное устройство одобрено MasterCard, Visa, Amex, JCB для организации доступа к платежным системам. Именно поэтому устройства PCI-K9 продаются, Но приобрести подобные устройства имеет право только финансовое учреждение с лицензией, а продавать – организация, имеющая лицензию на распространение криптографических средств.

 

Таким образом, подводя итог анализа средств Cisco K9 и Cisco K8 для защиты сети:

1. Все устройства Cisco K9 в окончании артикула на официальном рынке России – имеют криптографию, разрешенную ко ввозу на территорию России без лицензии и разрешены к открытой продаже.

2. Сетевые устройства Cisco, имеющие в артикуле K8 – устройства, с усеченными функциями по криптографии, которые в большинстве касаются отсутствием поддержки протокола 3DES, но при этом поддерживают IPSEC VPN на уровне AES, DES.

3. Устройства PCI – имеют стойкую криптографию (3DES), но продаются только банкам, только организациями, имеющими на это право (имеющими лицензию ФСБ на распространение криптографических средств).

4. Cisco NPE – имеют полный функционал, в расширенных версиях IOS включены все дополнительные функции, а вот сквозное шифрование – вырезано из программного кода IOS и не может быть включено пользователем.

Как выбрать DLP и не ошибиться: функциональность, стоимость владения и доверие к вендору

Системы защиты от утечек информации – DLP чаще всего устанавливают банки, предприятия нефтяной отрасли, крупные ритейлеры. Однако не так важна сфера деятельности, как количество сотрудников. Обычно компании начинают интересоваться DLP-системами, когда штат превышает 50 человек. Тогда управленческий контроль становится сложнее, и руководство снаряжает технических специалистов присмотреться к тому, что предлагает рынок для автоматизации процесса. Сходу разобраться в обилии решений от разных вендоров бывает непросто. Вот краткий гайд, который поможет расставить точки над i.

 

Как и для чего работает DLP

Исторически системы DLP, как видно из названия (data loss prevention или data leak prevention), были направлены на защиту компании от утечек информации. Но с эволюцией программного обеспечения заказчики начали ставить перед ней несвойственные изначально задачи. Сейчас защита конфиденциальной информации — это только одна из больших функций, которые выполняет система.

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

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

 

Чем меряемся

  • Количество каналов контроля

Контролировать максимум каналов информации (от веб-почты до мессенджеров) – главное требование к качеству программы. Ведущие DLP-системы отслеживают их все. Полезно, когда система обучена «ловить» нетипичные утечки, ведь конфиденциальные данные могут передаваться не только в переписке. Вариантов масса: снимки экрана, печать внутренних документов, копирование на флешку, даже устная беседа в Skype или передача файлов через Teamviewer.

 

  • Качество контроля

DLP должна уметь контролировать информацию, переданную в сетевых сервисах с разным методом подключения. Все популярные системы (Skype, Telegram, Viber и т.д.) сегодня дают выбор, работать в веб-интерфейсе или через приложение. В ИБ-системах такие вещи должны предусматриваться, иначе нельзя говорить о полноценной защите канала.

 

  • Надежность и скорость работы DLP

Устанавливаемые на ПК сотрудников агенты не должны перегружать систему, а сетевой DLP-компонент не должен приводить к задержкам коммуникации: DLP будет скомпрометирована, а руководитель всегда выберет бесперебойность бизнес-процессов, а не безопасность.

Часто система, которая хорошо работает на 200 машинах, не показывает результат на 1000. Поэтому важно разворачивать тестирование на максимально большом парке машин. Так можно оценить реальную нагрузку на инфраструктуру и технические возможности программы.

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

«Легкость» агента как правило означает, что большинство процессов в DLP происходит на серверах. При этом нужно удостовериться, что сбои в соединении не нарушат стабильность перехвата.

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

 

  • Аналитические возможности

Правила «хорошего тона» для DLP таковы, что софт должен максимально «разгружать» ИБ-специалистов, выполняя основные задачи по структурированию инцидентов. Сегодня система должна уметь выявлять не только утечки, но и неспецифические угрозы:

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

Но полная автоматизация контроля – это все-таки утопическая задача, и сотрудникам службы ИБ все равно приходится перепроверять результаты некоторых «сработок» вручную. Для нивелирования этого фактора DLP-системы движутся к тому, чтобы вести профилактику нарушений, анализируя пользовательское поведение. Одно из направлений – UEBA, но здесь не появилось работающих инструментов.

Мы решаем этот вопрос через автоматизированный профайлинг. Он позволяет анализировать получаемую из DLP информацию и определять личностные качества сотрудников и динамику их изменений. Это позволяет существенно сузить круг поиска инцидентов и находить их там, где нарушитель не оставляет следов.

 

Сколько это стоит

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

Чаще всего цена состоит из таких переменных:

  • стоимость лицензий (на 1 рабочее место);
  • стоимости внедрения;
  • стоимость техподдержки;
  • стоимость получения новых версий;
  • стоимость оборудования и стороннего ПО;
  • зарплаты ИБ и IТ специалистов.

Чем более сильные аналитические возможности заложены в DLP, тем ниже стоимость владения системой. Для анализа ситуации в компании с помощью хорошей DLP-системы на 2000 сотрудников бывает достаточно одного ИБ-специалиста. Один из наших клиентов контролировал 25 тысяч машин в компании силами всего 7 сотрудников.

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

 

А вендор кто?

Весомый аргумент «за» или «против» того или иного предложения – его автор. При выборе DLP, как и любого другого продукта, нужно составить представление о его производителе: насколько это опытный и надежный вендор. Сложность в том, что со стороны, при первом знакомстве со сферой, оценить это можно только по косвенным признакам: количество офисов, штат технического персонала, число клиентов и разнообразие представляемых ими сфер.

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

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

  • Ставьте на тест последовательно несколько систем. Так будет проще оценить как плюсы/минусы самого программного обеспечения, так и качество техподдержки.
  • Сравните объем перехвата по нескольким DLP. Если он слишком разный, скорее всего, одна из систем что-то пропускает. Что касается оценки аналитических возможностей, то стоит обратить внимание на информативность отчетов и наличие полной базы перехвата. Важно, чтобы DLP-система собирала всю переданную по выбранным каналам информацию, а не только инциденты. Эти данные могут оказаться бесценными, если придется проводить ретроспективное расследование.
  • Обратите внимание, просто ли вам найти информацию по базе, проанализировать данные. Это особенно важно, когда в компании нет выделенной службы безопасности или все информационные потоки контролирует один специалист. В частности, у нас в компании ситуацию по нескольким сотням сотрудников, работающих в десятках филиалов, мониторит один человек.
  • Поработайте с программой как минимум 2 недели, чтобы как следует разобраться в возможностях. Лучше при этом постоянно держать контакт с техподдержкой. Обращайте внимание на то, насколько специалисты легко ориентируется в программном обеспечении.

И последнее. Чтобы взглянуть на ПО без «розовых очков», попросите разработчика познакомить вас с действующим клиентом. Задайте ему вопросы о стабильности работы системы, возможностях контроля, плюсах и минусах работы ПО.


Статья взята с ресурса www.computerra.ru. Автор: