Книга: ИТ Сервис-менеджмент. Введение

15.3. Процесс

15.3. Процесс

Организации и их информационные системы меняются. Стандартные шаблоны, такие как Сборник практических рекомендаций по Управлению Информационной Безопасностью (Code of Practice for Information Security Management), статичны и недостаточно соответствуют быстрым изменениям в ИТ. По этой причине деятельность, ведущаяся в рамках Процесса Управления Информационной Безопасностью, должна постоянно пересматриваться в целях обеспечения эффективности Процесса. Управление Информационной Безопасностью сводится к никогда не прекращающемуся циклу планов, действий, проверок и актов. Виды деятельности, проводимые в рамках процесса Управления Информационной Безопасностью или в других процессах под контролем Управления Информационной Безопасностью, описываются ниже.

Рис. 15.1. Процесс Управления Информационной Безопасностью (источник: OGC)

Требования заказчика изображены в правом верхнем углу, как входные данные процесса. Эти требования определяются в разделе о безопасности Соглашения об Уровне Сервиса как услуги по безопасности и обеспечиваемый Уровень Безопасности. Поставщик услуг доводит эти соглашения до ИТ-организации в форме Плана по безопасности, определяющего критерии безопасности или операционные Соглашения об Уровне Услуг. Этот план исполняется и результаты оцениваются. Затем план и способы его реализации корректируются, о чем Управление Уровнем Сервиса сообщает заказчику. Таким образом, заказчик и поставщик услуг вместе участвуют в формировании всего цикла процесса. Заказчик может изменить требования на основе получаемых отчетов, а поставщик услуг может скорректировать план или его реализацию на основе результатов наблюдения или поставить задачу изменения договоренностей, определенных в соглашении SLA. Функция контроля представлена в центре рисунка 15.1. Далее эта диаграмма будет использоваться при описании видов деятельности Процесса Управления Информационной Безопасностью.

15.3.1. Взаимоотношения с другими процессами

Процесс Управления Информационной Безопасностью имеет связи с другими процессами ITIL (см. рис. 15.2), так как в других процессах выполняются действия, связанные с обеспечением безопасности. Эта деятельность проводится в обычном порядке в рамках ответственности определенного процесса и его руководителя. При этом Процесс Управления Информационной Безопасностью обеспечивает другие процессы инструкциями о структуре деятельности, связанной с безопасностью. Обычно соглашения об этом определяются после консультаций между Руководителем Процесса Управления Информационной Безопасностью и Руководителями других процессов.

Рис. 15.2. Отношения между Процессом Управления Информационной безопасностью и другими процессами (источник: OGC)

Управление Конфигурациями

В контексте информационной безопасности процесс Управления конфигурациями имеет наибольшее значение, так как он позволяет классифицировать Конфигурационные Единицы (CI). Эта классификация определяет связи между Конфигурационными Единицами и предпринимаемыми мерами или процедурами безопасности.

Классификация Конфигурационных Единиц определяет их конфиденциальность, целостность и доступность. Эта классификация основана на требованиях безопасности соглашений SLA. Заказчик ИТ-организации определяет классификацию, так как только заказчик может решить, насколько важны информация или информационные системы для бизнес-процессов. При создании классификации Конфигурационных Единиц заказчик учитывает степень зависимости бизнес-процессов от информационных систем и информации. Затем ИТ-организация увязывает классификацию с соответствующими Конфигурационными Единицами. ИТ-организация должна также реализовать комплекс мер безопасности для каждого Уровня Классификации. Эти комплексы мер могут быть описаны как процедуры, например «Процедура обращения с носителями данных с личной информацией». В соглашении SLA могут определяться комплексы мер безопасности для каждого Уровня Классификации. Система классификации должна всегда быть совместима со структурой организации заказчика. Однако для упрощения управления рекомендуется использовать одну общую систему классификации, даже если ИТ-организация имеет несколько заказчиков.

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

Управление Инцидентами

Управление Инцидентами является важным процессом, информирующим о наличии инцидентов, связанных с безопасностью. По своей природе связанные с безопасностью инциденты могут быть обработаны с помощью иной процедуры, чем другие инциденты. Поэтому важно, чтобы Процесс Управления Инцидентами распознавал инциденты по безопасности как таковые. Любой инцидент, который может помешать выполнению требований безопасности SLA, классифицируется как инцидент по безопасности. Было бы полезным включить в соглашения SLA определение типов инцидентов, рассматривающихся как инциденты по безопасности. Любой инцидент, препятствующий достижению базового внутреннего Уровня Безопасности, также всегда классифицируется как инцидент по безопасности.

Сообщения об инцидентах поступают не только от пользователей, но также от различных Процессов Управления, возможно, на основе аварийных сигналов или данных системного аудита. Крайне необходимо, чтобы Процесс Управления Инцидентами распознавал все инциденты по безопасности. Это требуется для инициирования соответствующих процедур для обработки таких инцидентов. Рекомендуется включить в планы процедуры для различных типов инцидентов по безопасности и опробовать их на практике. Также рекомендуется согласовывать процедуру оповещения об инцидентах, связанных с безопасностью. Нередко паника возникает из-за чрезмерно раздутых слухов. Точно так же нередко отсутствие своевременного оповещения об инцидентах по безопасности приводит к возникновению ущерба. Желательно, чтобы все внешние сообщения, относящиеся к инцидентам по безопасности, проходили через руководителя Процесса Управления Информационной Безопасностью.

