Управление информационной безопасностью на основе ITIL и ISO 27001

Введение

Управление безопасностью ITIL описывает структурированное внедрение безопасности в организацию. Управление безопасностью ITIL основано на стандарте ISO 27001. "ISO/IEC 27001:2005 охватывает все типы организаций (например, коммерческие предприятия, государственные учреждения, некоммерческие организации). ISO/IEC 27001:2005 определяет требования к установлению, внедрению, функционированию, мониторингу, анализу, поддержанию и улучшению документированной системы управления информационной безопасностью в контексте общих бизнес-рисков организации. Он определяет требования к реализации мер безопасности, адаптированных к потребностям отдельных организаций или их частей. ISO/IEC 27001:2005 разработан для обеспечения выбора адекватных и соразмерных мер безопасности, которые защищают информационные активы и вселяют уверенность заинтересованным сторонам". Базовым понятием управления безопасностью является информационная безопасность. Основная цель информационной безопасности – контроль доступа к информации. Ценность информации – это то, что необходимо защищать. Эти ценности включают конфиденциальность, целостность и доступность. Вытекающими аспектами являются конфиденциальность, анонимность и верифицируемость. Цель управления безопасностью состоит из двух частей:

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

Управление безопасностью

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

Контроль

Первая деятельность в процессе управления безопасностью – это подпроцесс “Контроль”. Подпроцесс “Контроль” организует и управляет процессом управления безопасностью. Подпроцесс “Контроль” определяет процессы, распределение ответственности за политики и структуру управления. Рамочная структура управления безопасностью определяет подпроцессы разработки, внедрения и оценки, преобразуя их в планы действий. Кроме того, в рамках управления определяется, как результаты должны быть представлены заказчикам. Таблица 2.1.2: Понятие и определение подпроцесса контроля. Деятельность управления безопасностью Поддеятельность Описание Контроль Реализация политик Этот процесс определяет конкретные требования и правила, которые необходимо соблюдать для реализации управления безопасностью. Процесс завершается формулировкой политики. Настройка организации безопасности Этот процесс создает организационную структуру для информационной безопасности. Например, в рамках этого процесса определяется структура ответственности. Процесс завершается созданием рамочной структуры управления безопасностью. Отчетность В этом процессе весь процесс целеполагания документируется в определенном формате. Процесс завершается составлением отчетов. Мета-модель процесса подпроцесса контроля основана на диаграмме деятельности UML и предоставляет обзор деятельности подпроцесса контроля. Серый прямоугольник представляет подпроцесс контроля, а меньшие элементы внутри него – действия, происходящие в его рамках. Понятие Описание Документы контроля Контроль – это описание организации и управления безопасностью. Политики Политики определяют конкретные требования или правила, которые должны быть соблюдены. В сфере информационной безопасности политики обычно касаются конкретных аспектов, охватывая одну область. Например, политики “приемлемого использования” регулируют правила и нормы надлежащего использования вычислительных ресурсов. Рамочная структура управления информационной безопасностью Рамочная структура управления информационной безопасностью – это установленная структура управления, предназначенная для инициирования и контроля внедрения информационной безопасности в организации и управления текущим обеспечением информационной безопасности. Мета-модель данных подпроцесса контроля основана на диаграмме классов UML. Рисунок 2.1.2 демонстрирует мета-модель подпроцесса контроля. Рисунок 2.1.2: Мета-модель процесса подпроцесса контроля.

