Инструментальные средства

4.4 Дополнительные инструментальные средства

4.4.1 Системы анализа и оценки уязвимостей

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

Анализ уязвимостей — самостоятельная технология управления безопасностью, но она является лишь дополнением к использованию IDPS, а отнюдь не ее заменой. Если организация полагается исключительно на инструментальные средства анализа уязвимостей для слежения за системой, осведомленный атакующий может просмотреть систему анализа уязвимостей, заметить, когда выполняется анализ, и осуществить атаку в интервале между этими проверками.

Тем не менее, системы анализа уязвимостей могут создавать "моментальный снимок" состояния безопасности системы в конкретное время. Более того, так как они являются исключительно системами тестов для поиска уязвимостей, системы анализа уязвимостей могут позволять менеджеру безопасности контролировать ошибки администратора или выполнять аудит системы для анализа согласованности с конкретной политикой безопасности системы.

4.4.2 Разница между системами анализа уязвимостей и системами обнаружения проникновения

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

Последовательность действий при анализе уязвимостей

Общий процесс оценки уязвимостей состоит в следующем:

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

Коммерческие системы оценки уязвимостей часто оптимизируют данный процесс в том, что выполняют одновременно несколько инструментальных средств анализа уязвимостей.

Классификация инструментальных средств анализа уязвимостей

Существует два основных способа классификации систем анализа уязвимостей: первый – по расположению, из которого информация об исследуемой системе получена, и второй – по информации, которой располагает инструментальное средство анализа уязвимостей. В первом способе классификации систем анализа уязвимостей они классифицируются как network-based, и как host-based. При использовании второго способа системы классифицируются как credentialed или non-credentialed. Эти термины указывают, делался ли анализ с использованием или без креденциалами (такими, как ID и пароли или другая идентификационная и аутентификационная информация, с помощью которой предоставляется доступ к внутренним системам). Рассмотрим первый способ классификации для описания различных подходов к анализу уязвимостей.

Host-based анализ уязвимостей

Системы host-based анализа уязвимостей определяют уязвимость, анализируя доступный источник системных данных, такой, как содержимое файлов, параметры конфигурации и другую информацию о состоянии системы. Данная информация обычно доступна с использованием стандартных системных запросов и проверки системных атрибутов. Так как информация получена в предположении, что анализатор уязвимости имеет доступ к хосту, данный тип инструментальных средств анализа также иногда называется credential-based оценка уязвимости. Такая оценка определяется как пассивная.

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

Network-Based анализ уязвимостей

Системы network-based анализа уязвимостей получили распространение в последние несколько лет. Эти системы устанавливают удаленное соединение с целевой системой и пытаются провести реальную атаку. Проведение реальных атак или поиск слабых мест может происходить независимо от того, есть ли разрешение на доступ к целевой системе; следовательно, это можно считать non-credential анализом. Более того, так как network-based анализ уязвимостей выглядит как реальная атака или сканирование целевой системы, он также иногда называется активным анализом.

Инструментальные средства network-based анализа уязвимостей иногда определяются как инструментальные средства обнаружения проникновения. Хотя для некоторых систем такое определение корректно, всё же в большинстве случаев программный продукт анализа уязвимостей не является законченным решением обнаружения проникновения.

Существуют два метода, используемые network-based для оценки уязвимостей:

Тестирование ошибок (exploit’ов) – в этом случае система пытается осуществить реальную атаку. После этого возвращается результат, указывающий, была ли атака успешной.

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

Преимущества систем анализа уязвимостей

• Анализ уязвимостей имеет важное значение как часть системы мониторинга безопасности, позволяя определять проблемы в системе, которые не может определить IDPS.
• Системы анализа уязвимостей имеют возможность выполнять относящееся к безопасности тестирование, которое может использоваться для документирования состояния безопасности систем. Такое тестирование должно выполняться после начальной установки системы.
• Когда системы анализа уязвимостей используются регулярно, они могут надежно обнаруживать изменения в состоянии безопасности системы, оповещая администраторов о проблемах, которые требуют решения.
• Системы анализа уязвимостей предлагают способ комплексной проверки любых изменений, сделанных в системе, гарантируя, что решение одних проблем безопасности не создаст других проблем.

