Управление Информационной Безопасностью. Контролем процесса Управления Изменениями, то можно гарантировать, что этот Уровень безопас­ности будет обеспечиваться и после проведения изменений

контролем Процесса Управления Изменениями, то можно гарантировать, что этот Уровень Безопас­ности будет обеспечиваться и после проведения изменений. Для поддержки этого Уровня Безопас­ности существует ряд стандартных операций. Каждый Запрос на изменения (RFC) связан с рядом параметров, которые определяют процедуру приемки. Параметры срочности и степени воздействия могут быть дополнены параметром, связанным с безопасностью. Если Запрос на изменения (RFC) может оказать значительное воздействие на информационную безопасность, потребуются расши­ренные приемочные испытания и процедуры.

В Запрос на изменения (RFC) также должны быть включены предложения по решению вопросов безопасности. Они опять же должны основываться на требованиях SLA и базовом Уровне Внутрен­ней Безопасности, необходимом для ИТ-организации. Следовательно, эти предложения будут вклю­чать комплекс мер по обеспечению безопасности, основанный на Практических нормах по Управле­нию Информационной Безопасностью.

Желательно, чтобы руководитель Процесса Управления Информационной Безопасностью (а также, возможно, инспектор по безопасности от заказчика) был членом Консультативного комитета по из­менениям (Change Advisory Board — CAB).

Однако это не значит, что по всем изменениям необходимо консультироваться с Руководителем Процесса Управления Информационной Безопасностью. В нормальной ситуации безопасность должна быть интегрирована в обычный рабочий режим. Руководитель Процесса Управления Изме­нениями должен иметь возможность решать, требуется ли ему или комитету CAB входная информа­ция от Руководителя Процесса Управления Информационной Безопасностью. Точно так же руково­дитель Процесса Управления Информационной Безопасностью не обязательно должен участвовать в выборе мер для конкретных Конфигурационных Единиц затронутых Запросом на Изменения (RFC), так как для соответствующих мер уже должен существовать структурированный подход. Во­просы могут возникнуть только со способом реализации указанных мер.

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

С точки зрения безопасности Управление Изменениями является одним из наиболее важных про­цессов. Это объясняется тем, что Управление Изменениями вводит новые меры безопасности в ИТ-инфраструктуру вместе с изменениями этой инфраструктуры.