Программа управления обнаружением и устранением уязвимостей (NIST SP 800-40 v. 2.0)

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

(Ключевые моменты)

 NIST Special Publication 800-40 Version 2.0. Creating a Patch and Vulnerability Management Program.

 

1. Введение.

2. Процесс управления уязвимостями и обновлениями.

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

 

2.1. Рекомендованный процесс.

NIST рекомендует организациям создать группу управления уязвимостями (patch and vulnerability group, PVG), которая будет реализовать программу управления уязвимостями. Поскольку PVG должна активно работать с администраторами систем, для крупных организаций может потребоваться несколько PVG. Рекомендации в данном документе основаны на предположении, что в организации действует только одна PVG.

Организация должна стремиться передать (в максимально возможном объеме) от локальных администраторов к PVG, обязанности по тестированию и внедрению исправлений уязвимостей. Это позволит сэкономить ресурсы за счет устранения дублирования обязанностей (например, несколько системных администраторов тестируют одни и те же обновления для одинаковых систем) и, использования автоматизированных решений, что позволяет избежать ресурсоемкой ручной установки. Самый простой способ достижения этой цели — внедрение корпоративных решений по управлению обновлениями, которые позволяют PVG, автоматически устанавливать патчи на большом количестве систем. Если автоматизированные средства управления обновлениями не доступны, PVG должна координировать усилия администраторов.

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

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

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

 

2.1.1. Группа управления уязвимостями.

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

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

Возможные обязанности PVG:

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

 

2.1.1. Администраторы систем.

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

 

2.2. Создание инвентаря активов.

NIST рекомендует PVG использовать существующие в организации системы инвентаризации ИТ-ресурсов, для определения, какие аппаратные средства, операционные системы, и приложения используются, а затем провести группировку и приоритезацию этих ресурсов. PVG следует вести вручную инвентарь ИТ-ресурсов, не зафиксированных в существующих системах инвентаризации. Имея в наличии инвентарь активов с определенными для них приоритетами, PVGдолжна определить, какие аппаратные и программные средства будут участвовать в процессе управления уязвимостями.

 

2.1.2. Инвентарь ИТ

Ниже приведен примерный список характеристик актива, которые организация может включить в их инвентарь (не все характеристики будут применяться ко всем ИТ-ресурсам):

1. Имя системы.

2. Порядковый номер.

3. Владелец ИТ ресурса (т.е., основной пользователь).

4. Системный администратор.

5. Физическое местоположение.

6. Сетевой порт (к которому подключен актив).

7. Настройки программного обеспечения:

  • Наименование и номер версии операционной системы.
  • Установленное программное ПО с номерами версий.
  • Используемые службы (сервисы).
  • IP-адрес (если статический).

8. Настройки аппаратного обеспечения:

  • Центральный процессор
  • Память
  • Дисковое пространство
  • MAC адрес
  • Поддержка беспроводных сетей
  • Посты ввода/вывода (например, USB, Firewire)
  • Версия прошивки

 

2.2.2. Группировкаиприоритезацияактивов.

Ресурсы, входящие в инвентарь активов, должны быть сгруппированы. Также для активов необходимо определить уровень приоритета. Группировка и приоритезация активов является полезной для оценки риска систем, и должна использоваться, чтобы помочь определить, какие системы могут потребовать особого внимания в управлении уязвимостями. Основную группировку необходимо осуществлять на основании FederalInformationProcessingStandard (FIPS) 199. Также может быть полезно, группировать активы на основании их местоположения в сети. Это особенно важно для тех ресурсов, которые непосредственно подключены к сети Интернет.

 

2.2.2.1. NIST Special Publication 800-18

Руководство по группировке ИТ-ресурсов аккредитованных систем представлено в NIST SP 800-18. В нем предлагается группировать ИТ-ресурсы, на основании следующих показателей:

  • Элементы находятся под одним управлением/контролем.
  • Элементы выполняют одинаковые функции, или миссии/цели.
  • Элементы имеют схожие эксплуатационные характеристики безопасности, и потребности в защите.
  • Элементы принадлежат к общей одинаковой среде функционирования.

 

2.2.2.2. FederalInformationProcessingStandard 199

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

 

2.2.2.3. Приоритезация внутри систем.

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

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

 

2.2.3. Использование.

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

 

2.3. Мониторинг угроз уязвимостей и исправлений.

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

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

Есть несколько типов источников, доступных для поиска информации об угрозах, уязвимостях и исправлениях. Приложение D содержит перечень ресурсов. Каждый тип источника информации имеет свои сильные и слабые стороны. NIST рекомендует использовать более одного типа источника информации. Наиболее распространенными типамиявляются:

  • Веб-сайты и рассылки поставщиков
  • Веб-сайты третьих сторон
  • Сторонние рассылки и группы новостей
  • Сканеры уязвимостей
  • Базы данных уязвимостей
  • Инструменты управления обновлениями уровня предприятия
  • Другие инструменты уведомления.

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

NIST рекомендует организациям использовать как минимум следующие типы ресурсов:

  • Инструменты управления обновлениями, чтобы получить все доступные патчи от поддерживаемых поставщиков.
  • Списки рассылки и веб-сайты производителей, чтобы получить все доступные патчи, для приложений, не поддерживаемых автоматизированной системой управления обновлениями организации.
  • Базы данных уязвимостей или списки рассылки для получения оперативной информации обо всех известных уязвимостях и предлагаемых исправлениях (например, National Vulnerability Database).
  • Списки рассылки от третьих сторон, которые подчеркивают самые критические уязвимости (например, US-CERTCyberSecurityAlerts). Такие списки помогут сосредоточиться на наиболее важных уязвимостях.

 