Недостатки и проблемы систем анализа уязвимостей

• Host-based анализаторы уязвимостей сильно привязаны к конкретным ОС и приложениям; следовательно, они часто являются более дорогими с точки зрения развертывания, сопровождения и управления.
• Network-based анализаторы уязвимостей являются платформо-независимыми, но они менее точные и создают больше ложных тревог.
• Некоторые network-based проверки, особенно это относится к DoS-атакам, могут разрушить систему, которую они тестируют.
• При выполнении оценки уязвимостей в сетях, в которых работают системы обнаружения проникновений, IDPS могут блокировать проведение таких оценок. Хуже того, регулярные network-based оценки могут "обучить" некоторые IDPS, основанные на обнаружении аномалий. В результате этого IDPS будут игнорировать реальные атаки.

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

4.4.3 Проверка целостности файлов

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

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

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

4.5 Выбор IDPS

Сегодня доступен широкий выбор программных и аппаратных систем определения проникновения, предназначенных для решения широкого спектра проблем, связанных с безопасностью. Имея такой выбор, определить наиболее подходящую систему для конкретного случая становится достаточно трудно. Ниже перечислены вопросы, которые следует рассмотреть при выборе конкретной IDPS.

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

Выбор наиболее подходящейIDPS

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

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

4.5.1 Определение окружения IDPS

Во-первых, следует понимать, в каком окружении IDPS должна функционировать. Это важно, поскольку если IDPS не развернута с учетом информационных источников, которые доступны системе, она может не иметь возможности видеть все, что делается в сети или системе: как атаку, так и нормальную деятельность.

1. Технические спецификации окружения систем

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

2. Технические спецификации используемой системы безопасности

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

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

3. Цели организации

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

4. Возможность формализации окружения системы и принципы управления, используемые в организации

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

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

4.5.2 Цели использования IDPS

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

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

1. Защита от внешних угроз

   Следует максимально конкретно определить возможные внешние угрозы.

2. Защита от внутренних угроз

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

3. Необходимость обновления систем, за которыми ведется наблюдение

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

4. Возможность использования IDPS для управления сетью

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

4.5.3 Существующая политика безопасности

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

1. Структурированность

   Следует определить цели политики безопасности в терминах стандартных целей безопасности (целостность, конфиденциальность и доступность), а также общих целей управления.

2. Описание функций, выполняемых пользователями системы

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

3. Реакция на нарушения политики безопасности

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

4.6 Требования организации к функционированию IDPS

4.6.1 Цели организации

Цели функционирования организации, ограничения и традиции влияют на выбор IDPS, других инструментальных средств безопасности и технологий для защиты системы. Рассмотрим эти требования и ограничения.

1. Внешние по отношению к IDPS требования

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

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

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

3. Законодательные требования, относящиеся к безопасности и к расследованию инцидентов безопасности

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

   Следует специфицировать все функции IDPS, относящиеся к сбору и защите логов IDPS, которые могут использоваться в качестве судебного доказательства.

4. Требования внутреннего аудита

   Следует рассмотреть, имеются ли какие-либо функции аудита, которые IDPS может предоставлять или поддерживать.

5. Требования аккредитации системы

   Следует рассмотреть, какая аккредитация требуется для IDPS и других систем.

4.6.2 Требования к ресурсам, необходимым для функционирования IDPS

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

1. Бюджет для приобретения и поддержки жизненного цикла аппаратуры, ПО и инфраструктуры IDPS

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

   Некоторые IDPS разработаны в предположении, что персонал будет присутствовать около них в течение всего времени. Если это не представляется возможным, то следует рассмотреть те системы, которые требуют меньшего присутствия.
3. Полномочия для осуществления изменений на основе результатов, предоставленных IDPS

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

4.7 Возможности IDPS

IDPS должна обеспечивать следующие возможности.

1. Масштабируемость используемого программного продукта для конкретного окружения

   Многие IDPS не имеют возможности масштабирования до больших и сильно распределенных сетевых окружений.
