ITIL security management describes the structured fitting of security into an organization. ITIL security management is based on the ISO 27001 standard. "ISO/IEC 27001:2005 covers all types of organizations (e.g. commercial enterprises, government agencies, not-for profit organizations). ISO/IEC 27001:2005 specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented Information Security Management System within the context of the organization's overall business risks. It specifies requirements for the implementation of security controls customized to the needs of individual organizations or parts thereof. ISO/IEC 27001:2005 is designed to ensure the selection of adequate and proportionate security controls that protect information assets and give confidence to interested parties."

A basic concept of security management is information security. The primary goal of information security is to control access to information. The value of the information is what must be protected. These values include confidentiality, integrity and availability. Inferred aspects are privacy, anonymity and verifiability.

The goal of security management comes in two parts:

Security requirements defined in service level agreements (SLA) and other external requirements that are specified in underpinning contracts, legislation and possible internal or external imposed policies. Basic security that guarantees management continuity. This is necessary to achieve simplified service-level management for information security.

SLAs define security requirements, along with legislation (if applicable) and other contracts. These requirements can act as key performance indicators (KPIs) that can be used for process management and for interpreting the results of the security management process.

The security management process relates to other ITIL-processes. However, in this particular section the most obvious relations are the relations to the service level management, incident management and change management processes.

Security management

Security management is a continuous process that can be compared to W. Edwards Deming's Quality Circle (Plan, Do, Check, Act).

The inputs are requirements from clients. The requirements are translated into security services and security metrics. Both the client and the plan sub-process affect the SLA. The SLA is an input for both the client and the process. The provider develops security plans for the organization. These plans contain policies and operational level agreements. The security plans (Plan) are then implemented (Do) and the implementation is then evaluated (Check). After the evaluation, the plans and the plan implementation are maintained (Act).

The activities, results/products and the process are documented. External reports are written and sent to the clients. The clients are then able to adapt their requirements based on the information received through the reports. Furthermore, the service provider can adjust their plan or the implementation based on their findings in order to satisfy all the requirements stated in the SLA (including new requirements).

Control

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

The CONTROL rectangle with a white shadow is an open complex concept. This means that the Control rectangle consists of a collection of (sub) concepts.

Figure 2.1.3 is the process data model of the control sub-process. It shows the integration of the two models. The dotted arrows indicate the concepts that are created or adjusted in the corresponding activities.

Figure 2.1.3: Process-data model control sub-process

Plan

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

Implementation

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.