КОНТРОЛЬ ЗАЩИЩЕННОСТИ ИНФОРМАЦИОННЫХ

СИСТЕМ И ВЫПОЛНЕНИЕ ТРЕБОВАНИЙ

ЗАКОНОДАТЕЛЬСТВА

Дополнительные материалы к докладу на конференции «IT Security Conference 2017» Подготовили:

Вячеслав Аксенов, IT Security Architect, R&D Department, ActiveCloud, viacheslav.aksionov@activecloud.com;

Наталья Насонова, канд.техн.наук, доцент, доцент кафедры Защиты информации Белорусского государственного университета информатики и радиоэлектроники, natallianasonova@gmail.com.

_____________________________________________________________________________________

_____________________________________________________________________________________

г. Минск, 2017

2

ОГЛАВЛЕНИЕ 1. ВВЕДЕНИЕ ................................................................................................................................................. 4

2. ИСТОЧНИКИ ТРЕБОВАНИЙ ...................................................................................................................... 5

2.1. Нормативные правовые акты Республики Беларусь .................................................................... 5

Требование № 41. «Выявление уязвимостей информационной системы и оперативное их

устранение». ........................................................................................................................................ 5

Требование № 42. «Контроль за установкой обновлений программного обеспечения, включая

обновление программного обеспечения средств защиты информации». .................................... 6

Требование № 43. «Контроль за работоспособностью, параметрами настройки и

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

информации». ...................................................................................................................................... 6

Требование № 44. «Контроль за неизменностью состава технических средств, программного

обеспечения и средств защиты информации». ................................................................................ 7

2.2. CIS Critical Security Controls .............................................................................................................. 7

CSC 1. Инвентаризация авторизованного и неавторизованного оборудования. .......................... 7

CSC 2. Инвентаризация авторизованного и неавторизованного программного обеспечения. ... 9

CSC 3. Безопасная конфигурация программного и аппаратного обеспечения ноутбуков,

рабочих станций и серверов. ........................................................................................................... 11

CSC 4. Регулярное выявление и устранение уязвимостей. ............................................................ 13

CSC 20. Проведение тестирования на проникновение и учений. ................................................. 15

2.3. ISO/IEC 27001:2013 «Информационные технологии. Методы защиты. Системы менеджмента

информационной безопасности. Требования». ................................................................................. 16

A.8.1.1. Инвентаризация активов. .................................................................................................... 16

A.12.6.1. Контроль технических уязвимостей. ................................................................................ 17

A.14.2.8. Тестирование защищенности системы. ........................................................................... 18

A.18.2.1. Независимый анализ информационной безопасности. ................................................. 18

A.18.2.3. Анализ технического соответствия. .................................................................................. 19

2.4. Payment Card Industry Data Security Standard (PCI DSS). .............................................................. 20

Требование 2. Не использовать пароли и другие системные параметры, заданные

производителем по умолчанию. ..................................................................................................... 20

Требование 6. Разрабатывать и поддерживать безопасные системы и приложения. ............... 20

Требование 11. Регулярно выполнять тестирование систем и процессов обеспечения

безопасности. ..................................................................................................................................... 21

3. ОСОБЕННОСТИ ИСПОЛЬЗОВАНИЯ СРЕДСТВ КОНТРОЛЯ ЗАЩИЩЕННОСТИ (НПА РБ) ...................... 21

3.1. Положение о технической и криптографической защите информации в Республике

Беларусь, утверждено Указом Президента Республики Беларусь 16.04.2013 № 196. ................... 21

3.2. Закон Республики Беларусь от 10 ноября 2008 г. № 455-З «Об информации,

информатизации и защите информации». ......................................................................................... 22

3.3. Технический регламент Республики Беларусь «Информационные технологии. Средства

защиты информации. Информационная безопасность» (ТР 2013/027/BY). .................................... 22

3

3.4. Положение о порядке технической защиты информации в информационных системах,

предназначенных для обработки информации, распространение и (или) предоставление

которой ограничено, не отнесенной к государственным секретам, утверждено приказом

Оперативно-аналитического центра при Президенте Республики Беларусь 30.08.2013 № 62. .... 23

4. РАЗРАБОТКА ПРОГРАММЫ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ ............................................................. 23

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

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

4.1.2. Создание реестра активов. ..................................................................................................... 25

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

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

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

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

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

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

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

4.1.10. Проведение обучения по устранению уязвимостей. ......................................................... 29

4.1.11. Рекомендации ....................................................................................................................... 29

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

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

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

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

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

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

4.4. Ресурсы с информацией по управлению уязвимостями: ........................................................... 32

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

5. OPEN-SOURCE ИНСТРУМЕНТЫ. ............................................................................................................. 32

5.1. Nmap / Zenmap................................................................................................................................ 32

5.2. OpenVAS........................................................................................................................................... 33

5.3. Metasploit Framework / Armitage. .................................................................................................. 33

5.4. w3af .................................................................................................................................................. 34

5.5. Hydra ................................................................................................................................................ 34

6. ОБЩЕДОСТУПНЫЕ ИСТОЧНИКИ ИНФОРМАЦИИ ОБ УЯЗВИМОСТЯХ ................................................ 35

7. КУРСЫ ОБУЧЕНИЯ .................................................................................................................................. 36

7.1. Контроль (анализ) защищенности информационных систем .................................................... 36

7.2. CIS Critical Security Controls. Аудит и внедрение. ......................................................................... 36

4

1. ВВЕДЕНИЕ Контроль защищенности информационной системы играет важную роль как на этапе ввода

в действие информационной системы так в ходе ее эксплуатации (функционирования).

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

компонентов комплекса программно-технических средств, могут привести к

несанкционированному доступу к объектам информационной системы, раскрытию или

краже конфиденциальной информации, нарушению требований законодательства и

регуляторов, прерыванию бизнес-процессов организации.

В соответствии с действующим законодательством Республики Беларусь об информации,

информатизации и защите информации, требования, связанные с обеспечением контроля

защищенности информационной системы, являются обязательными для включения в

техническое задание на систему защиты информации или задание по безопасности на

информационную систему, предназначенную для обработки информации,

распространение и (или) предоставление которой ограничено, не отнесенной к

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

международных стандартах и рекомендациях, связанных с вопросами обеспечения

информационной безопасности, например, таких как PCI DSS, ISO/IEC 27002, CIS Critical

Security Controls.

НПА Республики Беларусь

ISO/IEC 27001:2013

PCI DSS

CIS Critical Security Controls

КОНТРОЛЬ (АНАЛИЗ)

ЗАЩИЩЕННОСТИ

5

2. ИСТОЧНИКИ ТРЕБОВАНИЙ

2.1. Нормативные правовые акты Республики Беларусь

ПОЛОЖЕНИЕо порядке технической защиты информации

в информационных системах, предназначенных для обработки

информации, распространение и (или) предоставление которой ограничено, не

отнесенной к государственным секретам, утвержденное приказом Оперативно-

аналитического центра при Президенте Республики Беларусь

30.08.2013 62 (в редакции приказа Оперативно-аналитического центра при

Президенте Республики Беларусь 16.01.2015 3)

ПЕРЕЧЕНЬтребований к системе защиты информации, подлежащих включению

в задание по безопасности на информационную систему или в техническое задание на информационную систему

Требование 41. «Выявление уязвимостей информационной системы и оперативное их устранение».

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

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

Требование 44. «Контроль за неизменностью состава технических средств,

программного обеспечения и средств защиты информации».

Требование № 41. «Выявление уязвимостей информационной системы и оперативное их

устранение».

Выявление (поиск) уязвимостей, связанных с ошибками кода в программном

