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

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

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

2. Системы анализа уязвимостей

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

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

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

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

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

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

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

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

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

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

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

8. Тестирование ошибок

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

9. Анализ создаваемых объектов

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

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

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

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

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

12. Выбор IDPS

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

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

• Технические спецификации окружения
систем
• Технические спецификации используемой
системы безопасности
• Цели организации
• Возможность формализации окружения
системы и принципы управления,
используемые в организации

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

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

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

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

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

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

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

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

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

• Структурированность
• Описание функций, выполняемых
пользователями системы
• Реакция на нарушения политики
безопасности

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

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

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

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

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

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

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

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

23. Возможности IDPS

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

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

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

25. Ограничения IDPS

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

26. Ограничения IDPS

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