Управление Проблемами

Процесс Управления Проблемами отвечает за идентификацию и устранение структурных сбоев по безопасности. Проблема может также привести к возникновению риска для системы безопасности. В этом случае Управление Проблемами должно привлечь на помощь Процесс Управления Информационной Безопасностью. Для того чтобы не возникло новых проблем с безопасностью, принятое окончательное или обходное решение должно быть проверено. Эта проверка должна основываться на соответствии предлагаемых решений требованиям соглашений SLA и внутренним требованиям безопасности.

Управление Изменениями

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

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

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

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

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

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

Управление Релизами

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

• используется соответствующее аппаратное и программное обеспечение;

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

• внедрение надлежащим образом санкционировано с помощью процедуры изменения;

• программное обеспечение является легальным;

• программное обеспечение не содержит вирусов, и вирусы не появятся при его распространении;

• номера версий известны и зарегистрированы в Базе Данных CMDB Процессом Управления Конфигурациями;

• управление развертыванием будет эффективным.

В этом процессе также используется обычная процедура приемки, которая должна охватывать аспекты информационной безопасности. Рассмотрение аспектов безопасности во время тестирования и приемки является особенно важным. Это означает, что требования и меры по безопасности, определенные в SLA, должны соблюдаться постоянно.

Управление Уровнем Сервиса

Процесс Управления Уровнем Сервиса гарантирует, что договоренности об услугах, предоставляемых заказчикам, определены и выполняются. В Соглашениях об Уровне Сервиса должны учитываться также меры безопасности. Целью этого является оптимизация Уровня Предоставляемых Услуг. Управление Уровнем Сервиса включает ряд видов деятельности, связанных с безопасностью, в которых важную роль играет Управление Информационной Безопасностью:

1. Определение потребностей заказчика в области безопасности. Естественно, определение необходимости в безопасности является ответственностью заказчика, так как эти потребности основаны на его интересах.

2. Проверка осуществимости требований заказчика по безопасности.

3. Предложение, обсуждение и определение Уровня Безопасности ИТ-услуг в SLA.

4. Определение, разработка и формулирование внутренних требований безопасности для ИТ-услуг (Операционные Соглашения об Уровне Услуг – OLA).

5. Мониторинг стандартов безопасности (OLA).

6. Составление отчетов о предоставляемых услугах.

Управление Информационной Безопасностью предоставляет Управлению Уровнем Сервиса входную информацию и поддержку для осуществления видов деятельности с 1 по 3. Виды деятельности 4 и 5 проводятся Управлением Информационной Безопасностью. Для деятельности 6 Управление Информационной Безопасностью и другие процессы предоставляют необходимую входную информацию. Руководители Процессов Управления Уровнем Сервиса и Управления Информационной Безопасностью после взаимных консультаций решают, кто реально занимается проведением этих операций. При составлении соглашений SLA обычно предполагается, что существует общий базовый Уровень Безопасности (baseline). Дополнительные требования заказчика по безопасности должны четко определяться в SLA

Управление Доступностью

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

Управление Мощностями

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

Управление Непрерывностью ИТ-услуг

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

15.3.2. Раздел по Безопасности Соглашения об Уровне Сервиса

Соглашение об Уровне Сервиса (SLA) определяет договоренности с заказчиком. Процесс Управления Уровнем Сервиса отвечает за соглашения SLA (см. также главу 10). Соглашение SLA является главной движущей силой всех процессов ITIL.

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

Рис. 15.3. Отношения между процессами (источник: OGC)

Эти бизнес-процессы зависят от ИТ-услуг; а поэтому и от ИТ-организации. Заказчик определяет требования к безопасности (требования к информационной безопасности SLA на рис. 15.3. отсутствуют) на основе анализа риска. На рис. 15.4. показано, как определяются элементы безопасности SLA.

Рис. 15.4. Составление раздела по безопасности в соглашении SLA (источник: OGC)

Элементы безопасности обсуждаются представителями заказчика и поставщика услуг. Поставщик услуг сравнивает требования к Уровню Услуг Заказчика со своим Каталогом Услуг, где описываются стандартные меры безопасности (базовый Уровень Безопасности). Заказчик может выдвигать дополнительные требования.

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

15.3.3. Раздел по Безопасности Операционного Соглашения об Уровне Услуг (OLA)

Еще одним важным документом является Операционное Соглашение об Уровне Услуг. В нем описываются услуги, предоставляемые внутренним поставщиком услуг. Поставщик должен связать эти договоренности с видами ответственности, существующими внутри организации. В Каталоге Услуг дается их общее описание. В Операционном Соглашении об Уровне Услуг эти общие описания преобразуются в конкретные определения всех услуг и их компонентов, а также способа выполнения договоренностей об Уровнях Услуг внутри организации.

Пример. В Каталоге Услуг значится «управление авторизацией пользователей и частных лиц». Операционное Соглашение об Уровне Услуг конкретизирует это для всех определенных услуг, предоставляемых ИТ-организацией. Таким образом, реализация мероприятия определяется для подразделений, предоставляющих услуги UNIX, VMS, NT, Oracle и т. д.

Там, где это возможно, требования заказчика к Уровню Сервиса определяются по Каталогу Услуг, а в случае необходимости заключаются дополнительные соглашения. Такие дополнительные меры повышают Уровень Безопасности по сравнению со стандартным.

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

Оглавление книги