Текст книги "ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL"
Автор книги: Jan van Bon
сообщить о нарушении
Текущая страница: 17 (всего у книги 18 страниц)
Сообщения об инцидентах поступают не только от пользователей, но также от различных Процессов Управления, возможно, на основе аварийных сигналов или данных системного аудита. Крайне необходимо, чтобы Процесс Управления Инцидентами распознавал все инциденты по безопасности. Это требуется для инициирования соответствующих процедур для обработки таких инцидентов. Рекомендуется включить в планы процедуры для различных типов инцидентов по безопасности и опробовать их на практике. Также рекомендуется согласовывать процедуру оповещения об инцидентах, связанных с безопасностью. Нередко паника возникает из-за чрезмерно раздутых слухов. Точно так же нередко отсутствие своевременного оповещения об инцидентах по безопасности приводит к возникновению ущерба. Желательно, чтобы все внешние сообщения, относящиеся к инцидентам по безопасности, проходили через руководителя Процесса Управления Информационной Безопасностью.
Управление Проблемами
Процесс Управления Проблемами отвечает за идентификацию и устранение структурных сбоев по безопасности. Проблема может также привести к возникновению риска для системы безопасности. В этом случае Управление Проблемами должно привлечь на помощь Процесс Управления Информационной Безопасностью. Для того чтобы не возникло новых проблем с безопасностью, принятое окончательное или обходное решение должно быть проверено. Эта проверка должна основываться на соответствии предлагаемых решений требованиям соглашений 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 также описывается метод определения эффективности. ИТ-организация (поставщик услуг) должна регулярно предоставлять отчеты организации пользователя (заказчика).
15.4. Виды деятельности
15.4.1. Контроль – политика и организация информационной безопасности
Контроль информационной безопасности, представленный в центре рисунка 15.1, является первым подпроцессом Управления Информационной Безопасностью, и относится к организации и Управлению Процессом. Этот вид деятельности включает в себя структурированный подход Управления Информационной Безопасностью, который описывает следующие подпроцессы: формулирование Планов по безопасности, их реализация, оценка реализации и включение оценки в годовые Планы по безопасности (планы действий). Также описываются отчеты, предоставляемые заказчику через Процесс Управления Уровнем Сервиса.
Этот вид деятельности определяет подпроцессы, функции безопасности, роли и ответственности. Он также описывает организационную структуру, систему отчетности и потоки управления (кто кого инструктирует, кто что делает, как производится доклад о выполнении). Следующие меры из сборника практических рекомендаций по Управлению Информационной Безопасностью реализуются в рамках этого вида деятельности.
Внутренние правила работы (политика)[250]250
Policy.
[Закрыть]:
? разработка и реализация внутренних правил работы (политики), связи с другими правилами;
? цели, общие принципы и значимость;
? описание подпроцессов;
? распределение функций и ответственностей по подпроцессам;
? связи с другими процессами ITIL и их управлением;
? общая ответственность персонала;
? обработка инцидентов, связанных с безопасностью.
Организация информационной безопасности:
? структурная схема управления[251]251
Management Framework.
[Закрыть];
? структура управления (организационная структура);
? более детальное распределение ответственностей;
? учреждение Руководящего комитета по информационной безопасности[252]252
Information Security Steering Committee.
[Закрыть];
? координация информационной безопасности;
? согласование инструментальных средств (например, для анализа риска и улучшения осведомленности);
? описание процесса авторизации средств ИТ в консультации с заказчиком;
? консультации специалистов;
? сотрудничество между организациями, внутреннее и внешнее взаимодействие;
? независимый аудит информационных систем;
? принципы безопасности при доступе к информации третьих сторон;
? информационная безопасность в договорах с третьими сторонами.
15.4.2. Планирование
Подпроцесс планирования сводится к определению содержания раздела соглашений SLA по вопросам безопасности при участии Процесса Управления Уровнем Сервиса и описанию деятельности, связанной с вопросами безопасности, проводимой в рамках Внешних Договоров. Задачи, которые в соглашении SLA определяются общими словами, детализируются и конкретизируются в форме Операционного Соглашения об Уровне Услуг (OLA). Соглашение OLA может рассматриваться как План по безопасности для организационной структуры поставщика услуг и как конкретный План по безопасности, например, для каждой ИТ-платформы, приложения и сети.
Входной информацией для подпроцесса планирования являются не только положения соглашения SLA, но и принципы политики безопасности поставщика услуг (из подпроцесса контроля). Примерами этих принципов: "Каждый пользователь должен быть идентифицирован уникальным образом"; "Базовый Уровень Безопасности предоставляется всегда и для всех заказчиков".
Операционные Соглашения об Уровне Услуг (OLA) в отношении информационной безопасности (конкретные Планы по безопасности) разрабатываются и реализуются с помощью обычных процедур. Это означает, что если эти виды деятельности стали необходимы в других процессах, то нужна координация с этими процессами. Все необходимые изменения ИТ-инфраструктуры проводятся Процессом Управления Изменениями с использованием входной информации, предоставляемой Процессом Управления Информационной Безопасностью. Ответственным за Процесс Управления Изменениями является Руководитель этого Процесса.
Подпроцесс планирования координируется с Процессом Управления Уровнем Сервиса по вопросам определения содержания раздела по безопасности соглашения SLA, его обновления и обеспечения соответствия его положениям. За эту координацию отвечает руководитель Процесса Управления Уровнем Сервиса.
Требования по безопасности должны определяться в соглашении SLA, по возможности в измеримых показателях. Раздел по безопасности соглашения SLA должен гарантировать, что достижение всех требований и стандартов безопасности заказчика может быть проконтролировано.
15.4.3. Реализация
Задачей подпроцесса реализации (внедрения) является выполнение всех мероприятий, определенных в планах. Этот подпроцесс может поддерживаться следующим контрольным списком действий.
Классификация и Управление ИТ-ресурсами:
? предоставление входных данных для поддержки Конфигурационных Единиц (CI) в базе CMDB;
? классификация ИТ-ресурсов в соответствии с согласованными принципами.
Безопасность персонала:
? задачи и ответственности в описании работ;
? отбор персонала;
? соглашения о конфиденциальности для персонала;
? обучение персонала;
? руководства для персонала по разрешению инцидентов, связанных с безопасностью, и устранению обнаруженных дефектов защиты;
? дисциплинарные меры;
? улучшение осведомленности по вопросам безопасности.
Управление Безопасностью:
? внедрение видов ответственности и распределение обязанностей;
? письменные рабочие инструкции;
? внутренние правила;
? меры безопасности должны охватывать весь жизненный цикл систем; должны существовать руководства по безопасности для разработки систем, их тестирования, приемки, операционного использования, обслуживания и выведения из операционной среды;
? отделение среды разработки и тестирования от операционной (рабочей) среды;
? процедуры обработки инцидентов (осуществляемые Процессом Управления Инцидентами);
? использование средств восстановления;
? предоставление входной информации для Процесса Управления Изменениями;
? внедрение мер защиты от вирусов;
? внедрение методов управления для компьютеров, приложений, сетей и сетевых услуг;
? правильное обращение с носителями данных и их защита.
Контроль доступа:
? внедрение политики доступа и контроля доступа;
? поддержка привилегий доступа пользователей и приложений к сетям, сетевым услугам, компьютерам и приложениям;
? поддержка барьеров сетевой защиты (фаервол, услуги доступа по телефонной линии, мосты и маршрутизаторы);
? внедрение методов идентификации и авторизации компьютерных систем, рабочих станций и ПК в сети
15.4.4. Оценка
Существенное значение имеет независимая оценка реализации запланированных мероприятий. Такая оценка необходима для определения эффективности, ее выполнение также требуют заказчики и третьи стороны. Результаты подпроцесса оценки могут использоваться для корректировки согласованных с заказчиком мер, а также для их реализации. По результатам оценки могут быть предложены изменения, в случае чего формулируется Запрос на изменения (RFC), направляемый в Процесс Управления Изменениями.
Существует три вида оценки:
? самостоятельная оценка: проводится в первую очередь линейными подразделениями организации;
? внутренний аудит: проводится внутренними ИТ-аудиторами;
? внешний аудит: проводится внешними ИТ-аудиторами.
В отличие от самостоятельной оценки аудит не проводится тем же персоналом, который участвует в других подпроцессах. Это необходимо для обеспечения разделения ответственностей. Аудит может проводиться отделом внутреннего аудита.
Оценка также проводится как ответное действие в случае возникновения инцидентов.
Основными видами деятельности являются:
? проверка соответствия политике безопасности и реализация Планов по безопасности;
? проведение аудита безопасности ИТ-систем;
? определение и принятие мер несоответствующего использования ИТ-ресурсов;
? проверка аспектов безопасности в других видах ИТ-аудита.
15.4.5. Поддержка
В связи с изменением рисков при изменениях в ИТ-инфраструктуре, в компании и в бизнес-процессах необходимо обеспечить должную поддержку мер безопасности. Поддержка мер безопасности включает поддержку соответствующих разделов по безопасности соглашений SLA и поддержку подробных Планов по безопасности (на Уровне Операционных Соглашений об Уровне Услуг).
Поддержание эффективного функционирования системы безопасности проводится на основе результатов подпроцесса Оценки и анализа изменений рисков. Предложения могут быть внедрены или в подпроцессе планирования, или в ходе обеспечения поддержки всего соглашения SLA. В любом случае внесенные предложения могут привести ко включению дополнительных инициатив в годовой План по безопасности. Любые изменения подлежат обработке в рамках обычного Процесса Управления Изменениями.
15.4.6. Составление отчетов
Составление отчетов является видом деятельности по предоставлению информации из других подпроцессов. Отчеты составляются для предоставления информации о достигнутых характеристиках безопасности и для информирования заказчиков о проблемах безопасности. Вопросы предоставления отчетов обычно согласовываются с заказчиком.
Составление отчетов является важным как для заказчика, так и для поставщика услуг. Заказчики должны иметь точную информацию об эффективности работы (например, по реализации мер безопасности) и о принимаемых мерах безопасности. Заказчик также информируется о любых инцидентах, связанных с безопасностью. Ниже даются предложения по составлению отчетов.
Примеры регулярных отчетов и включаемых в них событий:
Подпроцесс планирования:
? отчеты о степени соответствия соглашению SLA и согласованным ключевым показателям качества по вопросам безопасности;
? отчеты о внешних договорах и связанных с ними проблемах;
? отчеты об Операционных Соглашениях об Уровне Услуг (внутренние Планы по безопасности) и собственных принципах безопасности поставщика (например, по базовому Уровню Безопасности);
? отчеты о годовых планах по безопасности и планах действий.
Подпроцесс внедрения:
? отчеты о состоянии дел в информационной безопасности. Сюда входят отчет о выполнении годового плана по безопасности, перечень осуществленных или намеченных мер, информация об обучении, результаты дополнительного анализа рисков и т. д.;
? перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с предыдущим отчетным периодом;
? определение тенденций возникновения инцидентов;
? состояние программы оповещения.
Подпроцесс оценки:
? отчеты об эффективности подпроцессов;
? результаты аудиторских проверок, анализа и внутренних оценок;
? предупреждения, определение новых угроз.
Специальные отчеты:
Для сообщений об определенных в соглашении 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 закупила программные приложения для бухгалтерии и Процесса Управления Взаимоотношениями.
Джон отвечает на телефонные звонки, рассматривает запросы заказчиков, занимается планированием и материально-техническим снабжением курьерской службы, а также передает сообщения курьеров Джейн и Питеру.
Питер отвечает за обслуживание велосипедов, заказывает детали и инструменты, планирует материально-техническое обеспечение и инструктирует курьеров.