The first activity in the security management process is the “Control” sub process. The Control sub process organizes and manages the security management process. The Control sub process defines the processes, the allocation of responsibility for the policy statements and the management framework. The security management framework defines the sub processes for development, implementation and evaluations into action plans. Furthermore, the management framework defines how results should be reported to clients. +Table 2.1.2: Concept and definition control sub process Security management Activities Sub Activities Descriptions Control Implement policies This process outlines the specific requirements and rules that have to be met in order to implement security management. The process ends with policy statement. Set up the security organization This process sets up the organizations for information security. For example, in this process the structure the responsibilities are set up. This process ends with security management framework. Reporting In this process the whole targeting process is documented in a specific way. This process ends with reports. The meta process model of the control sub process is based on a UML activity diagram and gives an overview of the activities of the Control sub process. The grey rectangle represents the control sub process and the smaller beam shapes inside it represent activities that take place inside it. Concept Description Control documents Control is a description of how security management is organized and how it is managed. Policy statements Policy statements outline specific requirements or rules that must be met. In the information security realm, policies are usually point specific, covering a single area. For example, "acceptable use" policies cover the rules and regulations for appropriate use of the computing facilities. Security management framework Security management framework is an established management framework to initiate and control the implementation of information security within an organization and to manage ongoing information security provision. The meta data model of the control sub process is based on a UML class diagram. Figure 2.1.2 shows the metamodel of the control sub process. Figure 2.1.2: Meta process model control sub process

Прямоугольник “CONTROL” с белой тенью является открытой сложной концепцией. Это означает, что прямоугольник “Контроль” состоит из набора (под)концепций. Рисунок 2.1.3 представляет собой модель данных процесса подпроцесса контроля. Он демонстрирует интеграцию двух моделей. Пунктирные стрелки указывают на концепции, которые создаются или корректируются в соответствующих видах деятельности. Рисунок 2.1.3: Модель данных процесса подпроцесса контроля.

План

Подпроцесс "План" содержит действия, которые в сотрудничестве с управлением уровнем обслуживания приводят к разделу "Безопасность (информации)" в SLA. Кроме того, подпроцесс "План" содержит действия, связанные с базовыми контрактами, которые специфичны для (информационной) безопасности. В подпроцессе "План" цели, сформулированные в SLA, конкретизируются в форме соглашений на операционном уровне (OLA). Эти OLA могут быть определены как планы безопасности для конкретного внутреннего подразделения поставщика услуг. Помимо входных данных SLA, подпроцесс "План" также работает с политиками самого поставщика услуг. Как уже говорилось ранее, эти политики определяются в подпроцессе контроля. Соглашения на операционном уровне по информационной безопасности разрабатываются и внедряются на основе процесса ITIL. Это требует взаимодействия с другими процессами ITIL. Например, если управление безопасностью хочет изменить ИТ-инфраструктуру для повышения безопасности, эти изменения будут реализованы через процесс управления изменениями. Управление безопасностью предоставляет входные данные (запрос на изменение) для этого изменения. Менеджер по изменениям отвечает за процесс управления изменениями. +Таблица 2.2.1: (Под)действия и описания Подпроцесс "План" ITIL Управление безопасностью Деятельность Поддеятельность Описание Планирование Создать раздел безопасности для SLA Этот процесс содержит действия, приводящие к разделу соглашений по безопасности в соглашениях об уровне обслуживания. В конце этого процесса создается раздел "Безопасность" соглашения об уровне обслуживания. Создание базовых контрактов Этот процесс содержит действия, приводящие к базовым контрактам, специфичным для безопасности. Создание соглашений на операционном уровне Общие цели, сформулированные в SLA, конкретизируются в соглашениях на операционном уровне. Эти соглашения можно рассматривать как планы безопасности для конкретных организационных подразделений. Отчетность В этом процессе весь процесс создания плана документируется определенным образом. Этот процесс завершается составлением отчетов. План состоит из комбинации неупорядоченных и упорядоченных (под)действий. Подпроцесс содержит три комплексных действия, которые являются закрытыми, и одно стандартное действие. +Таблица 2.2.2: Концепция и определение Подпроцесс "План" управление безопасностью Концепция Описание План Сформулированные схемы для соглашений по безопасности. Раздел безопасности соглашений об уровне обслуживания Раздел соглашений по безопасности в письменных соглашениях между поставщиком услуг и клиентом, документирующий согласованные уровни обслуживания для услуги. Базовые контракты Контракт с внешним поставщиком, охватывающий предоставление услуг, поддерживающих ИТ-организацию в предоставлении услуг. Соглашения на операционном уровне Внутреннее соглашение, охватывающее предоставление услуг, поддерживающих ИТ-организацию в предоставлении услуг. Как и подпроцесс "Контроль", подпроцесс "План" моделируется с использованием метода метамоделирования. Левая сторона рисунка 2.2.1 представляет собой метамодель данных подпроцесса "План". Прямоугольник "План" является открытой (комплексной) концепцией, имеющей отношение агрегации к двум закрытым (комплексным) концепциям и одной стандартной концепции. Эти две закрытые концепции в данном контексте не детализируются. Следующий рисунок (рисунок 2.2.1) представляет собой диаграмму данных процесса подпроцесса "План". На этом рисунке показана интеграция двух моделей. Пунктирные стрелки указывают, какие концепции создаются или изменяются в соответствующих действиях подпроцесса "План". Рисунок 2.2.1: Модель данных процесса Подпроцесс "План"

