? отчеты о внешних договорах и связанных с ними проблемах;

? отчеты об Операционных Соглашениях об Уровне Услуг (внутренние Планы по безопасности) и собственных принципах безопасности поставщика (например, по базовому Уровню Безопасности);

? отчеты о годовых планах по безопасности и планах действий.

Подпроцесс внедрения:

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

? перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с преды­дущим отчетным периодом;

? определение тенденций возникновения инцидентов;

? состояние программы оповещения.

Подпроцесс оценки:

? отчеты об эффективности подпроцессов;

? результаты аудиторских проверок, анализа и внутренних оценок;

? предупреждения, определение новых угроз.

Специальные отчеты:

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

15.5. Контроль процесса

15.5.1. Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха являются:

? полное понимание необходимости процесса со стороны руководства и его привлечение к процессу;

? привлечение пользователей к разработке процесса;

? точное определение и разделение ответственностей.

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

15.5.2. Функции и роли

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

15.6. Проблемы и затраты

15.6.1. Проблемы

Следующие аспекты имеют существенное значение для успешной реализации Процесса Управления Информационной Безопасностью:

? Понимание необходимости процесса (понимание со стороны участников): меры безопасности редко встречают быстрое положительное понимание со стороны персонала; чаще встречается сопро­тивление, а не одобрение. Пользователи возмущаются потерей определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются существенными для их работы. Это объясняется тем, что привилегии дают им определенный статус. Поэтому необходима специаль­ная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать пример ("разъяснять курс" и "вести за собой"). При отсутствии инцидентов по безопасно­сти у руководства может возникнуть искушение сократить расходы на Управление Безопасностью.

? Отношение: информационные системы небезопасны не из-за их технического несовершенства, а из-за ошибок при использовании технологии. Обычно это связано с человеческим отношением и поведением. Это означает, что процедуры безопасности должны быть интегрированы в рутинные операции.

? Осведомленность: осведомленность или, скорее, коммуникации является ключевым понятием. Между коммуникациями и безопасностью иногда возникает конфликт интересов: коммуникации мостят дорогу, а безопасность создает препятствия. Это означает, что реализация мер безопасно­сти требует использования всех способов коммуникаций для того, чтобы пользователи приняли необходимый стиль поведения.

? Верификация: должна существовать возможность проверки и верификации безопасности. Это от­носится как ко вводимым мерам, так и к причинам их введения. Необходима возможность убе­диться, что в соответствующих обстоятельствах приняты правильные решения. Например, долж­на быть возможность проверки полномочий тех, кто принимал решения.

? Управление Изменениями: часто при проведении изменений ослабевает качество оценки соответ­ствия базовому Уровню Безопасности.

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

? Отсутствие систем обнаружения: новые системы, такие, как Интернет, не были рассчитаны на безопасность и необходимость обнаружения взлома. Причина заключается в том, что разработка защищенной системы требует больше времени, чем незащищенной, и находится в конфликте с требованиями бизнеса по невысокой стоимости разработки и скорейшей поставке на рынок.

? Чрезмерные надежды на технологию "неприступной крепости": угрозы безопасности систем все чаще возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с первым примером атак Denial of Service (DoS). В то время как защита информации с использова­нием традиционного подхода "неприступной крепости" сохраняет свое значение, также приобре­тает важность подхода "встречных атак" при возникновении нарушений безопасности. Организа­ция должна иметь возможность быстро направить ресурсы в место возникновения дефекта до то­го, как он сможет выйти из-под контроля.

15.6.2. Затраты

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

Приложение А. Фирма "Quick Couriers" ("Быстрые курьеры")

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

Транспорт в Амстердаме в настоящее время так перегружен, что предоставление курьерских услуг с помощью автофургонов стало затруднительным. Поэтому после окончания учебы трое друзей Джейн, Джон и Питер решили заняться курьерскими услугами на велосипедах и открыли фирму Quick Couriers (QC). Фирма QC доставляет посылки в центр города, используя для этого велосипе­ды.

Сначала основатели фирмы Quick Couriers просто работали на себя, но потом они заключили дого­воры с международными курьерскими компаниями на получение и доставку посылок в центр горо­да, из-за чего они уже не могли выполнять всю работу сами. Поэтому сейчас они используют студен­тов, работающих на них неполный рабочий день и развозящих посылки на велосипедах фирмы.

Джейн является ответственной за бухгалтерию, выписывание счетов, обработку заказов и поддерж­ку деловых связей. Фирма Quick Couriers закупила программные приложения для бухгалтерии и Процесса Управления Взаимоотношениями.

Джон отвечает на телефонные звонки, рассматривает запросы заказчиков, занимается планировани­ем и материально-техническим снабжением курьерской службы, а также передает сообщения курье­ров Джейн и Питеру.