11.09.2013

IPS мертвы или их просто недостаточно?

Помните ли вы, что в 2003-м году многие аналитики и журналисты активно публиковали материалы с заголовками "системы обнаружения атак мертвы". И проблемы с IDS уже тогда были достаточно понятны и очевидны - ложные срабатывания и необнаружения реальных атак. Но шумиха шумихой, красивые названия красивыми названиями, а проблема реально существовала и существует, но относилась она не к системам обнаружения атак - это проблема управления и визуализации данных, получаемых средствами безопасности. Именно тогда стали появляться первые SIEM-решения, которые и взяли на себя непростую задачу по отсеиванию из миллионов событий безопасности того, что могло заинтересовать службы ИБ. Но вернемся к IDS.

Давайте вспомним, где традиционно ставится система обнаружения вторжений? Преимущественно на периметре корпоративной или ведомственной сети. Потому что там проще контролировать входящий трафик и там нет проблем с доступом к трафику. Внутри локальной сети внедрение IDS превращается в шаманство. Либо вы должны использовать коммутаторы с модулями IPS (а такой вендор в мире всего один), либо пытаться перенаправить трафик с нескольких портов коммутатора на порт, к которому и подключен сенсор IPS. Но тут возникают сложности - и порт этот может быть занят, и трафик коммутируется не весь, и производительности сенсора не хватает, и сетевики не дают снизить производительность коммутатора за счет перенаправления всего трафика на IPS. А если еще вспомнить про способы обхода IDS/IPS, то становится понятно, что одних систем предотвращения вторжений явно не хватает для эффективного решения контроля трафика на предмет поиска в нем вредоносного кода.



Чем можно расширить защитные свойства IPS? Ну очевидно - межсетевые экраны, сетевые антивирусы, системы контентной фильтрации... Это распространенные защитные стратегии, которым следуют многие компании и предприятия.


Но достаточно ли их? Очевидно, что сигнатурные методы, а большинство современных средств защиты (что бы производители не говорили об эвристических механизмах) все-таки не спасают от многих угроз. По крайней мере в реальном масштабе времени. Да, 95% всех атак происходит из-за известных дыр, знанием о которых средства защиты оснащены. Но ведь остаются еще 5%. Они и составляют сегодня основную угрозы. По данным разных компаний рост целенаправленных (или как говорят апологеты "русского" языка - таргетированных) атак составляет от 35 до 50 процентов за прошедший год. Это большие цифры. Атаки перестают быть массовыми. Их сложно становится ловить с помощью традиционным подходов. Ловушки, обманные системы тут не срабатывают. Ведь они ставятся в местах массового протекания трафика (так действуют многие антивирусные компании) и, следовательно, пропускают целенаправленные атаки, разработанные под конкретную жертву. Потом, может быть, антивирусный вендор узнает об этой угрозе, но может пройти и год и два, прежде чем наступит это радостное событие. Достаточно вспомнить Stuxnet, Duqu, Flame, чтобы понять, что это правда.


Значит ли это, что традиционные сигнатурные подходы и средства, их реализующие, мы должны выбросить на помойку? Конечно нет. Свою задачу они решают и решают неплохо. Но только свою. Они являются необходимым, но уже явно недостаточным условием для построения эффективной защиты. Новым решением, устраняющим зияющие пробелы в системе защиты, могут стать системы сетевого поведенческого анализа (network-based behavior monitorig/analysis или network-based anomaly detection).


Их идея проста. Что объединяет всех? Пользователей, разные устройства, разные ОС, разные приложения... Сеть! Именно по ней передается трафик, который мы и должны контролировать. Но с точки зрения поиска узких мест в сети, источников широковещательного трафика, точек потери пакетов и т.п., а с точки зрения получения доступа к такому набору информации, который позволяет ответить нам на множество насущных вопросов, важных для борьбы с внутренней угрозой (с внешней мы научились худо-бедно бороться).


В чем преимущество такого решения? Оно видит все - на него передается информация по протоколу NetFlow (или sFlow) с любого сетевого устройства - коммутатора, включая виртуального, маршрутизатора, включая облачного, и т.п. И средства защиты ему могут передавать такую информацию (например, есть межсетевые экраны, отдающие статистику по NetFlow). И даже приложения и виртуальные сервера - они тоже могут. Иными словами решения по анализу сетевого трафика могут служить его коллекторами. Но чем тогда такой коллектор отличается от IPS? Не только объемом собранной информации.



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


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


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