The Plan sub process contains activities that in cooperation with service level management lead to the (information) Security section in the SLA. Furthermore, the Plan sub process contains activities that are related to the underpinning contracts which are specific for (information) security. In the Plan sub process the goals formulated in the SLA are specified in the form of operational level agreements (OLA). These OLA's can be defined as security plans for a specific internal organization entity of the service provider. Besides the input of the SLA, the Plan sub process also works with the policy statements of the service provider itself. As said earlier these policy statements are defined in the control sub process. The operational level agreements for information security are set up and implemented based on the ITIL process. This requires cooperation with other ITIL processes. For example, if security management wishes to change the IT infrastructure in order to enhance security, these changes will be done through the change management process. Security management delivers the input (Request for change) for this change. The Change Manager is responsible for the change management process. +Table 2.2.1: (Sub) activities and descriptions Plan sub process ITIL Security Management Activities Sub activities Descriptions Plan Create Security section for SLA This process contains activities that lead to the security agreements paragraph in the service level agreements. At the end of this process the Security section of the service level agreement is created. Create underpinning contracts This process contains activities that lead to underpinning contracts. These contracts are specific for security. Create operational level agreements The general formulated goals in the SLA are specified in operational level agreements. These agreements can be seen as security plans for specific organization units. Reporting In this process the whole Create plan process is documented in a specific way. This process ends with reports. Plan consists of a combination of unordered and ordered (sub) activities. The sub process contains three complex activities that are all closed activities and one standard activity. +Table 2.2.2: Concept and definition Plan sub process security management Concept Description Plan Formulated schemes for the security agreements. Security section of the security level agreements The security agreements paragraph in the written agreements between a service provider and the customer(s) that documents agreed service levels for a service. Underpinning contracts A contract with an external supplier covering delivery of services that support the IT organisation in their delivery of services. Operational level agreements An internal agreement covering the delivery of services which support the IT organization in their delivery of services. Just as the Control sub process the Plan sub process is modeled using the meta modeling technique. The left side of figure 2.2.1 is the meta data model of the Plan sub process. The Plan rectangle is an open (complex) concept which has an aggregation type of relationship with two closed (complex) concepts and one standard concept. The two closed concepts are not expanded in this particular context. The following picture (figure 2.2.1) is the process data diagram of the Plan sub process. This picture shows the integration of the two models. The dotted arrows indicate which concepts are created or adjusted in the corresponding activities of the Plan sub process. Figure 2.2.1: Process data model Plan sub process

Реализация