2.4. Определение приоритета по устранению уязвимостей.

При определении приоритетов устранения уязвимостей PVG должна рассматривать угрозу и ее потенциальное влияние на организацию. Для такой оценки необходимо:

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

 

2.5. Создание базы данных исправлений, учитывающей специфику организации.

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

 

2.6. Тестирование исправлений.

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

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

 

2.7. Установка исправлений уязвимостей.

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

  • установка обновления (патча),
  • изменение конфигурации,
  • удаление уязвимого ПО.

 

2.8. Распространение информации об уязвимостях и исправлениях администраторам.

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

 

2.9. Верификация установленных исправлений.

PVG и системные администраторы должны убедиться в устранении уязвимостей. Это может быть достигнуто несколькими способами:

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

 

2.10. Обучение по устранению уязвимостей.

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

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

 

2.11. Рекомендации

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

Рекомендации для организаций, внедряющих программу управления уязвимостями и обновлениями:

1. Создать инвентарь всех ИТ-активов.

2. Создать группу управления уязвимостями.

3. Осуществлять непрерывный мониторинг на наличие угроз, уязвимостей и исправлений.

4. В соответствии с приоритетностью систем осуществлять поэтапную установку обновлений (по мере необходимости).

5. Тестировать исправления перед их применением.

6. Развернуть в масштабах предприятия решение, позволяющее централизованно управлять установкой обновлений.

7. Создать базу данных исправлений (может входить в состав решения по управлению обновлениями).

8. Использовать автоматическое обновление приложений (по мере необходимости).

9. Проверять устранение уязвимостей.

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

 

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

В этом разделе рассказывается, как разработать и внедрить метрики для оценки программы управления уязвимостями. NIST SP 800-55, Security Metrics Guide for Information Technology Systems являетсяосновойподхода, описанногонастоящемразделе.

Каждая организация должна последовательно измерять эффективность своей программы управления уязвимостями и применять корректирующие действия по мере необходимости. Это может быть сделано путем разработки метрик. Организации должны документировать показатели для каждой системы и детальное описание каждого из показателей. Реальные целевые показатели должны быть доведены до владельцев систем и сотрудников служб безопасности.

 

4. Вопросы управления уязвимостями и обновлениями.

4.1. Решения по управлению обновлениями

Существует два основных типа решений по управлению обновлениями систем:

  • без агента.
  • с использованием агента.

Такие решения могут обладать дополнительными возможностями, таким как:

  • Инвентаризации ПО.
  • Сканирования уязвимостей.

В то время как нестандартные системы и устаревшие компьютеры могут помешать масштабному развертыванию, вопросы взаимодействия c IT персоналом и владельцами систем могут быть еще большей проблемой. Владельцы систем (и пользователи компьютеров) могут иметь некоторые первоначальные сомнения по поводу предоставления доступа к своим компьютерам. Например, такие как:

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

 

4.2. Снижение необходимости установки патчей.

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

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

 

4.3. Использование стандартных конфигураций.

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

  • Тип оборудования и модель.
  • Версия операционной системы и уровень обновлений.
  • Основные установленные приложения (Версия и уровень обновлений).
  • Параметры безопасности для операционной системы и приложений.

NIST SP 800-70, Security Configuration Checklists Program for IT Products—Guidance for Checklists Users and Developers, представляет собой руководство по созданию и использованию контрольных списков конфигураций безопасности, которое будет полезно для документирования стандартных настроек безопасности.

 

4.4. Установка исправлений после инцидентов.

Установка исправлений  после компрометации системы — является значительно более сложным, чем простое применение соответствующих патчей. Хотя применения патча безопасности, как правило, исправит уязвимость, которая была использована для компрометации системы, это не устранит руткитов, бэкдоров, или большинство других изменений, которые могут быть сделаны нарушителем. В большинстве случаев система должна быть переформатирована и установлена заново, или восстановлена из безопасной и надежной резервной копии. NIST SP 800-61, Computer Security Incident Handling Guide — хороший источник информации по обработке инцидентов безопасности и восстановлению взломанных систем.

 

5. Ресурсы США по управлению уязвимостями:

5.1. US-CERT National Cyber Alert System

  • Cyber Security Alerts. http://www.us-cert.gov/cas/alerts/
  • Cyber Security Tips. http://www.us-cert.gov/cas/tips/
  • Cyber Security Bulletins. http://www.us-cert.gov/cas/bulletins/

5.2. Common Vulnerabilities and Exposures (CVE). http://cve.mitre.org/

5.3. National Vulnerability Database (NVD). http://nvd.nist.gov/

5.4. US-CERT Vulnerability Notes Database. http://www.kb.cert.org/vuls/

5.5. Open Vulnerability Assessment Language (OVAL). http://oval.mitre.org/

 

6. Заключение и основные рекомендации

Краткое изложение рекомендаций настоящего документа:

1. Создать группу управления уязвимостями.

2. . Осуществлять непрерывный мониторинг угроз, уязвимостей и исправлений.

3. В соответствии с приоритетностью систем осуществлять поэтапную установку обновлений (по мере необходимости).

4. Тестировать исправления перед их применением.

5. Развернуть в масштабах предприятия решение, позволяющее централизованно управлять установкой обновлений.

6. Использовать автоматическое обновление приложений (по мере необходимости).

7. Создать инвентарь всех ИТ-ресурсов.

8. Где возможно, использовать стандартные конфигурации для ИТ-ресурсов.

9. Проверять устранение уязвимостей.

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

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