2. Протестированность программного продукта

   Простого утверждения, что IDPS имеет определенные возможности, недостаточно для доказательства того, что эти возможности реально существуют. Следует иметь возможность демонстрации соответствия конкретной IDPS требуемому окружению и целям безопасности.

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

4.7.1 Учет возможного роста организации

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

1. Адаптируемость программного продукт к возрастающей квалификации пользователей

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

   Это означает возможность масштабирования IDPS при расширении и увеличении разнородности сети. Большинство производителей могут хорошо адаптировать свои продукты к возрастанию сетей. Следует также узнать о поддержке новых стандартов протоколов и типов платформ.
3. Адаптируемость программного продукта к возрастанию и изменению угроз безопасности

   Данный вопрос особенно актуален для текущего состояния угроз в интернете, когда каждый месяц появляется по 30-40 новых атак.

4.7.2 Предоставляемая поддержка программного продукта

Подобно другим программным продуктам, IDPS требуют постоянного сопровождения и поддержки.

1. Поддержка инсталляции и конфигурирования

   Многие производители предоставляют квалифицированную помощь при инсталляции и конфигурировании IDPS; другие считают, что это могут делать собственные специалисты потребителя, и обеспечивают только поддержку по телефону или e-mail.

2. Возможность непрерывной поддержки программного продукта

   • Существует ли подписка на обновления.

     В большинстве IDPS, которые определяют злоупотребления, программный продукт настолько хорош, насколько база данных сигнатур соответствует текущему состоянию. Большинство производителей предоставляют подписку на обновления сигнатур, которые создаются с некоторой периодичностью.
   • Как часто подписчики получают обновления.

     При современных угрозах, когда ежемесячно публикуется 30-40 новых атак, это является важным фактором.
   • Как быстро после обнаружения новой атаки производитель поставит новую сигнатуру.

     Если IDPS используется для защиты популярных сайтов в интернете, особенно важно получать сигнатуры для новых атак как можно быстрее.
   • Включает ли подписка на обновление также и обновление ПО.

     Большинство IDPS являются программными продуктами и, следовательно, могут содержать ошибки и уязвимости. Таким образом, возможность частого обновления ПО также является весьма существенным фактором.
   • Как быстро выпускаются обновления ПО после того, как о проблеме было сообщено производителю.

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

     Сервисы технической поддержки означают помощь производителя в настройке и адаптации IDPS для конкретных нужд, мониторинге наследуемых систем на предприятии или создание отчетов о результатах IDPS с использованием протокола или формата заказчика.
   • Какой способ контакта (e-mail, телефон, системы мгновенных сообщений , веб-интерфейс) осуществляется для выполнения технической поддержки.

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

     Как и в случае других продуктов ПО, IDPS должны иметь определенные гарантии, связанные с их функционированием.
3. Ресурсы по обучению, предоставляемые производителем как часть пакета услуг

   После того, как IDPS выбрана, инсталлирована и сконфигурирована, она должна обслуживаться персоналом предприятия. Для того чтобы эти люди могли оптимально использовать IDPS, они должны научиться ее использовать. Некоторые производители предоставляют программы обучения как часть пакета услуг.
4. Дополнительные ресурсы, доступные для обучения

   В случае, если производитель IDPS не предоставляет обучение как часть пакета IDPS, следует выделить определенный бюджет для обучения персонала.

4.8 Развертывание IDPS

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

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

4.8.1 Стратегия развертывания IDPS

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

Для защиты сети предприятия рекомендуется рассмотреть комбинацию network-based IDPS и host-based IDPS. Далее следует определить стадии развертывания, начиная с network-based IDPS, так как они обычно являются более простыми для инсталлирования и сопровождения. После этого следует защитить критичные серверы с помощью host-based IDPS. Используя инструментальные средства анализа уязвимостей, следует протестировать IDPS и другие механизмы безопасности относительно правильного конфигурирования и функционирования.

4.8.2 Развертывание network-based IDPS

Единственный вопрос, который следует тщательно продумать при развертывании network-based IDPS, — это расположение системных сенсоров. Существует много вариантов расположения network-based IDPS, каждый из которых имеет свои преимущества:

увеличить изображение
Рис. 4.1. Возможные варианты расположения сенсоров network-based IDPS