Подпроцесс "Реализация" обеспечивает надлежащее выполнение всех мер, указанных в планах. В процессе реализации никакие меры не определяются и не изменяются. Определение или изменение мер осуществляется в рамках подпроцесса "План" в сотрудничестве с процессом управления изменениями. Таблица 2.3.1: (Под)действия и описания Подпроцесс реализации ITIL Деятельность по управлению безопасностью Поддеятельность ОписанияРеализация Классификация и управление ИТ-приложениями Процесс формальной группировки элементов конфигурации по типам, например, программное обеспечение, аппаратное обеспечение, документация, окружение и приложения. Процесс формального определения изменений по типам, например, запрос на изменение области проекта, запрос на изменение валидации, запрос на изменение инфраструктуры. Этот процесс приводит к классификации активов и документам контроля. Реализация мер по обеспечению безопасности персонала Принимаются меры для обеспечения безопасности и уверенности персонала, а также для предотвращения преступлений и мошенничества. Процесс завершается обеспечением безопасности персонала. Реализация управления безопасностью Определяются и документируются конкретные требования и/или правила безопасности, которые должны быть выполнены. Процесс завершается политиками безопасности. Реализация контроля доступа Определяются и документируются конкретные требования безопасности доступа и/или правила безопасности доступа, которые должны быть выполнены. Процесс завершается контролем доступа. Отчетность Весь процесс реализации в соответствии с планом документируется определенным образом. Этот процесс завершается составлением отчетов. Левая сторона рисунка 2.3.1 представляет собой мета-модель процесса фазы реализации. Четыре метки с черной тенью указывают на то, что эти действия являются закрытыми понятиями и не расширяются в данном контексте. Отсутствие стрелок, соединяющих эти четыре действия, означает, что они не упорядочены, и отчетность будет выполняться после завершения всех четырех действий. В ходе фазы реализации создаются и/или корректируются концепции. +Таблица 2.3.2: Концепция и определение Подпроцесс реализации Управление безопасностью Концепция ОписаниеРеализация Успешно реализованное управление безопасностью в соответствии с планом управления безопасностью. Классификация активов и документы контроля Всеобъемлющая инвентаризация активов с назначенной ответственностью за обеспечение эффективной защиты безопасности. Обеспечение безопасности персонала Четко определенные должностные инструкции для всего персонала, определяющие роли и обязанности в области безопасности. Политики безопасности Документы, в которых излагаются конкретные требования безопасности или правила безопасности, которые должны быть выполнены. Контроль доступа Управление сетью для обеспечения того, чтобы доступ к информации в сетях имели только лица, обладающие соответствующей ответственностью, и для защиты поддерживающей инфраструктуры. Созданные и/или скорректированные концепции моделируются с использованием метода метамоделирования. Правая сторона рисунка 2.3.1 представляет собой мета-модель данных подпроцесса реализации. Документы по реализации являются открытой концепцией и расширяются в данном контексте. Она состоит из четырех закрытых концепций, которые не расширяются, поскольку они не имеют отношения к данному конкретному контексту. Для большей ясности взаимосвязей между двумя моделями интеграция двух моделей иллюстрируется на рисунке 2.3.1. Пунктирные стрелки, идущие от действий к концепциям, показывают, какие концепции создаются/корректируются в соответствующих действиях. Рисунок 2.3.1: Модель данных процесса Подпроцесс реализации.

