 | ||
ITIL security management (originally Information Technology Infrastructure Library) 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."
Contents
- Security management
- Control
- Plan
- Implementation
- Evaluation
- Maintenance
- Complete process data model
- Relations with other ITIL processes
- Example internal e mail policies
- References
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:
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.
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.
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.
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.
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.
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.
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
Evaluation
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.
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.
Table 2.4.2: Concept and definition evaluation sub-process Security management
Maintenance
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.
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
Complete process-data model
Figure 2.6.1: Complete process-data model Security Management process
Relations with other ITIL processes
The Security Management Process, as stated in the introduction, has relations with almost all other ITIL-processes. These processes are:
Within these processes activities concerning security are required. The concerning process and its process manager are responsible for these activities. However, Security Management gives indications to the concerning process on how to structure these activities.
Example: internal e-mail policies
Internal e-mail is subject to multiple security risks, requiring corresponding security plan and policies. In this example the ITIL security Management approach is used to implement e-mail policies.
The Security management team is formed and process guidelines are formulated and communicated to all employees and providers. These actions are carried out in the Control phase.
In the subsequent Planning phase, policies are formulated. Policies specific to e-mail security are formulated and added to service level agreements. At the end of this phase the entire plan is ready to be implemented.
Implementation is done according to the plan.
After implementation the policies are evaluated, either as self-assessments, or via internal or external auditors.
In the maintenance phase the e-policies are adjusted based on the evaluation. Needed changes are processed via Requests for Chang.