назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [ 63 ] [64] [65] [66] [67] [68] [69] [70] [71] [72]


63

IpcnoBaiinji заказчика изображены в правом верхнем углу, как входные данные процесса. Эти требо-naiHHi он])едсл5потся в разделе о безонасиостп Соглапгения об Уровне Сервиса как услуги ио безопасности и обеспечиваемый Уровень Безопасности. Поставнцпс услуг доводит эти соглапюния до ИГ-организагип! в форме Плана по безопасности, онределяюн1его критерии безопаснос.ти или опе-рацпон1п>1е Соглашения об Уровне Услуг. Этот план исполняется н результаты оцениваются. Затем план п способы его реализации корректируются, о чем Управление Уровнем Сервиса сообп1ает заказчику. Таким образом, заказчик и поставщик услуг вместе участвуют в формировании всего цикла процесса. Заказчик может изменить Г11ебования иа основе получаемых отчетов, а поставщик услуг может ско)ректи1)овать план или его реализацию на основе результатов наблюдения или поставить задачу изменения договоренн(ютей, определенных в соглашении SLA. Функция контроля представлена в цспг])с рисунка \5Л. Далее эта диаграм,\1а будет использоваться при описании видов деятельности Процесса Управления Инфо])мацио)1пой Безопасностью.

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

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

Взаимоотношения с:

Управлением Взаимоотношениями с Заказчиками ИТ

Взаимоотношения с:

Управлением Уровнем Услуг Управлением Финансами ИТ Управлением Доступностью Управлением Мощностями Управлением Непрерывностью Бизнеса

Взаимоотношения с:

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

Управлением Инцидентами и Службой Service Desk Управлением Проблемами Управлением Изменениями

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

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

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

Класси(1)нкаппя Конфигурацнопных Единиц определяет их копфпде1П(иальность, целостность и доступность. .Эта к.масспф1п<ация основана па требованиях безопасности соглашений SEA. Заказчик ИТ-организации определяет классификацию, так как только заказчик может репшть, насколько важны



15. ШРАВАЕМт ИНФОРМАЦИОННОЙ Bf OilACHOCTbiC?

11И(])ормацня НЛП информацио1Н1ые системы для бизнес-процессов. При создан1И1 классификации Конфигурационных Единиц заказчик зачитывает степень зависимости бизнес-процессов от ии(х)рма-ционных систем и 1ик1)ормации. Затем ИТ-организация увязывает классификащио с соответствующими Конфигурационными Единицами. ИТ-организация должна также реализовать комплекс мер безопасности д.пя каждого Уровня Юшссификации. Этн комплексы мер могут бьтть описаны как процедуры, например «Процедура обран1ения с носителями данных с личной информацией*-. В соглашении SLA MOTJT определяться комплексы Meji бсзоиастюсти для каждого Уровня Классификащпт Система классификации должна всегда быть совместима со структуро!! oprannsain-in заказчика. Однако для упрощения управлапш рекомендуется использовать одну общую систему классификации, даже если ИТ-организация имеет несколько заказчиков.

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

Управление Инцидента.\1и

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

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

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

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

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

Виды работ, выполняемых в рамках Процесса Управления Изменениями, часто бывают тесно связаны с безопасностью, так как Управление Изменениями и Управление Ии()ормацио1И10Й Безопасностью взаимозависимы. Если достигнут приемлемый Уровень Безопасности, которьп"! находится иод



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [ 63 ] [64] [65] [66] [67] [68] [69] [70] [71] [72]