Новая версия модуля управления конфигурациями ИБ для iTop

Существенно обновил свой модуль Security Object Management для iTop https://bitbucket.org/esguardian/itop-extensions/overview.

Кроме доделки управления ролями (добавлены шаблоны ролей), сделал систему управления чек-листами. Получилась очень удобная система консолидации требований различных стандартов ИБ и просто своих собственных правил, и отражения их в существующей системе управления конфигурациями. Подробно описывать не хочу. Это лучше попробовать. Коротко приведу выдержку readme. Разумеется это всё бесплатно и Open Source. И я принимаю пожелания от коллег.

Использование чек-листов

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

Зачем это нужно

Если вы когда-нибудь сталкивались с проверками соответствия стандарту PCI DSS или требованиям положения 382-П Банка России, вы уже догадались.
Да. Вот для этого и нужно. Система управления чек-листами позволяет собрать поэлементно в единый список требования какого-либо стандарта и привязать эти требования к различным элементам конфигурации вашей системы: серверам, сетевым устройствам, прикладным решениям, бизнес-процессам и т.п. И затем контролировать их выполнение.

Структура данных

  • Чек-лист.

Это контейнер в котором собираются правила в виде элементов чек-листа. Он поддерживает добавление и удаление правил и некоторую сводную сортировку, а именно показывает списки правил трех видов: неназначенные ни кому, имеющие статус «не выполнено» хотябы в одной проверке, полностью выполненные во всех проверках.

  • Правило.

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

  • Область (scope).

Это область применения правила. Для орг. меры — это список организаций. Для тех. меры — это список групп КЕ (Конфигурационная Единица — это такой русский перевод термина Configuration Item CMDB).

  • Проверка.

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

  • Эквивалент.

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

Логика работы

  • Создайте чек-лист.

Назовите его в соответствии стандарту, например, 382-П или PCI DSS. Система поддерживает определенную иерархию имен. Имя чек-листа всегда будет префиксом имени правила в чек-листе.

  • Добавьте правила в чек-лист.

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

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

Будет лучше если вы создадите группы для разных типов КЕ, например, для гипервизоров, маршрутизаторов, виртуальных сетей, веб-серверов. Не обязательно сразу продумывать структуру групп. Их можно менять. Вместе с автоматическим созднием элементов проверки для всех КЕ включенных в группу, поддерживается и автоматическое удаление этих элементов при исключении КЕ из группы или исключении группы из области действия правила.

  • Назначте правилам области действия.

Элементы проверки создадутся автоматически. Статус новых элементов будет установлен в «Не выполнено» если только к данному КЕ не существует элемента проверки, соответсвующего эквивалентному правилу и имеющего статус «Выполнено». Вот зачем нужны эквиваленты. А еще они меняют статус всех существующих эквивалентных элементов проверки связанных с данным КЕ, если изменяется статус одного из них. Иерархического наследования в группах нет. То есть если в область применения включена группа КЕ, в которую иерархически вложены другие группы, элементы проверки будут созданы только для КЕ из назначенной группы, вложенные группы не будут затрагиваться.
При удалении области действия (или КЕ из группы) соответсвующие элементы проверки будут уничтожены. При этом учитывается возможность пересечения скопов. То есть один КЕ может оказаться сразу в двух группах, которым назначено правило. Если одна из групп будет удалена из скопа, элемент проверки для такого КЕ не будет удален. Аналогично при автоматическом создании дублирующие элементы не создаются.

  • Замечание об эквивалентах.

Если вашему правилу был приписан некий эквивалент и вы решили приписать вместо него другой, что произойдет? Произойдет пересчет статусов всех элементов проверки этого правила и их новых эквивалентов в минимальное значение. Допустим у вашего правила есть элемент проверки связанный с неким КЕ и у этого элемента статус «не выполнено». Пусть с этим же КЕ связано еще несколько элементов проверки других правил. Вы изменили класс эквивалентности и теперь какие-то из упомянутых элементов проверок стали эквивалентны вашему. Их статус тут же будет установлен в «не выполнено». Разумеется это касается только элементов привязанных к одному и тому же КЕ. Именно к КЕ, а не к группе. Элементы проверки привязываются только к КЕ. Если ваш элемент имел статус «выполнено», а какой-то из новых эквивалентных ему окажется в статусе «не выполнено», то ваш элемент поменяет статус на «не выполнено».

  • Где показываются результаты?

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

  • Другие замечания.

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

 

Реклама

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s