The Implementation sub process makes sure that all measures, as specified in the plans, are properly implemented. During the Implementation sub process no measures are defined nor changed. The definition or change of measures takes place in the Plan sub process in cooperation with the Change Management Process. +Table 2.3.1: (Sub) activities and descriptions Implementation sub process ITIL Security Management Activities Sub activities DescriptionsImplement Classifying and managing of IT applications Process of formally grouping configuration items by type, e. g., software, hardware, documentation, environment and application. Process of formally identifying changes by type e. g., project scope change request, validation change request, infrastructure change request this process leads to asset classification and control documents. Implement personnel security Measures are adopted to give personnel safety and confidence and measures to prevent a crime/fraud. The process ends with personnel security. Implement security management Specific security requirements and/or security rules that must be met are outlined and documented. The process ends with security policies. Implement access control Specific access security requirements and/or access security rules that must be met are outlined and documented. The process ends with access control. Reporting The whole implement as planned process is documented in a specific way. This process ends with reports. The left side of figure 2.3.1 is the meta process model of the Implementation phase. The four labels with a black shadow mean that these activities are closed concepts and they are not expanded in this context. No arrows connect these four activities, meaning that these activities are unordered and the reporting will be carried out after the completion of all four activities. During the implementation phase concepts are created and /or adjusted. +Table 2.3.2: Concept and definition Implementation sub process Security management Concept Description Implementation Accomplished security management according to the security management plan. Asset classification and control documents A comprehensive inventory of assets with responsibility assigned to ensure that effective security protection is maintained. Personnel security Well defined job descriptions for all staff outlining security roles and responsibilities. Security policies Documents that outline specific security requirements or security rules that must be met. Access control Network management to ensure that only those with the appropriate responsibility have access to information in the networks and the protection of the supporting infrastructure. The concepts created and/or adjusted are modeled using the meta modeling technique. The right side of figure 2.3.1 is the meta data model of the implementation sub process. Implementation documents are an open concept and is expanded upon in this context. It consists of four closed concepts that are not expanded because they are irrelevant in this particular context. In order to make the relations between the two models clearer the integration of the two models is illustrated in Figure 2.3.1. The dotted arrows running from the activities to the concepts illustrate which concepts are created/ adjusted in the corresponding activities. Figure 2.3.1: Process data model Implementation sub process

Оценка

Оценка необходима для измерения успешности планов внедрения и безопасности. Оценка важна для клиентов (и, возможно, третьих сторон). Результаты подпроцесса оценки используются для поддержания согласованных мер и реализации. Результаты оценки могут привести к новым требованиям и соответствующему запросу на изменение. Запрос на изменение затем определяется и отправляется в Управление изменениями. Существуют три вида оценки: самооценка, внутренний аудит и внешний аудит. Самооценка в основном проводится внутри организации процессов. Внутренние аудиты проводятся внутренними ИТ-аудиторами. Внешние аудиты проводятся внешними независимыми ИТ-аудиторами. Помимо вышеупомянутых, проводится оценка на основе зафиксированных инцидентов безопасности. Наиболее важными видами деятельности для этой оценки являются мониторинг безопасности ИТ-систем; проверка соответствия законодательству в области безопасности и реализации плана безопасности; отслеживание и реагирование на нежелательное использование ИТ-ресурсов. Таблица 2.4.1: (Под)деятельности и описания Подпроцесс оценки ITIL Управление безопасностью Деятельность Поддеятельность Описание Оценить Самооценка Изучить реализованные соглашения по безопасности. Результатом этого процесса являются документы самооценки. Внутренний аудит Проверить реализованные соглашения по безопасности с помощью внутреннего аудитора EDP. Результатом этого процесса является внутренний аудит. Внешний аудит Проверить реализованные соглашения по безопасности с помощью внешнего аудитора EDP. Результатом этого процесса является внешний аудит. Оценка на основе инцидентов безопасности Изучить реализованные соглашения по безопасности на основе событий безопасности, которые не являются частью стандартной работы сервиса и которые вызывают или могут вызвать прерывание или снижение качества этого сервиса. Результатом этого процесса являются инциденты безопасности. Отчетность Документировать процесс оценки реализации определенным образом. Этот процесс завершается составлением отчетов. Диаграмма данных процесса, представленная на рисунке 2.4.1, состоит из модели метапроцесса и модели метаданных. Подпроцесс оценки был смоделирован с использованием метода метамоделирования. Пунктирные стрелки, идущие от метадиаграммы процессов (слева) к метадиаграмме данных (справа), указывают, какие концепции создаются/корректируются в соответствующих действиях. Все действия на этапе оценки являются стандартными. Краткое описание концепций этапа оценки приведено в таблице 2.4.2, где концепции перечислены и определены. Концепция Описание ОЦЕНКА Оцененная/проверенная реализация. РЕЗУЛЬТАТЫ Результат оценки реализации. ДОКУМЕНТЫ САМООЦЕНКИ Результат проверки организации процесса в отношении управления безопасностью. ВНУТРЕННИЙ АУДИТ Результат проверки управления безопасностью внутренним аудитором EDP. ВНЕШНИЙ АУДИТ Результат проверки управления безопасностью внешним аудитором EDP. ДОКУМЕНТЫ ПО ИНЦИДЕНТАМ БЕЗОПАСНОСТИ Результаты оценки событий безопасности, которые не являются частью стандартной работы сервиса и которые вызывают или могут вызвать прерывание или снижение качества этого сервиса. Таблица 2.4.2: Концепции и определения подпроцесса оценки Управление безопасностью.