Позади внешнего межсетевого экрана в DMZ-сети (расположение 1)

Преимущества:

• Видит атаки, исходящие из внешнего мира, которым удалось преодолеть первую линию обороны сетевого периметра.
• Может анализировать проблемы, которые связаны с политикой или производительностью межсетевого экрана, обеспечивающего первую линию обороны.
• Видит атаки, целями которых являются прикладные серверы (такие, как веб или ftp), обычно расположенные в DMZ.
• Даже если входящая атака не распознана, IDPS иногда может распознать исходящий трафик, который возникает в результате компрометации сервера.

Перед внешним межсетевым экраном (расположение 2)

Преимущества:

• Документирует количество атак, исходящих из интернета, целью которых является сеть.
• Документирует типы атак, исходящих из интернета, целью которых является сеть.

На основной магистральной сети (расположение 3)

Преимущества:

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

В критичных подсетях (расположение 4)

Преимущества:

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

4.8.3 Развертывание host-based IDPS

После того, как network-based IDPS размещены и функционируют, для увеличения уровня защиты системы дополнительно может быть рассмотрено использование host-based IDPS. Однако инсталлирование host-based IDPS на каждый хост может потребовать существенных временных затрат. Поэтому рекомендуется, чтобы в первую очередь host-based IDPS были инсталлированы на критичных серверах. Это может уменьшить общую стоимость развертывания и позволит основное внимание уделить реагированию на тревоги, касающиеся наиболее важных хостов. После того, как host-based IDPS начали функционировать в обычном режиме, организации с повышенными требованиями к безопасности могут обсудить возможность инсталлирования host-based IDPS на другие хосты. В этом случае следует приобретать host-based системы, которые имеют централизованное управление и функции создания отчетов. Такие возможности могут существенно понизить сложность управления сообщениями о тревогах от большого числа хостов.

Далее следует рассмотреть возможность повышения квалификации администраторов. В большинстве случаев эффективность конкретной host-based IDPS зависит от возможности администратора различать ложные и верные тревоги.

Также важно (так как часто администратор не сопровождает постоянно host-based IDPS) установить график проверки результатов IDPS. Если это не сделано, риск, что противник изменит что-либо в IDPS в течение осуществления атаки, возрастает.

4.8.4 Стратегии оповещения о тревогах

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

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

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

4.9 Сильные стороны и ограниченность IDPS

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

4.9.1 Сильные стороны IDPS

IDPS хорошо выполняют следующие функции:

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

4.9.2 Ограничения IDPS

IDPS имеют много ограничений. Наиболее существенные следующие:

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

4.10 Выходные данные IDPS

Почти все IDPS имеют в качестве выходной информации строку сообщения о каждой обнаруженной атаке. Эта строка обычно содержит перечисленные ниже поля:

• время и дату;
• IP-адрес сенсора;
• название атаки, специфичное для производителя;
• стандартное название атаки (если оно существует);
• IP-адреса источника и назначения;
• номера портов источника и назначения;
• сетевой протокол, используемый для атаки.

Многие IDPS также предоставляют более подробное описание каждого типа атаки. Данное описание важно, так как оно дает возможность администратору уменьшить ущерб, наносимый атакой.

Данное описание обычно содержит следующую информацию:

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

4.11 Будущие направления развития IDPS

Хотя функция аудита системы, которая являлась первоначальной задачей IDPS за последние пятьдесят лет, стала формальной дисциплиной, поле для исследований IDPS все еще остается обширным, большинство исследований датировано не позднее 80-х годов. Более того, широкое коммерческое использование IDPS не начиналось до середины 90-х.

Intrusion Detection и Vulnerability Assessment является быстро развивающейся областью исследований.

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

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

Более того, очень вероятно, что основные возможности IDPS скоро станут ключевыми в сетевой инфраструктуре (такой, как маршрутизаторы, мосты и коммутаторы) и в операционных системах. При этом скорее всего разработчики IDPS сфокусируют свое внимание на решение проблем, связанных с масштабируемостью и управляемостью IDPS.

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

Наконец, механизмы, связанные с управлением рисками в области сетевой безопасности, будут оказывать влияние на требования к IDPS.