Или просто ответить на вопрос: "Какими приложениями чаще всего пользуются работники и служащие?" Например, применяются ли пиринговые приложения для обхода традиционных защитных средств?


Ну и конечно, как и у любого корпоративного продукта, информацию и аналитику можно получать по разным срезам и за разные интервалы времени.



Если подытожить, то что дают такие решения для безопасников помимо описанных выше преимуществ? Ну, во-первых, эти решения можно использовать совместно с айтишниками (и наоборот). Собираемые исходные данные одни и те же - сетевой трафик. Во-вторых, эти решения идеально подходят в тех случаях, когда периметр сети размывается и сложно найти одну-две точки, куда и можно воткнуть межсетевой экран с системой предотвращения вторжений. Системам сетевого анализа все равно откуда идет трафик - если он проходит через коммутатор или маршрутизатор, сведения о нем по NetFlow можно перенаправить куда угодно и там проанализировать. В условиях активного размывания границ периметра, перехода на корпоративную мобильность, обращения к аутсорсингу ЦОДов и облачным вычислениям это становится более чем актуально. В-третьих, эти решения эффективно функционируют и в виртуальных средах, для которых средств защиты пока не так и много. И наконец, эти средства не относятся к средствам защиты информации, а следовательно не подлежат обязательной сертификации. Пустячок, а приятно и иногда облегчает жизнь.

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

12 коммент.:

Tomas комментирует...

Алексей, а чего презентацию то не выложили про совместное с lancope решение (интригуете?): http://www.slideshare.net/CiscoRu/cisco-cyber-threat-defense?ref=http://gblogs.cisco.com/ru/ctd/

Про то, что это не СЗИ и не нужно сертифицировать - ну его то не нужно, допустим, но то, с чего он берет NetFlow то нужно - FW, IPS... Кроме того, таких решений, как CTD, ФСТЭК не описал в своих новых приказах (а вот про FW, IDS написал), соответственно для ГИС и КСИИ оно не подойдет, а именно на них в основном и будут направлены те самые таргетированные атаки (и об НДВ не забудем). В связи с чем вопрос - Cisco Russia каким-то образом собирается сертифицировать это решение (это же и для облачных провайдеров будет интереснее с сертификатом, так как ПДн)? Что-то с НДВ планируете делать?

Сергей Борисов комментирует...

Поддержу идею о том что в локальной сети эффективнее будет использовать централизованную систему анализа трафика (по rspan, netflow, syslog) чем размещать большое количество IPS а потом консолидировать информацию с них.

А из решений, кроме Lancope stealthwatch есть ещё Arbor Pravail NSI

Tomas комментирует...

А с идеей я и не спорю! Вы о чьей такой локалке говорите, что такие решения предлагаете, этож не дешево?
Arbor Pravail NSI - вообще железка по описанию..., сертификатов нет, как мне кажется?

Алексей Лукацкий комментирует...

А на соедства анализа трафика сертификаты не нужны

Алексей Лукацкий комментирует...

Речь идет о распределенных сетках, т.к. на небольших можно использовать бесплатные коллекторы и анализаторы

Tomas комментирует...

Алексей, название поста "IPS мертвы или их просто недостаточно?" - соответственно, если CTD является расширением функционала IPS, то при обнаружении вторжения что она будет делать - не отдавать ли команду IPS, FW.. на блокировку (насколько я понял, это средство контроля и управления NetFlow)? а если блокировка приведет к остановке бизнес-процесса какого-то, причем ошибочная блокировка? ну или я не правильно понял суть CTD...

Алексей Лукацкий комментирует...

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

Сергей Борисов комментирует...

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

Правильнее говорить что централизованная системы анализа трафика заменяет или дополняет IPS.

Tomas комментирует...

Сергей, да без разницы "заменяет" или "дополняет" IPS - это средство защиты, вот я к чему! А раз СЗИ, то сертификация.
Алексей, а штука классная, судя по описанию! Внедрения есть? Напишите пост о практическом применении? Сергей, и Вы!?

Алексей Лукацкий комментирует...

Напишу. Но уже в корпоративном блоге ;-)

Anatolii Shavlovskyi комментирует...

Как решить проблему защиты в режиме реал-тайм? Ланскопе самостоятельно не блокирует атаку и соответственно время реакции может достигнуть 10 мин.

Алексей Лукацкий комментирует...

Во-первых, Cisco Cyber Threat Defense умеет блокировать, но надо понимать, что это не его функция. Его основная задача - мониторинг и контроль, а не предотвращение.

И далеко не все атаки внутри требуют мгновенной реакции. Это ж не периметр