Evaluation is necessary to measure the success of the implementation and security plans. The evaluation is important for clients (and possibly third parties). The results of the Evaluation sub process are used to maintain the agreed measures and the implementation. Evaluation results can lead to new requirements and a corresponding Request for Change. The request for change is then defined and sent to Change Management. The three sorts of evaluation are self assessment, internal audit and external audit. The self assessment is mainly carried out in the organization of the processes. Internal audits are carried out by internal IT auditors. External audits are carried out by external, independent IT auditors. Besides those already mentioned, an evaluation based on communicated security incidents occurs. The most important activities for this evaluation are the security monitoring of IT systems; verify the security legislation and security plan implementation; trace and react to undesirable use of IT supplies. +Table 2.4.1: (Sub) activities and descriptions Evaluation sub process ITIL Security Management Activities Sub Activities Descriptions Evaluate Self assessment Examine implemented security agreements. The result of this process is self assessment documents. Internal Audit Examine implemented security agreements by an internal EDP auditor. The result of this process is internal audit. External audit Examine implemented security agreements by an external EDP auditor. The result of this process is external audit. Evaluation based on security incidents Examine implemented security agreements based on security events that are not part of the standard operation of a service and which cause, or may cause, an interruption to, or a reduction in, the quality of that service. The result of this process is security incidents. Reporting Document the Evaluate implementation process in a specific way. This process ends with reports. Figure 2.4.1: Process data model Evaluation sub process

The process data diagram illustrated in the figure 2.4.1 consists of a meta process model and a meta data model. The Evaluation sub process was modeled using the meta modeling technique. The dotted arrows running from the meta process diagram (left) to the meta data diagram (right) indicate which concepts are created/ adjusted in the corresponding activities. All of the activities in the evaluation phase are standard activities. For a short description of the Evaluation phase concepts see Table 2.4.2 where the concepts are listed and defined. Concept Description EVALUATION Evaluated/checked implementation. RESULTS The outcome of the evaluated implementation. SELF ASSESSMENT DOCUMENTS Result of the examination of the security management by the organization of the process itself. INTERNAL AUDIT Result of the examination of the security management by the internal EDP auditor. EXTERNAL AUDIT Result of the examination of the security management by the external EDP auditor. SECURITY INCIDENTS DOCUMENTS Results of evaluating security events which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service. Table 2.4.2: Concept and definition evaluation sub process Security management

Содержание

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

Because of organizational and IT infrastructure changes, security risks change over time, requiring revisions to the security section of service level agreements and security plans. Maintenance is based on the results of the Evaluation sub process and insight in the changing risks. These activities will produce proposals. The proposals either serve as inputs for the plan sub process and travel through the cycle or can be adopted as part of maintaining service level agreements. In both cases the proposals could lead to activities in the action plan. The actual changes are made by the Change Management process. +Table 2.5.1: (Sub) activities and descriptions Maintenance sub process ITIL Security Management Activities Sub Activities Descriptions Maintain Maintenance of Service level agreements This keeps the service level agreements in proper condition. The process ends with maintained service level agreements. Maintenance of operational level agreements This keeps the operational level agreements in proper condition. The process ends with maintained operational level agreements. Request for change to SLA and/or OLA Request for a change to the SLA and/or OLA is formulated. This process ends with a request for change. Reporting The implemented security policies process is documented in a specific way. This process ends with reports. Figure 2.5.1 is the process data diagram of the implementation sub process. This picture shows the integration of the meta process model (left) and the meta data model (right). The dotted arrows indicate which concepts are created or adjusted in the activities of the implementation phase. Figure 2.5.1: Process data model Maintenance sub process

