Snort
Начнем с краткой предыстории. Snort был создан Мартином Решем в 1998-м году и очень быстро завоевал популярность, как бесплатная система обнаружения вторжений, позволяющая самостоятельно и без особых усилий писать правила для обнаружения атак. По сути язык описания сигнатур Snort стал стандартом де-факто для многих систем обнаружения вторжений, которые стали его использовать в своих движках.
Основу Snort составляет движок, состоящий из пяти модулей:
- Снифер пакетов. Как понятно из названия данный модуль отвечает за захват передаваемых по сети данных для последующей их передаче на декодер. Делает он это с помощью библиотеки DAQ (Data AcQuisition). Работать данный снифер может “в разрыв”, в пассивном режиме или читать сетевые данные из заранее подготовленного файла.
- Декодер пакетов. Данный модуль занимается разбором заголовков захваченных пакетов, их разбором, поиском аномалий и отклонений от RFC, анализом TCP-флагов, исключением отдельных протоколов из дальнейшего анализа и другой аналогичной работой. Фокусируется данный декодер на стеке TCP/IP.
- Препроцессоры. Если декодер разбирал трафик на 2-м и 3-м уровне эталонной модели, то препроцессоры предназначены для более детального анализа и нормализации протоколов на 3-м, 4-м и 7-м уровнях. Среди самых популярных препроцессоров можно назвать frag3 (работа с фрагментированным трафиком), stream5 (реконструкция TCP-потоков), http_inspect_ (нормализация HTTP-трафика), DCE/RPC2, sfPortscan (применяется для обнаружения сканирования портов) и различные декодеры для протоколов Telnet, FTP, SMTP, SIP, SSL, SSH, IMAP и т.п. Некоторые российские разработчики пишут свои препроцессоры (например, для промышленных протоколов) и добавляют в собственные системы обнаружения вторжений (IDS), построенные на базе Snort.
- Движок обнаружения атак. Данный движок состоит из двух частей. Конструктор правил собирает множество различных решающих правил (сигнатур атак) в единый набор, оптимизированный для последующего применения подсистемой инспекции захваченного и обработанного трафика в поисках тех или иных нарушений.
- Модуль вывода. По факту обнаружения атаки Snort может выдать (записать или отобразить) соответствующее сообщение в различных форматах — файл, syslog, ASCII, PCAP, Unified2 (двоичный формат для ускоренной и облегченный обработки).
И до и после Snort появлялись системы обнаружения атак, но именно Snort заслужил славу стандарта де-факто, что подтверждает свыше 4-х миллионов скачиваний данного ПО с сайта www.snort.org и свыше 500 тысяч зарегистрированных в официальном сообществе пользователей. Что послужило причиной такой любви к Snort? Его язык описания нарушений политик сетевой безопасности. С одной стороны этот язык очень прост и правило для обнаружения атаки или иного нарушения политик безопасности может быть написано всего за пару минут (а то и быстрее). С другой, фильтры, сложные запросы, комбинирование правил, установление пороговых значений, учет временных интервалов, позволяют писать действительно очень сложные обработчики сетевых событий.
В конце 2014-го года была анонсировала альфа-версия Snort 3.0 (он же Snort++), в котором были реализованы многие задумки, ранее пылившиеся “на полке”. В частности, был переработан дизайн систем, ставший более ориентированным на пользователя. Также появился механизм автоматической идентификации протоколов на всех портах, поддержка параллельной обработки пакетов, а язык описания правил стал еще проще.
В конце 2014-го года было сделано и еще одно крупное изменение в Snort, которое вошло в релиз 2.9.7 системы, не дожидаясь выхода Snort 3.0 в промышленную эксплуатацию. Речь идет об OpenAppID, то есть язык распознавания прикладных протоколов и реализации того, что у Cisco называется Application Visibility and Control. По сути речь идет о механизме (в виде отдельного препроцессора) описания сигнатур для собственных приложений и использовании их в решающих правилах (сигнатурах атак). Пока Snort с OpenAppID опережает Cisco FirePOWER по данной возможности. Сейчас, чтобы описать свои приложения в Cisco FirePOWER, надо использовать либо HEX-редактор, либо давать на вход системы предварительно записанный PCAP-файл с трафиком интересующего приложения. Это бывает не очень удобно и требует определенных навыков. Язык OpenAppID, который будет поддерживаться в решениях Cisco, уже до конца 2015-го года, позволяет реализовывать эту задачу попроще.
FirePOWER
Спустя 3 года, в 2001-м году, Мартин Реш основал коммерческую компанию Sourcefire, в рамках которой была создана коммерческая версия Snort, называемую в разное время 3D Sensor, FirePOWER и др. Основной целью Мартина Реша было предложить заказчикам готовое и автоматизированное решение, не требующее больших усилий по настройке и внедрению. Второй целью было создание высокопроизводительного решения, способного обнаруживать атаки на высоких скоростях в десятки гигабит в секунду. Таким было первое поколение устройств компании Sourcefire. Затем появилась вторая серия устройств, в которой появилась функция идентификации приложений (в Snort она появилась только в прошлом году), механизм обнаружения вредоносного кода FireAMP, межсетевое экранирование и ряд других функций. В третьем поколении появился полноценный МСЭ следующего поколения (NGFW). В 2011-м году компания Cisco объявила о намерении приобрести компанию Sourcefire (несколькими годами ранее это не удалось компании Check Point) и с этого момента у платформы FirePOWER началась новая жизнь.
В настоящий момент данная платформа представлена в виде 6 вариантов реализации:
- Отдельные высокопроизводительные устройства Cisco FirePOWER Appliance. По сути это те же устройства, что и выпускала компания Sourcefire.
- Межсетевой экран Cisco ASA with FirePOWER Services, который помимо функциональности традиционного МСЭ и VPN (Site-to-Site и Remote Access) получил возможности МСЭ следующего поколения (NGFW), системы предотвращения вторжений (NGIPS), системы контетной фильтрации, системы нейтрализации вредоносного кода и ряда других функций.
- Маршрутизатор Cisco FirePOWER Threat Defense for ISR, позволяющий запустить все вышеперечисленные возможности на базе маршрутизатора.
- Виртуальные версии всех упомянутых возможностей, запускаемые на базе VMware.
- Новая аппаратная платформа Firepower 9300, способная выполнять множество задач сетевой безопасности (от МСЭ и VPN до борьбы с вредоносным кодом и отражением DDoS) на скоростях в сотни гигабит
- Промышленные межсетевые экраны и системы обнаружения вторжения Cisco ISA 3000 и Cisco ISA 4000.
Чем же коммерческое программное обеспечение этих шести платформ отличается от Snort, который можно свободно скачать из Интернет?
В чем отличия?
Попробую выделить ключевые возможности, присутствующие в технологиях FirePOWER:
- Одно из серьезных изменений, появившихся в 2007-м году, стала технология RNA (Real-Time Network Awareness), позволяющая строить активный профиль всего, что происходит в контролируемой сети, строит карту сети, идентифицирует хосты, протоколы и приложения путем пассивного анализа трафика. Позже эта информация сопоставляется с данными об атаках и иных нарушениях политик безопасности.
- Похожа на RNA технология RUA (Real-Time User Awareness), которая связывает данные о пользователях с сетевой активностью. Всегда полезно видеть, что атака реализуется против пользователя “Иванов И.И.”, а не против обезличенного узла с IP-адресом 192.168.1.34.
- В 2007-м году Sourcefire купила права на ClamAV, бесплатный антивирус, который был интегрирован с системой предотвращения вторжений для анализа уже не сетевых пакетов и соединений, а файлов, передаваемых по сети. Позже данное решение, после приобретения в 2011-м году компании Immunet, развилось в систему AMP for Networks, позволяющую идентифицировать вредоносный код с помощью семи различных алгоритмов, а также осуществлять ретроспективный анализ (анализ пост-фактум) уже попавших в сеть файлов. Кстати, идентификация и блокирование файлов по их типам появилось и в Snort, начиная с версии 2.9.7.
- Мартин Реш скептически относится к идее межсетевого экранирования, считая, что злоумышленники как раз пользуются открытыми на МСЭ портами для инкапсуляции своих несанкционированных действий. Поэтому вместо традиционного межсетевого экрана в решениях Sourcefire был реализован межсетевой экран прикладного уровня, он же межсетевой экран следующего поколения (NGFW), позволяющей контролировать нарушения в использовании приложений, инкапсуляцию в них запрещенного трафика и т.п. Кстати, именно по этой причине, NGFW практически невозможно сертифицировать по российским требованиям к МСЭ — NGFW просто не обладают таким функционалом; это не их задача.
- Для реализации функции NGFW необходимо уметь идентифицировать приложения, функционирующие в сети. Это делается с помощью технологии AppID, которая по сути стала основой для разработки ранее упомянутой технологии OpenAppID. Помимо предопределенных детекторов приложений возможно описывать и собственные приложения (об этом написано выше).
- Но от реализации функций межсетевого экрана в FirePOWER все же не обошлось. В частности в любой из шести платформ, использующих технологии FirePOWER, при создании политик безопасности можно использовать зоны, VLAN, IP, порты, а также пользователей и группы в правилах МСЭ.
- Помимо блокирования трафика по IP-адресам, в FirePOWER была реализована и технология фильтрации URL. В случае использования SSL возможна его расшифровка с последующей инспекцией. В настоящий момент инспекция SSL доступна только в FirePOWER Appliance, но до конца 2015-го года будет реализована и на остальных платформах.
- Имея на борту одного сенсора не только систему обнаружения вторжений, но и межсетевой экран, систему борьбы с вредоносным кодом, систему URL-фильтрации и ряд других защитных технологий, логично было объединить их возможности в рамках идентификации индикаторов компрометации (IOC), что и было сделано в одной из версий FirePOWER.
- Для снижения нагрузки на сенсоры в них была реализована так называется функция Security intelligence, заключающаяся в ведении черных и белых списков IP-адресов. Это позволяет не обрабатывать доверенный трафик и блокировать изначально вредоносный. Делается это на уровне декодера, что в итоге повышает производительность всей системы. Еще одной встроенной функцией является поддержка геолокации, позволяющая осуществлять географическую привязку адресов, зафиксированные в сетевых пакетах и сессиях.
- В FirePOWER встроена функция обнаружения защищенного контента по контрольным суммам (она появилось и в Snort 2.9.7), которую можно использовать как облегченный вариант DLP-системы.
- С точки зрения сетевых возможностей в FirePOWER реализована поддержка NAT и маршрутизации, чего нет в Snort, а также стекирование устройств для повышения производительности (только для FirePOWER Appliance) и кластеризация (только для Cisco ASA with FirePOWER Services) — до 16 устройств. В случае кластеризации совокупная производительность в режиме МСЭ составит 640 Гбит/сек, а в режиме IPS — 160 Гбит/сек.
- Код коммерческого ПО был оптимизирован (вместо GCC. используется Intel C), а на FirePOWER Appliance также используется специальные сетевые карты, которые позволяют балансировать нагрузку и обработку TCP-потоков между несколькими ядрами на одном устройстве. С их помощью осуществляется стекирование нескольких устройств. Поддержка многоядерных процессоров должна быть реализована и в Snort 3.0.
На этом можно было бы и остановиться, завершив сравнение защитных сенсоров, построенных на базе Snort и FirePOWER. Но ведь это еще не все, что нужно для полноценной системы защиты, особенно в корпоративной среде. Давайте посмотрим, какие функции управления, в т.ч. и централизованного, предлагаются вместе с Snort или FirePOWER.
Сам Snort никакой системы управления не имеет. Однако модуль вывода позволяет отдавать результаты работы во внешние системы, чем не преминули воспользоваться разработчики, которые предложили рынку сразу несколько различных систем для управления, генерации отчетов, анализа и визуализации событий безопасности Snort. Среди них ACID (очень давно не обновлялся), BASE, Snorby, Sguil, Aanval (коммерческое решение). С ACID я работал очень-очень давно, когда писал книжку “Обнаружение атак”. К тому же, как и BASE, ACID не обладает расширенными аналитическими возможностями по работе с данными. С Aanval я не работал, да и коммерческие системы управления третьих фирм для бесплатного Snort — это не совсем то, что нужно (хотя в ряде случаев возможно). А вот что касается Snorby и Sguil, то могу сказать, что второй является более популярным. Попробуем сравнить его с “родной” системой управления сенсорами FirePOWER — FireSIGHT Management Center (прежнее название — Defense Center).
Что такое Sguil? По сути это система агрегации событий от Snort, позволяющая визуализировать то, что модуль вывода Snort выдает вовне — сигнал тревоги, содержание пакета и другая сопутствующая информация. Далее Sguil позволяет вам запускать через него иные инструменты для более детального расследования зафиксированных событий. К числу таких инструментов могут быть отнесены:
- Squert, web-приложение для организации запросов и отображения данных, сохраненных в базе данных Squil.
- ELSA, система централизованного управления логами, этакий облегченный SIEM.
- NetworkMiner, средство для проведения сетевых расследований на основе полученного от Snort pcap-файла.
- WireShark, который в представлении не нуждается.
В принципе, при наличии квалификации и времени, из связки Sguil и других инструментов мониторинга (например, входящих в Security Onion) можно сваять неплохую систему управления событиями, которые отдает нам Snort. Но и только… Управление правилами, конфигурация сенсоров, отслеживание их статуса, обновление, бэкапирование базы данных событий, ролевое управление доступом, иерархическая система управления, генерация отчетов… Все это остается недоступным для пользователей Sguil.
“Родной” FireSIGHT Management Center лишен этих недостатков. Среди его функций:
- Централизованное управление и конфигурация множеством сенсоров FirePOWER.
- Обновление сенсоров без необходимости перекомпиляции кода (еще бы и правильные параметры не забыть указать).
- Корреляция событий не только от нескольких сенсоров IDS, но и от разнотипных средств и технологий защиты — МСЭ, AMP, RNA, RUA и др.
- Создание политик безопасности.
- Проведение расследований инцидентов.
- Управление профилями для каждого узла (адреса, ОС, приложения, протоколы, пользователи).
- Интеграция с AD и централизованное, иерархическое управление пользователями.
- Контроль состояния удаленных сенсоров.
- Настраиваемые dashboard для отображения различной информации.
- Генерация отчетов.
- Бекап базы данных.
- И т.п.
По сути, FireSIGHT — это средство автоматизации рутинных задач, которые раньше занимали столь драгоценное при реагировании на инциденты время. Например, в Snort и FirePOWER есть HAT (Host Attribute Table) — XML-файл, ассоциирующий с каждым IP-адресом используемые на нем операционные системы, а также ассоциации “сервис-порт”. В Snort этот файл создается вручную, что в крупной сети может представлять некоторые сложности. В FirePOWER этот файл создается автоматически за счет RNA и не требует ручной работы. И таких примеров можно привести множество.
У SGUIL есть два преимущество перед “родной” системой управления FireSIGHT Management Center. Во-первых, она бесплатна. А во-вторых, она отображает данные от сенсоров в реальном времени; у FireSIGHT максимальная частота обновления данных — раз в минуту. Зато FireSIGHT позволяет интегрировать сенсоры FirePOWER с различными внешними системами безопасности, применяемыми в корпоративном сегменте — сканерами безопасности, межсетевыми экранами, маршрутизаторами и коммутаторами, системами захвата пакетов, системами визуализации событий безопасности, SIEM и т.д. Делается это за счет специальных API, которые также отсутствуют у того же Snort (хотя с помощью различных скриптов можно попробовать интегрировать его с рядом таких же бесплатных инструментов защиты).
Резюме
В качестве заключения мне бы не хотелось делать никаких выводов кроме одного. Заявления о том, что технологии FirePOWER, ранее принадлежавшие компании Sourcefire, а позже приобретенные компанией Cisco, и бесплатная система обнаружения атак Snort, когда-то лежавшая в основе решений Sourcefire, это не одно и тоже. Ну то есть совсем не одно и тоже. Да, Snort остается стандартом де-факто для систем обнаружения атак, но Cisco FirePOWER — это гораздо больше, чем просто IDS. Тут вам и межсетевой экран прикладного уровня, и фильтрация URL, и нейтрализация вредоносного кода, и встроенная корреляция событий, и расследование инцидентов, и интеграция со сканерами безопасности, и множество других функций, автоматизирующих рутинные задачи безопасника.
Комментарии (28)
cooper051
05.10.2015 13:56Алексей, может вопрос немного не в тему, но не планируется ли реализация в Cisco ASA программных модулей S-terra (как сейчас FirePOWER)? Чтобы получать сертифицированный МЭ и VPN в одной коробке.
alukatsky
05.10.2015 14:10Мы рассматриваем такой вопрос, но не раньше завершения сертификации ASA в ФСБ. Без этого С-Терра может и заработает на ASA, но сертификата не получит. А без сертификата, что С-Терра, что встроенная криптография — равнозначны
cooper051
05.10.2015 14:17Боюсь задать глупый вопрос, но рискну (т.к. больше спросить не у кого). А почему в Cisco ASA не реализовать ГОСТ шифрование? Подключить библиотеки криптопро (как это делается в CheckPoint), тогда бы и S-terra не нужна была.
Klukonin
05.10.2015 15:15Как вы думаете, что для компании выгоднее, продавать для решения этой задачи свое железо в виде модулей S-terra или отдать все на откуп Крипто-Про/Криптоком?
З.Ы. Пардон что вклиниваюсь.
alukatsky
05.10.2015 15:23+1А тут все просто. Чтобы разрабатывать СКЗИ необходимо иметь лицензию ФСБ на разработку. Делаться разработка должна на территории России. Для сертификации надо предоставить исходники всего решения, куда встраивается СКЗИ. Это куча головной боли и непросто в реализации. Только после этого можно получить сертификат ФСБ. Без сертификата, что ГОСТ, что AES равнозначны с точки зрения законодательства. Именно поэтому у Check Point нет сертификата ФСБ на решение на базе КриптоПро. А наличие сертификата на криптобиблиотеку не делает все решение, ее включающее, легитимным. С 2014-го года ФСБ поменяла правила и требует сертификат на все изделие целиком.
Rel1cto
05.10.2015 15:37Алексей, расскажите подробнее, пожалуйста.
Я помню ваш пост «О так называемой поддержке ГОСТа...», по итогам которого решение CheckPoint оказывалось нелегитимным, потому что во всех случаях, когда закон требует ГОСТ, он же требует и проверку на «корректность встраивания», которой у ЧП нет.
Что-то поменялось в 2014, что оно стало ещё более нелегитимным? :)alukatsky
05.10.2015 16:14+1Не, не совсем так. ФСБ все шифровальные средства делит на два класса — сертифицированные и все остальные. Чтобы продукт считался сертифицированным он должен:
— быть разработан в России по согласованному с ФСБ ТЗ
— пройти целиком испытания в ФСБ (для этого нужно предоставлять исходники)
— реализовывать ГОСТ.
Наличие только третьего пункта не делает продукт сертифицированным. Нужно еще первые два пункта реализовать. Для иностранных компаний это, мягко говоря, затруднительно. Поэтому можно включить в свое решение КриптоПРО, но продукт сертифицированнее от этого не станет. Тоже самое, если КриптоПро поставить на маршрутизаторы, на модуль UCS-E. Оно будет работать (и работает), но сертифицированным считаться не будет
Klukonin
05.10.2015 15:38С 2014-го года ФСБ поменяла правила и требует сертификат на все изделие целиком.
Подскажите, пожалуйста, в каком акте это изменение прописано?
Гугл ведет только на ваш блог и отсылку в кулуары.alukatsky
05.10.2015 16:07К сожалению, в публичных актах этого нет. Это рассылалось по лицензиатам ФСБ
Klukonin
06.10.2015 08:57Значит это не законно.
То есть, если придет роскомнадзор, я показываю старые нормативные документы на контроль встраивания, показываю модель угроз с указанием на необходимость использования не выше КС2?alukatsky
07.10.2015 18:11Не совсем так. Вопросы сертификации СКЗИ относятся к ведению ФСБ и они вольны регулировать это так, как считают нужным. На уровень федерального законодательства выносится только обязанность применять или не применять сертифицированные СКЗИ. К тому же, даже раньше было требование применения сертифицированного СКЗИ, а не криптобиблиотеки. Так что ФСБ в своем праве.
Что касается РКН, то он вообще не уполномочен проверять вопросы технической защиты ПДн.
alukatsky
07.10.2015 18:27К слову: вы и требований к КС2 не найдете в открытом доступе :-) Это закрытый документ. Так и с изменением процедуры сертификации
Klukonin
08.10.2015 09:20Вы опять передергиваете. Я говорю о том что, допустим, в модели угроз все расписано и указывается что необходимо применять криптосредства не выше КС2. Я беру сертифицированный крипто-про и устанавливаю его на сертифицированный линуксовый дистрибутив, выполняя тем самым встраивание. Официальные документы ФСБ говорят о том что для КС2 контроль встраивания не является обязательным. Чем ФСБ будет обосновывать незаконность моих действий?
Закрытой рассылкой среди лицензиатов? Не смешите меня…alukatsky
08.10.2015 11:56Если вы берете сертифицированный КриптоПро, то должны соблюдать ТУ на него. А в нем черным по белому написано, что для встраивания КриптоПро куда-либо необходимо согласовать ТЗ с ФСБ. А при согласовании вы столкнетесь с тем, что сертификата получено не будет на решение, если оно не проверяется целиком.
alukatsky
08.10.2015 11:58Какие официальные документы ФСБ говорят, что для КС2 контроль встраивания не является обязательным? Номер приказа можно уточнить? Если уж мы дошли до такого уровня дискуссии.
Ну и к слову. Встраивать СКЗИ куда-то — это лицензируемый вид деятельности вообще-то. Не имея на это лицензии, вы рискуете попасть под 171-ю УК РФ.Klukonin
08.10.2015 12:28Не надо, крипто-про нигде не пишет про обязательное соблюдение ТУ пользоватетем, особенно в пункте про встраивание. Там этого нет.
Закон? Олично:
Постановление Правительства Российской Федерации от 17 ноября 2007 года №781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных».
5.Требования к контролю встраивания криптосредства
5.1.Встраивание криптосредств класса КС1 и КС2 осуществляется БЕЗ КОНТРОЛЯ со стороны ФСБ России (если этот контроль не предусмотрен техническим заданием на разработку (модернизацию) информационной системы).
Встраивание криптосредств класса КС3, КВ1, КВ2 и КА1 осуществляется только под контролем со стороны ФСБ России.
5.2.Встраивание криптосредств класса КС1, КС2 или КС3 может осуществляться либо самим пользователем криптосредства при наличии соответствующей лицензии ФСБ России, либо организацией, имеющей соответствующую лицензию ФСБ России.
Встраивание криптосредства класса КВ1, КВ2 или КА1 осуществляется организацией, имеющей соответствующую лицензию ФСБ России.
Ну да, придется найти лицензиата и просить его выполнить формальный контроль встраивания… А нифига.
Методическими рекомендациями необходимо руководствоваться в случае определения оператором необходимости обеспечения безопасности персональных данных с использованием криптосредств (за исключением случая, когда оператором является физическое лицо, использующее персональные данные исключительно для личных и семейных нужд), а также при обеспечении безопасности персональных данных при обработке в информационных системах, отнесенных к компетенции ФСБ России. В частности, Методическими рекомендациями необходимо руководствоваться в следующих случаях:
при обеспечении с использованием криптосредств безопасности персональных данных при их обработке в государственных информационных системах персональных данных (часть 5 Федерального закона от 27 июля 2006 года №149-ФЗ «Об информации, информационных технологиях и о защите информации»);
при использовании криптосредств для обеспечения персональных данных в случаях, предусмотренных п.3Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (ПоложениеПКЗ-2005).
То есть, либо это государство и ему стопудово надо сертифицированный СКЗИ, либо ориентироваться на ПКЗ-2005, но он носит РЕКОМЕНДАТЕЛЬНЫЙ характер.
Иными словами, все что вы окрестили обязательным к исполнению, на самом деле является только рекомендациями. И если ФСБ лицензиатов за неисполнение своих понятий полузаконно дрючит, это не относится к простым пользователям =))
Чтобы не быть голословным, пункт из ПКЗ
4. Требования Положения ПКЗ
— 2005 носят РЕКОМЕНДАТЕЛЬНЫЙ характер при разработке,
производстве, реализации и эксплуатации:
средств криптографической защиты информации, доступ к котор
ой ограничивается по
решению обладателя, пользователя (потребителя) данной информации, собственника
(владельца) информационных ресурсов (информационных систем) или уполномоченных
ими лиц, не являющихся государственными органами или организациями,
выполняющ
ими государственные заказы;alukatsky
08.10.2015 13:40Ничего, что 781-е Постановление отменено уже несколько лет назад?
Ну а что касается ТУ, то я почему-то вижу вот такой текст: «При встраивании СКЗИ ЖТЯИ.00050-03 в прикладные системы необходимо по Техническому заданию, согласованному с 8 Центром ФСБ России, проводить оценку влияния среды функционирования СКЗИ на выполнение предъявленных к СКЗИ требований в случаях:
— если информация, обрабатываемая СКЗИ, подлежит защите в соответствии с законодательством Российской Федерации;
— при организации защиты информации, обрабатываемой СКЗИ, в федеральных органах исполнительной власти, органах исполнительной власти субъектов Российской Федерации;
— при организации криптографической защиты информации, обрабатываемой СКЗИ, в организациях независимо от их организационно-правовой формы и формы собственности при выполнении ими заказов на поставку товаров, выполнение работ или оказание услуг для государственных нужд.
В остальных случаях рекомендуется проводить установленным порядком проверку корректности встраивания СКЗИ ЖТЯИ.00050-03 в прикладные системы с целью оценки обоснованности и достаточности мер, принятых для защиты информации, обрабатываемой СКЗИ.»
Klukonin
А разве современный подход к расследованию инцидентов не подразумевает использование SIEM? В котором как раз все эти вкусности агрегации и интеграции реализуются? С задачами IPS/IDS снорт справляется хорошо.
Никогда не пойму этот подход, при котором сначала предлагается внедрить кучу самодостаточных железок, а потом второй раз заморачиваться с их взаимной интеграцией и централизованной обработкой событий.
13oz
Тут будет уместно сказать, что it depends. Если у вас есть финансовые и человеческие ресурсы на разворачивание всех компонентов системы ИБ отдельно — то да, использование отдельного SIEM является предпочтительным. Но нужно помнить, что это вещь, во-первых, дорогая, и, во-вторых, тяжелая в настройке. Для значительной части заказчиков использование встроенных механизмов достаточно. Даже тот минимальный механизм управления инцидентами, который был встроен в Stonegate, позволял полноценно вести большую часть инцидентов.
А для этих целей сейчас предлагают использовать all-in-one решения, типа (не к ночи будь помянут) Check Point (тьфу-тьфу-тьфу, не приведи с ним работать).
cooper051
Не совсем понимаю такую ненависть к продуктам CheckPoint. У меня есть некоторые вопросы к надежности данного продукта (выходят из строя гораздо чаще чем cisco), но у них очень системный и четкий подход к обеспечению безопасности. Есть UTM устройство, которое включает все необходимое для защиты сети. Что использовать, а что нет, уже ваша проблема. Но у них всего один продукт.
В решениях же cisco по моему уже даже сотрудники cisco путаются. Бесконечно число решений, с перекрывающим друг друга функционалом. Нет четкого представления и вектора движения. По крайней мере я не вижу.
cooper051
И это я еще не упомянул кучу продуктов, которые Cisco просто бросила разрабатывать, взяв за них кучу денег.
alukatsky
Что плохого, когда один продукт может частично выполнять функции другого? Рутер выполняет функции МСЭ. NGFW выполняет функции WAF. WSA выполняет функции борьбы с ботнетами. AMP позволяет реализовать облегченную DLP. Иногда такая «облегченная» функциональность очень полезна, если нет возможности брать полнофункциональный продукт.
alukatsky
А FireSIGHT и есть SIEM для решений Cisco (не для всех, но для всех упомянутых)
Klukonin
Я вам, наверное, открою тайну, но в инфраструктуре могут быть не только Cisco.
alukatsky
Да, такое еще встречается иногда :-) Поэтому мы и не называем FireSIGHT полноценным мультивендорным SIEM'ом. Он только для управления событиями от решений Cisco. Но зато за эту функциональность денег не берем, в отличие от заоблачных цен на SIEM
Klukonin
Я не поверю что эта функциональность не отразилась на цене, хоть в явном виде она и не оплачивается. А SIEM стоит конских денег только у нескольких вендоров, которых можно пересчитать по пальцам, а одного из них вы точно знаете ;-)
Есть SIEM решения, не стоящие никаких денег, ибо СПО.
askbow
alukatsky А FireSIGHT будет работать с любыми продуктами Cisco по безопасности? Можно в него завести ASA и встроенный Firepower, добавить WSA, ESA, события из ISE, и прочее?
alukatsky
Пока не с любыми. Только ASA, FirePOWER и сканеры безопасности. Со временем может быть добавить и другие решения