(микропрограммном) обеспечении (общесистемном, прикладном, специальном), а

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

установки и настройки средств защиты информации, технических средств и

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

информации при их взаимодействии с техническими средствами и программным

обеспечением.

Разработка по результатам выявления (поиска) уязвимостей отчетов с описанием

выявленных уязвимостей и планом мероприятий по их устранению.

Анализ отчетов с результатами поиска уязвимостей и оценки достаточности

реализованных мер защиты информации.

Устранение выявленных уязвимостей, в том числе путем установки обновлений

программного обеспечения средств защиты информации, общесистемного

программного обеспечения, прикладного программного обеспечения или

микропрограммного обеспечения технических средств.

Информирование должностных лиц (пользователей, администраторов,

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

достаточности реализованных мер защиты информации.

В качестве источников информации об уязвимостях используются опубликованные

данные разработчиков средств защиты информации, общесистемного, прикладного

и специального программного обеспечения, технических средств, а также другие

базы данных уязвимостей.

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

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

информационной системы.

6

Требование № 42. «Контроль за установкой обновлений программного обеспечения,

включая обновление программного обеспечения средств защиты информации».

Получение из доверенных источников и установка обновлений программного

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

программное обеспечение базовой системы ввода-вывода.

Проверки соответствия версий общесистемного, прикладного и специального

программного (микропрограммного) обеспечения, включая программное

обеспечение средств защиты информации, установленного в информационной

системе и выпущенного разработчиком, а также наличие отметок в

эксплуатационной документации (формуляр или паспорт) об установке

(применении) обновлений.

Контроль за установкой обновлений проводится с периодичностью, установленной

в локальных нормативных правовых актах владельца информационной системы и

фиксируется в соответствующих журналах.

При контроле установки обновлений осуществляются проверки установки

обновлений баз данных признаков вредоносных компьютерных программ

(вирусов) средств антивирусной защиты, баз решающих правил систем

обнаружения вторжений в соответствии, баз признаков уязвимостей средств

анализа защищенности и иных баз данных, необходимых для реализации функций

безопасности средств защиты информации.

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

обеспечения регламентируются в локальных нормативных правовых актах

владельца информационной системы.

Требование № 43. «Контроль за работоспособностью, параметрами настройки и

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

информации».

Контроль работоспособности (неотключения) программного обеспечения и средств

защиты информации.

Проверка правильности функционирования (тестирование на тестовых данных,

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

информации.

Контроль соответствия настроек программного обеспечения и средств защиты

информации параметрам настройки, приведенным в эксплуатационной

документации на систему защиты информации и средства защиты информации.

Восстановление работоспособности (правильности функционирования) и

параметров настройки программного обеспечения и средств защиты информации

(при необходимости), в том числе с использованием резервных копий и (или)

дистрибутивов.

Контроль за работоспособностью, параметрами настройки и правильностью

функционирования программного обеспечения и средств защиты информации

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

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

7

Требование № 44. «Контроль за неизменностью состава технических средств, программного

обеспечения и средств защиты информации».

Контроль соответствия состава технических средств, программного обеспечения и

средств защиты информации приведенному в эксплуатационной документации с

целью поддержания актуальной (установленной в соответствии с эксплуатационной

документацией) конфигурации информационной системы и принятие мер,

направленных на устранение выявленных недостатков.

Контроль состава технических средств, программного обеспечения и средств

защиты информации на соответствие сведениям действующей (актуализированной)

эксплуатационной документации и принятие мер, направленных на устранение

выявленных недостатков.

Контроль выполнения условий и сроков действия сертификатов соответствия на

средства защиты информации и принятие мер, направленных на устранение

выявленных недостатков.

Исключение (восстановление) из состава информационной системы

несанкционированно установленных (удаленных) технических средств,

программного обеспечения и средств защиты информации.

Контроль за неизменностью состава технических средств, программного

обеспечения и средств защиты информации проводится с периодичностью,

установленной в локальных нормативных правовых актах владельца

информационной системы.

2.2. CIS Critical Security Controls1

CIS Critical Security Controls

CSC 1 Inventory of Authorized and Unauthorized Devices

CSC 2 Inventory of Authorized and Unauthorized Software

CSC 3 Secure Configurations for Hardware and Software on Mobile Devices, Laptops,

Workstations, and Servers

CSC 4 Continuous Vulnerability Assessment and Remediation

CSC 20 Penetration Tests and Red Team Exercises

Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access

Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and unauthorized and unmanaged software is found and prevented from installation or execution

Establish, implement, and actively manage (track, report on, and correct) the security configuration of laptops, servers, and workstations using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings

Continuously acquire, assess, and take action on new information in order to identify vulnerabilities, and to remediate and minimize the window of opportunity for attackers

Test the overall strength of an organization s defenses (technology, processes, and people) by simulating the objectives and actions of an attacke

CSC 1. Инвентаризация авторизованного и неавторизованного оборудования.

Реализация:

Необходимо развернуть автоматизированный инструмент по обнаружению

ресурсов и с его помощью составить предварительный перечень ресурсов,

подключенных к сети организации. Для этого должны использоваться как активные

1 https://www.cisecurity.org/critical-controls/

8

инструменты, сканирующие области IP-адресов, так и пассивные инструменты,

которые идентифицируют активное оборудование на основе анализа их трафика.

Необходимо обеспечить ведение реестра ресурсов всех систем, подключенных к

сети, и сетевых устройств, регистрируя, по крайней мере, IP-адреса, FQDN,

назначение каждой системы, владельцев ресурсов, ответственных за каждое

устройство, и отдел, к которому относится каждое устройство. Реестр должен

включать все системы, использующие IP-адреса, включая рабочие станции,

ноутбуки, серверы, сетевые оборудование (маршрутизаторы, концентраторы,

межсетевые экраны и т.д.), принтеры, системы хранения данных, VoIP-телефоны и

другие возможные виды устройств.

Созданный реестр ресурсов должен содержать данные, является ли устройство

портативным. Такие устройства, как мобильные телефоны, планшеты, ноутбуки и

другие портативные электронные устройства, хранящие или обрабатывающие

информацию, должны быть идентифицированы независимо от того, соединены они

с сетью организации или нет.

Необходимо обеспечить работоспособность и непрерывное функционирование

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

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

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

и/или ИТ персонал при обнаружении отклонений.

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

периодические проверки на уязвимость и шифрование информации. Нужно

ограничить доступ к этой системе только авторизованным персоналом и вести

подробный журнала регистрации доступа. Для повышения безопасности

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

отдельно от производственной сети.

В дополнение к реестру оборудования организациям следует разработать реестр

информационных ресурсов, описывающий критичную информацию и

привязывающий ее к аппаратным ресурсам (включая серверы, рабочие станции и

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

контролировать отдел и персонально ответственного за каждый информационный

ресурс.

Необходимо использовать аутентификацию устройств по протоколу 802.1x для

ограничения и контроля устройств, подключаемых к сети. Протокол 802.1x должен

быть привязан к данным реестра для определения авторизованных и

неавторизованных систем.

Управление сетевым доступом (NAC) может использоваться для мониторинга

авторизованных систем так, что при возникновении атаки ее воздействие может

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

локальную сеть с минимальными возможностями доступа.

9

Взаимодействие между объектами системы:

Шаг 1: Активный сканер сканирует сетевые системы и ресурсы.

Шаг 2: Пассивный сканер осуществляет захват трафика между системами и

ресурсами.

Шаг 3: Активный сканер передает отчеты в базу данных инвентаризации.

Шаг 4: Пассивный сканер передает отчеты в базу данных инвентаризации.

Шаг 5: База данных инвентаризации хранится офлайн.

Шаг 6: База данных инвентаризации инициирует срабатывание системы

оповещения через систему SIEM.

Шаг 7: Система оповещения уведомляет специалистов отдела безопасности.

Шаг 8: Специалисты отдела безопасности осуществляют мониторинг защищённой

базы данных инвентаризации.

Шаг 9: Специалисты отдела безопасности при необходимости обновляют данные в

защищенной базе данных инвентаризации.

Шаг 10: Система управления доступом непрерывно контролирует сеть.

Шаг 11: Система управления доступом осуществляет проверку обновлений в базе

данных инвентаризации активов.

CSC 2. Инвентаризация авторизованного и неавторизованного программного обеспечения.

Реализация:

Определите список авторизованного ПО, требующегося предприятию для каждого

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

назначений.

Разверните инструменты ведения реестра ПО по всей организации, включая все

типы используемых операционных систем на серверах, рабочих станциях и

ноутбуках. Система ведения реестра ПО должна отслеживать версии основных

операционных систем, а также инсталлированных приложений. Инструмент должен

10

регистрировать не только тип ПО, инсталлированного в каждой системе, но и номер

версии обновлений.

Система ведения реестра ПО должна также просматривать сеть на наличие

неавторизованного ПО, установленного на каждой машине. Этим

неавторизованным ПО может быть и легальное ПО системного администрирования,

установленное в системе, где для него нет задач.

Активируйте технологию белого списка приложений, которая разрешает системам

запускать только разрешенное ПО и предотвращает выполнение других программ в

системе, основываясь на автоматически генерируемом списке действительного ПО

с эталонной машины. Инструменты ведения белых списков должны использовать

алгоритмы хеширования для определения авторизованных последовательностей

для исполнения системой.

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

с высоким риском, и которые не должны быть установлены в сетевой среде, должны

использоваться виртуальные машины и/или выделенные системы.

Клиентские рабочие станции должны конфигурироваться в виде непостоянной

виртуализированной операционной среды, которую периодически можно легко и

быстро восстанавливать из копии доверенной системы.

Взаимодействие между объектами системы:

Шаг 1: Активный сканер сканирует системы и ресурсы.

Шаг 2: Активный сканер передает отчеты в базу данных инвентаризации.

Шаг 3: База данных инвентаризации сравнивается с перечнем авторизованного ПО.

Шаг 4: База данных инвентаризации инициирует срабатывание системы

оповещения через систему SIEM.

Шаг 5: Система оповещения уведомляет специалистов службы безопасности

Шаг 6: Специалисты службы безопасности осуществляют мониторинг защищённой

базы данных инвентаризации.

Шаг 7: Специалисты службы безопасности при необходимости обновляют данные в

базе данных инвентаризации ПО.

Шаг 8: Инструмент, использующий технологию белого списка, непрерывно

контролирует все системы в сети.

11

Шаг 9: Инструмент, использующий технологию белого списка, осуществляет

проверку и вносит изменения в базу данных инвентаризации ПО.

CSC 3. Безопасная конфигурация программного и аппаратного обеспечения ноутбуков,

рабочих станций и серверов.

Реализация:

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

эталонный образ безопасности, который должен применяться при создании всех

новых систем, разворачиваемых на предприятии. Любая из существующих систем,

которая подверглась заражению, должна восстанавливаться из эталонного образа с

безопасными настройками конфигурации. Периодические обновления этого образа

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

Эталонные образы системы должны иметь документированные настройки

безопасности, протестированные перед развертыванием системы, утвержденные

Советом по контролю за изменениями в организации и зарегистрированные в

централизованной библиотеке эталонных образов организации. Эти образы

должны периодически обновляться и переутверждаться (например, каждые 6

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

векторами уязвимостей и атак.

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

основных операционных систем и приложений, устанавливаемых в сетях, которые

предлагаются, например, NIST, NSA, Defense Information Systems Agency (DISA),

Center for Internet Security (CIS) и др. Настройка обычно включает избавление от

ненужных учетных записей, блокирование или удаление ненужных сервисов и

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

функций операционной системы Предотвращение выполнения данных (Data

Execution Prevention (DEP). Кроме этого, безопасная конфигурация также включает

использование обновлений, закрытие открытых и неиспользуемых сетевых портов,

установку систем обнаружения и/или предотвращения вторжений и МСЭ уровня

хоста.

Любое отклонение от стандартной конфигурации или ее обновление должно

документироваться и утверждаться в системе управления изменениями.

Организации должны заключать контракты на покупку систем с безопасной

конфигурацией, не включенной в набор эталонных образов, разработанных без

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

уязвимость.

Эталонные образы должны храниться на безопасно сконфигурированных серверах

с инструментами проверки целостности и управления изменениями для

обеспечения возможности внесения только авторизованных изменений. Эталонные

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

с копированием образов через безопасную среду для загрузки их в

производственную сеть.

Необходимо использовать последние версии ПО с актуальными обновлениями.

Если это возможно, устаревшее ПО из системы должно удаляться.

12

Все удаленное администрирование серверов, рабочих станций, сетевых устройств и

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

Протоколы telnet, VNC, RDP и др., которые исходно не поддерживают надежного

шифрования, должны использоваться только при передаче во вторичном

шифрованном канале, например, TLS/SSL или IPSec.

Как минимум один раз в месяц запускайте инструмент контроля параметров

конфигурации на разной выборке систем, чтобы убедиться, что они

сконфигурированы в соответствии с руководствами по безопасной конфигурации.

Используйте инструменты проверки целостности файлов как минимум раз в

неделю, чтобы удостовериться, что критические системные файлы (включая

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

приложений) не были изменены. Обо всех изменениях в таких файлах должен

автоматически оповещаться персонал безопасности. Система передачи

информации об изменениях должна выявлять обычные и ожидаемые изменения,

выделяя необычные и непредвиденные события.

Разверните и протестируйте автоматическую систему мониторинга конфигурации,

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

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

совместимые со SCAP инструменты, для сбора информации об уязвимостях

конфигурации.

Эти автоматические тесты должны анализировать изменения как в аппаратной, так

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

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

Предоставляйте Руководству диаграммы с количеством систем, соответствующих

руководствам по конфигурации, и не соответствующих, отображая изменение таких

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

Взаимодействие между объектами системы:

Шаг 1: Безопасные образы систем применяются в компьютерных системах.

13

Шаг 2: Безопасные образы систем хранятся в безопасном режиме.

Шаг 3: Система управления конфигурацией проводит валидацию и проверку

образов систем.

Шаг 4: Система контроля конфигурации активно сканирует производственные

системы для обнаружения нарушений и отклонений от эталонных образов.

Шаг 5: Системы контроля целостности файлов осуществляет мониторинг

критических файлов системы и наборов данных.

Шаг 6: Инструмент, использующий технологию белого списка, осуществляет

контроль конфигураций систем и программного обеспечения.

Шаг 7: SCAP-сканер конфигураций проверяет конфигурации.

Шаг 8: Система контроля целостности файлов посылает уведомления об

отклонениях системе оповещения.

Шаг 9: Инструмент, использующий технологию белого списка, посылает

уведомления об отклонениях системе оповещения.

Шаг 10: SCAP-сканер конфигураций посылает уведомления об отклонениях системе

оповещения.

Шаг 11 и 12: В управленческих отчетах сообщается о статусе конфигурации.

CSC 4. Регулярное выявление и устранение уязвимостей.

Реализация:

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

всех системах не реже, чем 1 раз в неделю. По возможности, сканирование

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

сканера уязвимостей. Любая идентифицированная уязвимость должна быть

своевременно устранена, причем критические уязвимости должны устраняться в

течение 48 часов.

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

сканирования уязвимостей для достижения двух целей. Во-первых, персонал

должен проверять, что функционирование самих инструментов периодического

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

возможность связать события по обнаружению атаки с предшествующими

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

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

Необходимо установить автоматические средства управлениями обновлениями для

операционных систем и ПО третьих сторон во всех системах, для которых данные

инструменты доступны и безопасны.

Для преодоления недостатков неаутенцифицированного сканирования

уязвимостей, необходимо обеспечить сканирование уязвимостей в

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

системе для анализа конфигурации безопасности, или с удаленными сканерами,

которым предоставлены права администратора на тестируемую систему.

Необходимо сравнивать результаты следующих друг за другом сканирований для

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

компенсирующими мерами или документированием и обоснованным принятием

14

риска. Такое принятие риска для существующих уязвимостей должно периодически

пересматриваться для обнаружения новых компенсирующих мер или последующих

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

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

Инструменты сканирования уязвимостей должны быть настроены для сравнения

сервисов, установленных на каждой машине, со списком авторизованных сервисов.

Инструменты должны также быть настроены идентифицировать изменения во

времени в системах для авторизованных и неавторизованных сервисов.

Организации для проведения сканирования должны использовать официально

утвержденные файлы настроек сканирования для гарантии удовлетворения

минимальных требований стандартов.

Персонал безопасности должен составлять отчет в виде таблицы с указанием

количества актуальных критичных уязвимостей для каждого

отдела/подразделения.

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

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

устранения.

Необходимо измерять задержки при разработке обновлений для новых

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

в организации.

Критичные обновлений должны оцениваться в тестовой среде перед установкой в

системе предприятия. Если такие обновления нарушают критичные бизнес-

приложения на тестовых машинах, организациям следует рассмотреть другие

средства управления, которые блокируют компрометацию систем, на которых не

могут быть использованы такие обновления.

Взаимодействие между объектами системы:

Шаг 1: Сервис по исследованию уязвимостей предоставляет информацию для

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

Шаг 2: Сканеры уязвимостей сканируют производственные системы.

15

Шаг 3: Сканеры уязвимостей сообщают об обнаруженных уязвимостях системе

управления уязвимостями (СУУ).

Шаг 4: СУУ сравнивает производственные системы с эталонами конфигураций.

Шаг 5: СУУ посылает данные на вход SIEM.

Шаг 6: СУУ генерирует отчеты для руководства.

Шаг 7: Система управления обновлениями применяет обновления программного

обеспечения к производственным системам.

CSC 20. Проведение тестирования на проникновение и учений.

Реализация:

Следует проводить регулярные внешние и внутренние тесты на проникновение для

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

успешной эксплуатации систем предприятия. Тестирование на проникновение

должно происходить из-за периметра сети (например, Интернет или зон с

беспроводными сетями вокруг организации), а также внутри ее границ (например,

из внутренней сети) для моделирования как внешних, так и внутренних атак.

Следует проводить периодические учения для тестирования готовности

организации к обнаружению и остановке атак или быстрому и эффективному

реагированию.

Следует обеспечить полное устранение системных ошибок, выявленных в ходе

тестирования на проникновение и учений.

Следует оценить, насколько удалось снизить существенные возможности для

нарушителей, запуская автоматические процессы для поиска:

o незашифрованных электронных писем и документов с «паролем» в имени

или теле файла;

o схем критичных сетей, хранящиеся online и в незашифрованном виде;

o критичных файлов конфигураций, хранящиеся online и в незашифрованном

виде;

o документов с оценкой уязвимостей, отчетами о тестировании на

проникновение и результатами учений, хранящихся online и в

незашифрованном виде;

o другой конфиденциальной информации, идентифицированной

управляющим персоналом как критичная для работы предприятия, в ходе

тестирования на проникновение или учений.

В тестирование на проникновение следует включать социальный инжиниринг.

Человеческий фактор – слабое звено в организации и зачастую выбирается

нарушителями в качестве цели.

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

результаты во времени.

Следует создать тестовую лабораторию, имитирующий производственную среду

для отдельных тестов на проникновение и атак при учениях против элементов,

обычно не тестируемых при производстве, таких как атаки против диспетчерского

управления и сбора данных и других управляющих систем.

Взаимодействие между объектами системы:

16

Шаг 1: Специалисты по проведению тестирования на проникновение (пентестеры)

выполняют тесты на проникновение в производственные системы.

Шаг 2: Автоматизированные инструменты для тестирования на проникновения

выполняют тесты на проникновение в производственные системы.

Шаг 3: Автоматизированные инструменты для тестирования на проникновения

сообщают пентестеру об обнаруженных уязвимостях.

Шаг 4: Пентестеры проводят более обширные тесты на проникновение в тестовых

лабораториях.

Шаг 5: Аудиторы оценивают и инспектируют работы, выполненные

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

Шаг 6: Аудиторы оценивают и инспектируют работы, выполненные пентестерами.

Шаг 7: Пентестеры генерируют отчеты и статистические данные об уязвимостях,

которые были обнаружены.

2.3. ISO/IEC 27001:2013 «Информационные технологии. Методы защиты. Системы

менеджмента информационной безопасности. Требования»2.

ISO/IEC 27001:2013 «Информационные технологии. Методы

защиты. Системы менеджмента информационной безопасности.

Требования»

ПРИЛОЖЕНИЕ А

A.8.1.1 Инвентаризация активов A.12.6.1 Контроль технических уязвимостей A.14.2.8 Тестирование защищенности системы A.18.2.1 Независимый анализ информационной безопасности A.18.2.3 Анализ технического соответствия

A.8.1.1. Инвентаризация активов.

Информация, другие активы, связанные с информацией и устройствами обработки

информации, должны быть выявлены и составлен реестр этих активов, который

должен поддерживаться в актуальном состоянии.

Организация должна выявить активы, поддерживающие жизненный цикл

информации, и документально зафиксировать их значимость. Жизненный цикл

2www.pqm-online.com, для ознакомления: ISO/IEC 27001:2013 http://www.pqm-online.com/assets/files/pubs/translations/std/iso-mek-27001-2013(rus).pdf ISO/IEC 27002:2013 http://pqm-online.com/assets/files/pubs/translations/std/iso-mek-27002-2013.pdf. Официальные издания можно приобрести по адресу https://shop.belgiss.by.

17

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

стирание и уничтожение.

Документация соответствующим образом должна быть зафиксирована в

специально созданных или уже существующих реестрах.

Реестр активов должен быть точным, актуальным, полным и соответствующим

другим реестрам.

Для каждого выявленного актива должен быть назначен владелец и проведена

классификация.

A.12.6.1. Контроль технических уязвимостей.

Должна своевременно получаться информация о технических уязвимостях в

используемых информационных системах, должно оцениваться влияние этих

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

связанных с этих рисков.

Ведение актуального и полного учета активов – это необходимое условие для

результативного управления техническими уязвимостями. Информация,

необходимая для поддержки управления техническими уязвимостями, включает в

себя наименование поставщика программного обеспечения, номер версии,

текущее состояние (например, какое программное обеспечение установлено на

какой системе) и лиц, ответственных в организации за это программное

обеспечение.

Должны предприниматься соответствующие и своевременные действия в случае

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

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

техническими уязвимостями:

o организация должна определить и установить должности и обязанности,

связанные с управлением техническими уязвимостями, включая мониторинг,

оценку рисков, исправление, отслеживание активов и любые необходимые

обязанности по координации;

o для программного обеспечения и других технических систем (включенных в

реестр активов) должны быть определены информационные ресурсы,

которые будут использованы для выявления существенных технических

уязвимостей и поддержки осведомленности о них; эти информационные

ресурсы должны обновляться в соответствии с изменениями в реестре или,

когда обнаруживаются другие новые или полезные ресурсы;

o должен быть определен срок реагирования на уведомление о возможных

существенных технических уязвимостях;

o как только выявлена техническая уязвимость, организация должна

определить связанные с ней риски и необходимые действия; такого рода

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

системе или применение иных мер;

o в зависимости от срочности устранения технической уязвимости, действия

должны предприниматься или в соответствии с процедурами управления

изменениями, либо в соответствии с процедурами обработки инцидентов

информационной безопасности;

18

o если патч доступен на легальном источнике, то должны быть оценены риски,

связанные с установкой патча (риски, вызываемые уязвимостью,

необходимо сравнить с рисками установки патча);

o патчи должны быть протестированы и оценены до их установки для гарантии

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

эффектам; если нет доступного патча, необходимо рассмотреть возможность

применения иных мер, таких как:

прекращение пользование сервисами и инструментами, связанными

с уязвимостями;

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

брандмауэров, на стыке сетей;

ужесточение мониторинга для выявления реальных атак;

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

o для всех предпринятых действий должны сохраняться контрольные

журналы;

o процесс управления техническими уязвимостями должен регулярно

контролироваться и оцениваться с тем, чтобы гарантировать его

результативность и эффективность;

o системы с высоким уровнем риска должны рассматриваться в первую

очередь;

o результативный процесс управления техническими уязвимостями должен

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

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

обеспечивать техническими процедурами, которые должны быть

выполнены, если произойдет инцидент;

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

но нет соответствующих контрмер. В такой ситуации организации должна

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

соответствующие действия по обнаружению и корректирующие действия.

A.14.2.8. Тестирование защищенности системы.

В ходе разработки должно выполняться тестирование функциональности,

связанной с безопасностью.

Новые и обновляемые системы требуют тщательного тестирования и проверки в

ходе процессов разработки, включая подготовку детального графика работ,

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

результатов. При разработке собственными силами такие тесты должны

первоначально выполняться командой разработки. Затем должно выполняться

независимое приемочное тестирование (как для разработки собственными силами,

так и для переданной на сторону), чтобы гарантировать, что система работает как

ожидалось и только как ожидалось. Объем тестирования должен соответствовать

важности и характеру системы.

A.18.2.1. Независимый анализ информационной безопасности.

Подход организации к управлению информационной безопасностью и его

реализация (т. е. задачи управления, средства управления, политики, процессы и

19

процедуры по обеспечению информационной безопасности) должны подвергаться

независимому анализу через запланированные интервалы времени или в тех

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

Руководство должно инициировать проведение независимого анализа. Такого рода

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

адекватность и результативность подхода организации к управлению

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

возможностей для улучшения и необходимости изменений в подходе к

безопасности, в том числе политике и задачах управления.

Такой анализ должен проводиться людьми, не связанными с анализируемой

областью, например, теми, кто проводит внутренние аудиты, руководителями

других направлений или внешней организацией, специализирующейся на

подобного рода оценках. Те, кто проводит такие проверки, должен обладать

соответствующими навыками и опытом.

Результаты независимого анализа должны быть зафиксированы и переданы

руководству, инициировавшему анализ. Эти записи должны сохраняться.

Если независимый анализ выявляет неадекватность подхода к управлению

информационной безопасностью и его реализации в организации, например,

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

положениями, сформулированными в политиках информационной безопасности,

руководство должно рассмотреть необходимость корректирующих действий.

A.18.2.3. Анализ технического соответствия.

Информационные системы должны регулярно анализироваться на соответствие

политикам и стандартам информационной безопасности организации.

Техническое соответствие должно анализироваться преимущественно с помощью

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

их интерпретации техническим специалистом. Кроме этого, анализ может

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

если необходимо) опытным системным инженером.

Если применяются тесты на проникновение или оценки уязвимостей, то

необходимо делать предупреждение, так как такая активность может вести к

нарушению безопасности системы.

Такие тесты должны планироваться, документироваться и повторяться.

Любой анализ технического соответствия должен выполняться только

компетентными и авторизованными лицами или под управлением таких лиц.

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

гарантировать, что средства управления оборудованием и программным

обеспечением осуществляются надлежащим образом. Данный тип анализа

соответствия требует специалиста по технической экспертизе.

Анализ соответствия также включает в себя, например, тест на проникновение и

оценку уязвимостей, которые могут выполняться независимыми экспертами,

приглашенными для этих целей. Это может быть полезным при определении

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

20

управления в предупреждении неавторизованного доступа с использованием этих

уязвимостей.

Тест на проникновение и оценка уязвимостей дает мгновенный снимок системы в

конкретном состоянии на конкретный момент времени. Это представление

ограничено той частью системы, которая подвергалась тестированию при попытках

проникновения. Тест на проникновение и оценка уязвимостей не заменяют собой

оценки рисков.

2.4. Payment Card Industry Data Security Standard (PCI DSS)3.

Payment Card Industry Data Security Standard (PCI DSS)

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters (2.2, 2.4).

Requirement 6: Develop and maintain secure systems and applications (6.1, 6.2). Requirement 11: Regularly test security systems and processes (11.2, 11.3, 11.5).

Требование 2. Не использовать пароли и другие системные параметры, заданные

производителем по умолчанию.

2.2 Должны быть разработаны стандарты конфигурации для всех системных

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

а также положения общепринятых отраслевых стандартов в области безопасности.

Примеры источников общепринятых отраслевых стандартов в области безопасности

включают, но не ограничиваются:

o Центр Интернет-безопасности (CIS);

o Международная организация по стандартизации (ISO);

o Институт системного администрирования, аудита, сетевых технологий и

проблем безопасности (SANS);

o Национальный институт стандартов и технологий.

2.4 Вести учет системных компонентов, на которые распространяется действие

стандарта PCI DSS.

Требование 6. Разрабатывать и поддерживать безопасные системы и приложения.

6.1 Должен быть внедрен процесс выявления уязвимостей с помощью авторитетных

внешних источников информации об уязвимостях, а также ранжирования риска

(например, «высокий», «средний» или «низкий») недавно обнаруженных

уязвимостей.

6.2 Все системные компоненты и программное обеспечение должны быть

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

системы безопасности, выпущенных поставщиком. Критичные обновления

безопасности должны быть установлены в течение месяца с момента их выпуска

производителем.

3Для ознакомления, по материалам http://ru.pcisecuritystandards.org/_onelink_/pcisecurity/en2ru/minisite/en/docs/PCI_DSS_v3.pdf. Актуальную версию стандарта можно скачать по адресу https://www.pcisecuritystandards.org/document_library.

21

Требование 11. Регулярно выполнять тестирование систем и процессов обеспечения

безопасности.

11.2 Следует проводить внешнее и внутреннее сканирование сети на наличие

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

изменений (например, установки новых системных компонентов, изменения

топологии сети, изменения правил межсетевых экранов, обновления продуктов).

11.3 Внедрить методологию проведения тестирования на проникновение, которая:

• основана на общепринятых отраслевых подходах к проведению

тестирования на проникновение (например, NIST SP800-115);

• охватывает весь периметр информационной среды держателей карт и

критичные системы;

• включает тестирование как снаружи сети, так и внутри сети;

• включает тестирование на наличие механизмов сегментации и уменьшения

охвата;

• требует, чтобы тесты на проникновение на уровне приложения включали, как

минимум, проверку на наличие уязвимостей, приведенных в требовании 6.5;

• требует, чтобы тесты на проникновение на уровне сети охватывали не только

операционные системы, но и другие компоненты, поддерживающие

взаимодействие на сетевом уровне;

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

месяцев;

• регламентирует хранение результатов тестов на проникновение и мер,

предпринятых для устранения уязвимостей.

11.5 Следует внедрить механизм защиты от изменений (например, мониторинг

целостности файлов) для оповещения персонала о несанкционированных

изменениях критичных системных файлов, конфигурационных файлов и файлов

данных; сопоставительный анализ критичных файлов должен проводиться не реже

одного раза в неделю.

3. ОСОБЕННОСТИ ИСПОЛЬЗОВАНИЯ СРЕДСТВ КОНТРОЛЯ ЗАЩИЩЕННОСТИ (НПА

РБ)

3.1. Положение о технической и криптографической защите информации в

Республике Беларусь, утверждено Указом Президента Республики Беларусь

16.04.2013 № 1964.

15. При осуществлении технической защиты информации5 используются средства

технической защиты информации, имеющие сертификат соответствия, выданный в

Национальной системе подтверждения соответствия Республики Беларусь, или

4 http://oac.gov.by/files/files/pravo/ukazi/Ukaz_196.htm. 5 техническая защита информации – деятельность, направленная на обеспечение конфиденциальности, целостности, доступности и сохранности информации техническими мерами без применения средств криптографической защиты информации.

22

положительное экспертное заключение по результатам государственной

экспертизы, проводимой ОАЦ.

3.2. Закон Республики Беларусь от 10 ноября 2008 г. № 455-З «Об информации,

информатизации и защите информации»6.

Статья 28. Основные требования по защите информации. Для создания системы

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

защиты информации, имеющие сертификат соответствия, выданный в

Национальной системе подтверждения соответствия Республики Беларусь, или

положительное экспертное заключение по результатам государственной

экспертизы, порядок проведения которой определяется Оперативно-

аналитическим центром при Президенте Республики Беларусь.

3.3. Технический регламент Республики Беларусь «Информационные технологии.

Средства защиты информации. Информационная безопасность» (ТР 2013/027/BY)7.

2. Перед выпуском в обращение8 на рынке средства защиты информации9 должны

быть подвергнуты процедуре подтверждения соответствия требованиям

информационной безопасности настоящего технического регламента в форме

сертификации или декларирования соответствия.

3. Подтверждению соответствия требованиям информационной безопасности

настоящего технического регламента путем сертификации подлежат средства

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

o технической защиты государственных секретов;

o создания систем защиты информации информационных систем,

предназначенных для обработки информации, распространение и (или)

предоставление которой ограничено;

o создания систем безопасности критически важных объектов

информатизации;

o обеспечения целостности и подлинности электронных документов в

государственных информационных системах.

Требования информационной безопасности настоящего технического регламента,

на соответствие которым осуществляется сертификация, определяются Оперативно-

аналитическим центром при Президенте Республики Беларусь в зависимости от

специфики средств защиты информации.

6 http://oac.gov.by/files/files/pravo/zakoni/zakon_455-%D0%97.htm. 7 http://oac.gov.by/files/files/pravo/post/Post_SM_375.htm. 8 обращение средств защиты информации на рынке – движение средств защиты информации от изготовителя к потребителю (пользователю), охватывающее все процессы, которые проходят средства защиты информации после завершения их производства. 9 средства защиты информации – технические, программные, программно-аппаратные средства, предназначенные для защиты информации, а также средства контроля эффективности ее защищенности.

23

3.4. Положение о порядке технической защиты информации в информационных

системах, предназначенных для обработки информации, распространение и (или)

предоставление которой ограничено, не отнесенной к государственным секретам,

утверждено приказом Оперативно-аналитического центра при Президенте

Республики Беларусь 30.08.2013 № 6210.

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

технической защиты информации, имеющие сертификат соответствия, выданный в

Национальной системе подтверждения соответствия Республики Беларусь, или

положительное экспертное заключение по результатам государственной

экспертизы, проводимой Оперативно-аналитическим центром при Президенте

Республики Беларусь (далее – ОАЦ).

4. РАЗРАБОТКА ПРОГРАММЫ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ11

4.1. Процесс управления уязвимостями и обновлениями В этом разделе рассматривается системный подход к управлению обнаружением и

устранением уязвимостей (далее по тексту - управление уязвимостями). Подход

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

Необходимо экономически эффективно реагировать на постоянно растущее число

уязвимостей в ИТ-систем.

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

NIST рекомендует организациям создать группу управления уязвимостями (patch and

vulnerability group, PVG), которая будет реализовать программу управления уязвимостями.

Поскольку PVG должна активно работать с администраторами систем, для крупных

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

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

Организация должна стремиться передать (в максимально возможном объеме) от

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

исправлений уязвимостей. Это позволит сэкономить ресурсы за счет устранения

дублирования обязанностей (например, несколько системных администраторов тестируют

одни и те же обновления для одинаковых систем) и, использования автоматизированных

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

достижения этой цели - внедрение корпоративных решений по управлению

обновлениями, которые позволяют PVG, автоматически устанавливать патчи на большом

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

доступны, PVG должна координировать усилия администраторов.

Чтобы PVG имела возможность тестировать автоматически развернутые патчи,

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

устройств (например, такие как, настольные компьютеры, маршрутизаторы, межсетевые

10 http://oac.gov.by/files/files/pravo/prikazi_oac/Prikaz_OAC_3.htm. 11 NIST Special Publication 800-40 Version 2.0. Creating a Patch and Vulnerability Management Program http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf. NIST Special Publication 800-40 Revision 3 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf.

24

экраны, серверы). При отсутствии стандартных конфигураций, инструменты управления

обновлениями будут неэффективны.

Чтобы сделать деятельность PVG экономически-эффективной, сфера ответственности PVG

должна быть четко определена. PVG должна осуществлять управление уязвимостями ИТ,

которые широко используются в организации.

Для остальных технологий и активов PVG будет оказывать помощь в обучении

администраторов управлению уязвимостями. Оставшаяся часть этого раздела содержит

подробную информацию о ролях и сферах ответственности PVG и системных

администраторов.

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

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

информационной безопасности и информационных технологий. В состав группы

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

уязвимостями и обновлениями, системного администрирования, управления

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

составе группы иметь специалистов по операционным системам и приложениям, наиболее

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

администрированию сетей и систем, сканированию уязвимостей, администрированию

системы обнаружения вторжений - являются вероятными кандидатами в PVG.

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

будет варьироваться в различных организациях. Многое зависит от размера и сложности

организации/сети, и бюджета. PVG небольших организаций может состоять из одного или

двух человек, и деятельность такой группы будет сосредоточена только на критических

уязвимостях и системах. Независимо от размера организации или ресурсов, цели

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

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

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

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

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

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

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

организации.

Общее тестирование исправлений и обновлений.

Распространение информации об уязвимостях и исправлениях локальным

администраторам.

Автоматизированная установка патчей.

Настройка автоматических обновлений (в случае если это возможно).

Верификация устранения уязвимостей, при помощи сканирования сетей и систем.

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

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

25

Системные администраторы несут ответственность за соответствие конфигурации ИТ-

ресурсов стандартам организации, и за участие этих ресурсов в автоматизированном

управлении обновлениями. Если организация не использует автоматизированную систему

установки обновлений, системные администраторы должны использовать PVG в качестве

основного источника информации по устранению уязвимостей, и устранять уязвимости в

согласованные сроки. Администраторы, несут ответственность за мониторинг и устранение

уязвимостей, тестирование исправлений и обновлений, для тех ИТ-ресурсов, которые не

попадают в область действия PVG.

4.1.2. Создание реестра активов.

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

инвентаризации ИТ-ресурсов, для определения, какие аппаратные средства,

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

приоритезацию этих ресурсов. PVG следует вести вручную реестр ИТ-ресурсов, не

зафиксированных в существующих системах инвентаризации. Имея в наличии реестр

активов с определенными для них приоритетами, PVG должна определить, какие

аппаратные и программные средства будут участвовать в процессе управления

уязвимостями.

Реестр ИТ

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

включить в их реестр (не все характеристики будут применяться ко всем ИТ-ресурсам):

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

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

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

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

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

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

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

Наименование и номер версии операционной системы.

Установленное программное ПО с номерами версий.

Используемые службы (сервисы).

IP-адрес (если статический).

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

Центральный процессор

Память

Дисковое пространство

MAC адрес

Поддержка беспроводных сетей

Посты ввода/вывода (например, USB, Firewire)

26

Версия прошивки

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

Ресурсы, входящие в реестр активов, должны быть сгруппированы. Также для активов

необходимо определить уровень приоритета. Группировка и приоритезация активов

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

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

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

местоположения в сети. Это особенно важно для тех ресурсов, которые непосредственно

подключены к сети Интернет.

NIST Special Publication 800-1812

Руководство по группировке ИТ-ресурсов аккредитованных систем представлено в NIST SP

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

показателей:

Элементы находятся под одним управлением/контролем.

Элементы выполняют одинаковые функции, или миссии/цели.

Элементы имеют схожие эксплуатационные характеристики безопасности, и

потребности в защите.

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

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

Часто необходимо определить приоритеты в границах самой системы. В PVG должен

документально определить, какие ИТ ресурсы имеют более высокий приоритет внутри

системы. Обычно высокий уровень приоритета присваивается ресурсам, которые попадают

в одну (и более) категорию:

Ресурсы, необходимые для функционирования системы (например, серверы).

Ресурсы, используемые для управления безопасностью.

Ресурсы, расположенные на границе сети организации.

Ресурсы, которые содержат особо важную информацию.

Ресурсы, которые доступны для внешних пользователей.

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

PVG будет осуществлять свою деятельность, на основании инвентаря ресурсов. Реестр

может использоваться в первую очередь для создания списка поддерживаемых PVG:

оборудования, операционных систем и приложений. Это поможет PVG и администраторам

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

администраторов, чтобы помочь им защитить свои системы.

12 NIST Special Publication 800-18 Revision 1 «Guide for Developing Security Plans for Federal Information Systems» http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-18r1.pdf

27

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

PVG отвечает за мониторинг источников информации об уязвимостях, обновлениях, патчах,

обходных путях, и угрозах, которые применимы к входящим в реестр активов ОС и ПО.

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

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

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

уязвимостях и исправлениях. Приложение D содержит перечень ресурсов. Каждый тип

источника информации имеет свои сильные и слабые стороны. NIST рекомендует

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

типами являются:

Веб-сайты и рассылки поставщиков

Веб-сайты третьих сторон

Сторонние рассылки и группы новостей

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

Базы данных уязвимостей

Инструменты управления обновлениями уровня предприятия

Другие инструменты уведомления.

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

Инструменты управления обновлениями, чтобы получить все доступные патчи от

поддерживаемых поставщиков.

Списки рассылки и веб-сайты производителей, чтобы получить все доступные патчи,

для приложений, не поддерживаемых автоматизированной системой управления

обновлениями организации.

Базы данных уязвимостей или списки рассылки для получения оперативной

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

(например, National Vulnerability Database).

Списки рассылки от третьих сторон, которые подчеркивают самые критические

уязвимости (например, US-CERT Cyber Security Alerts). Такие списки помогут

сосредоточиться на наиболее важных уязвимостях.

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

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

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

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

Определить существование, и распространенность эксплойтов, вредоносного по и

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

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

обходного пути для устранения уязвимости.

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

PVG должна создать базу данных исправлений, которые должны быть применены в рамках

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

28

но PVG может потребоваться вручную поддерживать отдельный перечень ИТ-технологий,

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

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

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

патчи, также они должны содержать копию каждого патча для ситуаций, когда Интернет

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

вручную может быть возможным, NIST настоятельно рекомендует покупать

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

данных.

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

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

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

Большинство производителей предоставляют некоторые механизмы

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

Проводите проверку исправлений на наличие вирусов.

Проверяйте патчи и исправления на непроизводственных (тестовых) системах.

Установка одного патча может непреднамеренно удалить или отключить другой

патч.

Тестирование следует проводить на системах, которые точно повторяют

конфигурацию целевых систем.

Если позволяет время, PVG может изучить опыт по установке таких обновлений

другими организациями.

В случае обнаружение проблем, связанных с установкой патчей, PVG должна

оценить риски, связанные с установкой (или не установкой) патча.

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

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

данная уязвимость. Существует три основных метода устранения уязвимостей в системе:

установка обновления (патча),

изменение конфигурации,

удаление уязвимого ПО.

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

Основной способ, которым PVG будет распространять патчи – специальное ПО для

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

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

уменьшить вероятность подделки, PVG должна распространять патчи защищенным

способом (например, при помощи специальных автоматизированных инструментов).

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

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

быть достигнуто несколькими способами:

Проверкой, что файлы или параметры конфигурации, связанные с исправлением,

были изменены, как указано в документации поставщика.

29

Сканированием хоста с помощью сканера уязвимостей.

Проведением анализа журналов патчей (например, в автоматизированной системе

управления обновлениями).

Попыткой эксплуатации уязвимости.

4.1.10. Проведение обучения по устранению уязвимостей.

В то время как PVG будет следить за уязвимостями в системах, попадающих в область

действия PVG, локальные администраторы должны следить за ПО, которое не попадает в

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

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

распространенных в организации системах и ПО. В этой ситуации, очень важно, чтобы

локальные администраторы получали необходимую информацию по управлению

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

ресурсов для поиска информации по уязвимостям и исправлениям.

Кроме того, все конечные пользователи (это относится к удаленным работникам

организации), должны быть осведомлены о процессе управления уязвимостями

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

по установке патчей и принятию других мер по устранению уязвимостей.

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

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

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

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

обновлениями:

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

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

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

исправлений.

4. В соответствии с приоритетностью систем осуществлять поэтапную установку

обновлений (по мере необходимости).

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

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

управлять установкой обновлений.

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

обновлениями).

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

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

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

30

4.2. Метрики процесса управления уязвимостями и обновлениями. В этом разделе рассказывается, как разработать и внедрить метрики для оценки

программы управления уязвимостями. NIST SP 800-5513, является основой подхода,

описанного настоящем разделе.

Каждая организация должна последовательно измерять эффективность своей программы

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

необходимости. Это может быть сделано путем разработки метрик. Организации должны

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

показателей. Реальные целевые показатели должны быть доведены до владельцев систем

и сотрудников служб безопасности.

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

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

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

без использования агента,

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

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

инвентаризации ПО,

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

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

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

Установка обновлений может привести к неожиданным проблемам с существующим программным обеспечением.

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

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

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

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

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

13 NIST Special Publication 800-55 Revision 1 «Performance Measurement Guide for Information Security» http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-55r1.pdf.

31

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

Выбирать более зрелый и менее сложный (комплексный) продукт.

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

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

Используйте только поддерживаемые разработчиком версии ПО.

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

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

Тип оборудования и модель.

Версия операционной системы и уровень обновлений.

Основные установленные приложения (Версия и уровень обновлений).

Параметры безопасности для операционной системы и приложений.

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

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

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

14 NIST Special Publication 800-70 Revision 2 «National Checklist Program for IT Products—Guidelines for Checklist Users and Developers» http://csrc.nist.gov/publications/nistpubs/800-70-rev2/SP800-70-rev2.pdf. NIST Special Publication 800-70 Revision 3 (Draft) «National Checklist Program for IT Products—Guidelines for Checklist Users and Developers (Draft)» http://csrc.nist.gov/publications/drafts/800-70/sp800-70r3_draft.pdf. 15 NIST Special Publication 800-61 Revision 2 «Computer Security Incident Handling Guide» http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

32

4.4. Ресурсы с информацией по управлению уязвимостями:

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/

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

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

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

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

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

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

1. Создать группу управления уязвимостями. 2. Осуществлять непрерывный мониторинг угроз, уязвимостей и исправлений. 3. В соответствии с приоритетностью систем осуществлять поэтапную установку

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

управлять установкой обновлений. 6. Использовать автоматическое обновление приложений (по мере необходимости). 7. Создать реестр всех ИТ-ресурсов. 8. Где возможно, использовать стандартные конфигурации для ИТ-ресурсов. 9. Проверять устранение уязвимостей. 10. Измерять эффективность программы управления уязвимостями организации, и

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

5. OPEN-SOURCE ИНСТРУМЕНТЫ.

5.1. Nmap / Zenmap. Nmap (http://nmap.org/) - утилита, предназначенная для сканирования IP-сетей,

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

Справочное руководство Nmap (Man Page) https://nmap.org/man/ru/index.html

33

5.2. OpenVAS. OpenVAS (http://www.openvas.org/) – приложение, предназначенное для проведения

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

Документация: http://www.openvas.org/documentation.html

Русскоязычное сообщество пользователей OpenVAS: http://openvas.ru/

5.3. Metasploit Framework / Armitage. Metasploit Framework (http://www.metasploit.com/) - платформа для эксплуатации

уязвимостей, создания, отладки и использования эксплойтов. Armitage – графический

интерфейс.

Бесплатный обучающий курс по Metasploit Framework: https://www.offensive-

security.com/metasploit-unleashed/

34

5.4. w3af w3af (http://w3af.org/) - платформа для тестирования безопасности веб-приложений.

Документация на w3af:

http://docs.w3af.org/en/latest/

https://media.readthedocs.org/pdf/w3af/latest/w3af.pdf

5.5. Hydra Hydra (http://freeworld.thc.org/thc-hydra/) – инструмент, предназначенный для удаленного

(по сети) подбора паролей.

35

6. ОБЩЕДОСТУПНЫЕ ИСТОЧНИКИ ИНФОРМАЦИИ ОБ УЯЗВИМОСТЯХ Банк данных угроз безопасности информации. Уязвимости (ФСТЭК РФ)

http://www.bdu.fstec.ru/vul

Open Source Vulnerability Database (OSVDB) - http://osvdb.org/

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

Common Vulnerabilities and Exposures (CVE) - http://www.cvedetails.com/

Common Weakness Enumeration (CWE) - http://cwe.mitre.org/

CWE/SANS TOP 25 Most Dangerous Software Errors - http://www.sans.org/top25-

software-errors/

OWASP Top Ten Project - https://www.owasp.org/index.php/Top_10_2013-Top_10

National Vulnerability Database http://nvd.nist.gov/

Exploit-Database http://www.exploit-db.com/

Securitytracker http://www.securitytracker.com/

Securiteam http://www.securiteam.com/

SecurityFocus http://www.securityfocus.com/

Security Magazine http://www.securitymagazine.com/

SC Magazine http://www.scmagazine.com/

SANS Newsletters http://www.sans.org/newsletters/newsbites/

https://www.us-cert.gov/ncas/current-activity

http://www.reddit.com/r/netsec

http://cert.europa.eu/cert/filteredition/en/CERT-LatestNews.html

http://www.rootsecure.net/?p=secnews_rss_feeds

https://twitter.com/search?q=%23dfir&src=typd #DFIR

https://twitter.com/search?q=%23infosec&src=typd&f=realtime #INFOSEC

36

7. КУРСЫ ОБУЧЕНИЯ

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

ближайшее время будут представлены на http://itsec.by/ и http://edu.softline.by/.

В курсе рассматриваются основные подходы к проведению тестирования на

проникновения и оценки защищенности информационных систем: OSSTMM, ISSAF, OWASP,

EC-Council. В рамках курса основное внимание уделяется практическим занятиям по

проведению последовательного теста на проникновение начиная от сбора информации о

целевой системе, и заканчивая эксплуатацией и разработкой отчета по результатам теста.

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

открытым исходным кодом: Netcat, Nmap, OpenVAS, Metasploit Framework, Hydra, w3af.

ПРОГРАММА КУРСА:

1. Требования законодательства об информации, информатизации и защите информации.

2. Методики тестирования на проникновение и оценки защищенности. 3. Классификация, виды и сценарии атак целевой системы. 4. Алгоритм проведения тестирования на проникновение и оценки защищенности. 5. Установка, настройка дистрибутива Kali Linux, и работа с базовыми инструментами. 6. Сбор информации о целевой системе. 7. Обнаружение/исследование. Netcat, Nmap (практикум). 8. Анализ уязвимостей. Nmap, OpenVAS, Nessus (практикум). 9. Эксплуатация уязвимостей. Metasploit Framework, Armitage (практикум). 10. Аудит паролей. Hydra (практикум). 11. Оценка защищенности и тестирование на проникновение веб-приложений. 12. Проведение оценки защищенности и тестирование на проникновение учебной

целевой системы (итоговая лабораторная работа).

7.2. CIS Critical Security Controls. Аудит и внедрение. Информация о дате, месте проведения курса и подробная программа курса в

ближайшее время будут представлены на http://itsec.by/ и http://edu.softline.by/.

В курсе рассматриваются практические аспекты внедрения средств и систем защиты

информации в соответствии с современным международным подходом CIS Critical Security

Controls. CIS Critical Security Controls – подход к обеспечению информационной

безопасности организации, который содержит практические рекомендации по

предотвращению несанкционированного доступа к ее сетям и системам, а также

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

информационной безопасностью организации и вопросы разработки и внедрения системы

менеджмента информационной безопасности (СМИБ) в соответствии со стандартами

ISO/IEC.

ПРОГРАММА КУРСА:

Правовое обеспечение информационной безопасности.

37

Принципы построения комплексной системы информационной безопасности

организации.

Внедрение процессов (функций) управления информационной безопасностью.

Аудит и внедрение CIS Critical Security Controls:

Инвентаризация авторизованного и неавторизованного оборудования;

Инвентаризация авторизованного и неавторизованного программного

обеспечения;

Безопасная конфигурация программного и аппаратного обеспечения

ноутбуков, рабочих станций и серверов;

Безопасная конфигурация сетевого оборудования (межсетевые экраны,

маршрутизаторы, коммутаторы);

Ограничение и контроль сетевых протоколов, портов и служб;

Контроль и защита беспроводных устройств;

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

Защита от вредоносного кода;

Безопасность прикладного ПО;

Возможность восстановления данных;

Ведение, мониторинг и анализ журналов регистрации событий

безопасности;

Оценка навыков по безопасности и проведение тренингов для

подтверждения эффективности;

Возможность реагирования на инциденты информационной безопасности;

Тестирование на проникновение, упражнения и учения;

Контроль использования административных привилегий;

Контроль доступа на основе минимально необходимых прав (принцип

«необходимо знать»);

Мониторинг и контроль учетных записей;

Предотвращение утечки данных;

Защита периметра;

Архитектура безопасности сети.