The maintenance sub process starts with the maintenance of the service level agreements and the maintenance of the operational level agreements. After these activities take place (in no particular order) and there is a request for a change the request for change activity will take place and after the request for change activity is concluded the reporting activity starts. If there is no request for a change then the reporting activity will start directly after the first two activities. The concepts in the meta data model are created/ adjusted during the maintenance phase. For a list of the concepts and their definition take a look at table 2.5.2. +Table 2.5.2: Concept and definition Plan sub process Security management Concept Description MAINTENANCE DOCUMENTS Agreements kept in proper condition. MAINTAINED SERVICE LEVEL AGREEMENTS Service Level Agreements(security paragraph) kept in proper condition. MAINTAINED OPERATIONAL LEVEL AGREEMENTS Operational Level Agreements kept in proper condition. REQUEST FOR CHANGE Form, or screen, used to record details of a request for a change to the SLA/OLA. Table 2.5.2: Concept and definition Plan sub process Security management

Таблица 2.5.1: (Под)действия и описания

Подпроцесс обслуживания ITIL Управление безопасностью

Деятельность | Поддеятельность | Описание
---|---|---
Обслуживание | Поддержание соглашений об уровне обслуживания | Поддержание соглашений об уровне обслуживания в надлежащем состоянии. Процесс завершается поддержанными соглашениями об уровне обслуживания.
| Поддержание операционных соглашений об уровне обслуживания | Поддержание операционных соглашений об уровне обслуживания в надлежащем состоянии. Процесс завершается поддержанными операционными соглашениями об уровне обслуживания.
| Запрос на изменение SLA и/или OLA | Формулируется запрос на изменение SLA и/или OLA. Процесс завершается запросом на изменение.
Отчетность | | Процесс реализации политик безопасности документируется определенным образом. Процесс завершается составлением отчетов.

Рисунок 2.5.1 – диаграмма данных процесса подпроцесса реализации. На рисунке показана интеграция модели метапроцессов (слева) и модели метаданных (справа). Пунктирные стрелки указывают, какие концепции создаются или корректируются в ходе действий на этапе реализации.

Рисунок 2.5.1: Модель данных процесса Подпроцесс обслуживания

Подпроцесс обслуживания начинается с поддержания соглашений об уровне обслуживания и поддержания операционных соглашений об уровне обслуживания. После выполнения этих действий (в произвольном порядке) и поступления запроса на изменение, выполняется действие «Запрос на изменение», а после завершения действия «Запрос на изменение» начинается действие «Отчетность». Если запрос на изменение отсутствует, действие «Отчетность» начинается непосредственно после первых двух действий. Концепции в модели метаданных создаются/корректируются в ходе фазы обслуживания. Список концепций и их определения приведен в таблице 2.5.2.

Таблица 2.5.2: Понятие и определение

Подпроцесс планирования Управление безопасностью

Понятие | Описание
---|---
ОБСЛУЖИВАНИЕ | Соглашения поддерживаются в надлежащем состоянии.
ПОДДЕРЖАННЫЕ СОГЛАШЕНИЯ ОБ УРОВНЕ ОБСЛУЖИВАНИЯ | Соглашения об уровне обслуживания (раздел "безопасность") поддерживаются в надлежащем состоянии.
ПОДДЕРЖАННЫЕ ОПЕРАЦИОННЫЕ СОГЛАШЕНИЯ ОБ УРОВНЕ ОБСЛУЖИВАНИЯ | Операционные соглашения об уровне обслуживания поддерживаются в надлежащем состоянии.
ЗАПРОС НА ИЗМЕНЕНИЕ | Форма или экран, используемый для записи деталей запроса на изменение SLA/OLA.

Таблица 2.5.2: Понятие и определение

Полная модель данных процесса

Рисунок 2.6.1: Полная модель данных процесса "Управление безопасностью"