Information Security Management
Description/Summary
Information Security Management deals with the implementation and monitoring of a predefined security level for the IT environment. In particular, it addresses areas such confidentiality, integrity and availability. Risk analysis, as the starting point, helps to define the customer requirements on a security level. An internal, minimal security requirement is named IT basic protection. Additional security requirements of the customer are to be defined on an individual basis.
Objectives
To introduce and maintain a required level of security, as defined by law, contracts or other agreements.
Information Security Management contributes to an integrated Service Management approach by achieving the following activities:
- Identifying and defining the internal and external security requirements
- Planning of security procedures
- Creating a security chapter in the SLA and Service Description
- Managing the implementation of security actions
- Evaluating the security procedures and security measures
- Security Reporting
- Security Improvement
Roles & Functions
Security Management specific roles
Static Process Roles
- Security Process Owner
Initiator of the process, accountable for defining the process strategic goals and allocating all required process resources. See Continual Process Improvement Management for a detailed description of these activities.
- Security Process Manager (Security Manager)
IT Security Management Process is controlled by the Security Manager. The Security Manager can delegate tasks to specialized staff. Should it be necessary to use external staff, an approval of the budget by the responsible person is required.
- IT Security Management Team
Team in Security Management perform mandatory tasks for the Security Manager.
Dynamic Process Roles
- Security Auditor
Security Auditor is providing the verification of security policies, processes and tools. Auditor should be altering an external and internal resource to provide independent and reliable audit.
Service Specific Roles
Roles depending on the affected service are found in the Service Description. The Service Description, including the service specific roles, is delivered from the Service Portfolio Management.
- Service Expert/Service Specialist:
- Service Owner:
- Service User:
Customer Specific Roles
Roles depending on the affected customer(s) are found in the Service Level Agreement. The Service Level Agreement for the customer specific roles is maintained by theService Level Agreement Management.
- Customer(s)
- Customers of the affected service with a valid SLA
Information artifacts
Security Policy
The process depends on general security rules. Moreover, this process is responsible for the permanent improvement and adjustment of general security policies and rules.
Security Design Record
- Security Design ID
- Security Design Requester
- Security Design Description
- Security Design Agent
- Security Design Owner
- Service: The Service which has to be (re)designed
- Service Integrity
- Service Confidentiality
Security Transition Record
- Security Transaction ID
- Security Transition Requester
- Security Transition Description
- Security Transition Agent
- Security Transition Owner
- Service: Services affected by the Change
- Configuration Items: CI affected by the Change
Security Verification record
- Security Verification ID
- Security Verification Requester
- Security Verification Description
- Security Verification Agent
- Security Verification Owner
- Security Verification Auditor
- Service: Services affected by the Security Audit
- Configuration Items: CI affected by the Security Audit
- Customer: Customer affected by the Security Audit
- User: User affected by the Security Audit
- Expert/Specialists: Expert/Specialists affected by the Security Audit
Key Concepts
Availability
Information and the service must be accessible to authorised users.
Integrity
Information must not be modified by unauthorized users. Following levels of integrity are possible:
- 0: it can not be proven if integrity was violated
- 1: it can be proven if integrity was violated
- 2: it can be proved if integrity was violated and the violation can be reversed
Confidentiality
Information must not be accessible by unauthorized users. Following levels of confidentiality are possible:
- public: information is available for all
- confidential: information is available for authorised personnel only and assigned external partners
- confidential – for intern use only: information is available for authorised personnel only
- top secret: information is available for senior management only
The Confidentiality Levels can be expanded or adjusted.
Authentication
Verification of identity of a user or information.
Authorization
Methods and tools used to decide if user or information is allowed to have access other devices or sources of information.
Severity Breach Levels
Severity levels here indicate the importance of an optimization proposal or security incident. The following levels can be defined as:
- Critical
- The level „critical“ needs to be implemented, including changes, as soon as possible.
- High
- The level „high“ needs to be implemented, including changes, within next 2 days.
- Low
- The level „low“ needs to be implemented, including changes, within next 7 days.
Process
Critical Success Factors
Critical Success Factors (CSF) define a limited amount of factors which influence the success of a process. For Security Management, the following factors can be defined as CSF:
- Right dimension of security, by avoiding too strict or too lax security
- Management support for security issues
- Security awareness in the company
- Definition of responsibilities between security implementation and security control activities and roles
Security Manager must review the CSFs and must define and implement measures to fulfill the process success.
Security Policy
High Level Process Flow Chart
This chart illustrates the Security Policy Creation and Control
Performance Indicators (KPI)
- Number of changes to Security policy
- Number of awareness programs
Process Trigger
Event Trigger
- The process is is not time triggered
Time Trigger
- Security Policy is activated periodically
Process Specific Rules
- Each Change to the Security Policy has to be documented
- Each Change to the Security Policy has to be published
Process Activities
Security Policy Definition
Security Policy Definition is dealing with definition of
- Basic security rules collected in a Security Policy
Basic Security rules define the Security vision, organization and are business strategy aligned. Main orientation rule is the balance between high security standard for internal IT services, services provided and external supplied services and required services and good commercial “value for money” proposition.
Activity Specific Rules
- Security Manager is set to the person who is responsible for security process
- Security Process Owner Manager is set to the person who is accountable for security process
- The Security Policy is created or updated
- add new Rules
- modify existing rules
- delete unnecessary rules
- The Security Policy is signed by the Senior Management and published
Security Policy Controlling
Security Policy Implementation and Monitoring is responsible for the implementation, communication, monitoring and update of security rules and policies.
Activity Specific Rules
- Communicate Security Policy
- Check for new Security Threats
- trigger Security Policy update when necessary
- Assure that staff understands and the rules by auditing and teaching staff
Security Design Assistance
Sub process Design in Security Management is responsible for the initial planing or planning of optimizations of the security process. If a change proposal on security process is classified the change needs to be planned as well. This is performed by an expert out of the responsible expert group in coordination with a member of the IT security staff. This sub process is triggered by Service Design. After the activity is finished, the status needs to be changed to planned.
The Process owner is the Security Manager. The Process agent is an expert assigned by „Security Staff“.
High Level Process Flow Chart
This chart illustrates the Security Management Design process and its activities
Performance Indicators (KPI)
- Number of new Security Design Assistance Requests
- Number of „approved – successful“ and „approved – unsuccessful“ Security Design Assistance Requests
- Ratio of „approved – successful“ and „approved – unsuccessful“ Security Design Assistance Requests
Process Trigger
Event Trigger
- The process is initiated by the Change Management.
Time Trigger
- Security Design Assistance is not time triggered
Process Specific Rules
- Each Security Design assistance Request must be recorded
- The Security Design Agent has to document the request and result of the design request
- The Security Design Owner has to control the Agent
- The Security Design Agent has to coordinate his work with other Design Agents
- The Security Design Requester has to be informed
Process Activities
Design of Security Part in Service Design Package
Within this activity, the security section of the service design package is designed. This includes information on accessibility, security actions and measures, relevant passwords and policies etc.
Activity Specific Rules
- set the Security Design Owner to a member of the IT security Management Staff
- set the Security Design Agent to a member of the Service Expert or Specialist Group
- Design Security according to the Security Requirements and the Security Policy
- coordinate Security Design package with the activity „Service Design“ and other relevant Service Designer
- document in the Service Design package and fill out the Security Design Record
- go to control activity „designed^“
Approval of Security Design Package
With this activity, the Security Manager approves the Security Design Package.
- Security Design Package is finally neglected
- Approval of the Security Design Package is temporarily refused and returned to the security expert for the improvement or optimization
- Security Design Package is accepted.
Activity Specific Rules
- set the Security Design Agent to Security Manager
- Approval the Security Design Package and the documentation in the Security Design Record
- If approval is posit iv go to control activity „approved – successful“
- else
- go to control activity „new“ for a redesign of the Security Design Package
- or „approved – unsuccessful“ for final abortion
Security Transition Assistance
This activity, in cooperation with Change Management, supports the implementation and testing of security improvements by designing, testing, implementing and then testing the implementation again. These actions are headed by Change Management.
If a security improvement proposal is authorized and approved by Change Management, all action’s functional descriptions and implementation procedures, which are described in the improvement proposal need to be detailed, tested and approved in cooperation with the Change Management. Afterwords the implementation should be assisted to provide help in case emergency or implementation issues.
A final PIR, conducted together with Change Management also includes testing.
High Level Process Flow Chart
This chart illustrates the Security Transition Assistance process and its activities
Performance Indicators (KPI)
- Number of Security Transition Assistance Request
- throughput time (min/average/max) for a Transition Assistance Request until „assisted – closed“
Process Trigger
Event Trigger
- Process is triggered by different activities in the Change Management.
Time Trigger
- Security Transition Assistance is not time triggered
Process Specific Rules
- Each Security Transition Assistance Request must be recorded
- The Security Transition Agent has to document the request and result of the design request
- The Security Transition Owner has to control the Agent
- The Security Transition Agent has to coordinate his work with other Transition Agents
- The Security Transition Requester from the Change Management has to be updated
Process Activities
Creation Risk Analysis and Feasibility Study
If a Security Transition Assistance is requested by Change Management the following 2 documents need to be defined:
- Feasibility Study
- Risk Analysis
Following aspects need to be addressed within a Feasibility Study:
- Feasibility of proposal
- Risk of implementation
- Risk of neglecting proposal
- Costs
A Feasibility Study is based on high level planning and should not address detailed planning because of the possibility that the proposed change will not be accepted. Detailed planning of the Change is part of the activity „Build – Implement – Test – Assistance “ after the Change has been authorized.
A Feasibility Study is provided by an expert or specialist of the address service. Eventually additional requirements provided by other processes, such as Financial, Availability or Capacity Management will also need to be reviewed.
After the responsible expert finishes their contribution to the planning of the security actions, the status needs to be set on planned design package
Activity Specific Rules
- set the „Security Transition Owner“ to a member of the IT Security Management Staff
- set the „Security Transition Agent“ to a member of the Service Expert or Specialist Group
- Create a Security Feasibility Study & Risk Analysis according to the Change Requirements and the Security Policy
- coordinate Creation of the Security Feasibility Study & Risk Analysis package with others
- document in the Security Feasibility Study & Risk Analysis Document as well as in the Security Transition Record
- go to control activity „created^“
Build – Test – Implement – Assistance
If a security change is approved for implementation, Change Management will request assistance from Security Management, who in turn may request assistence from the sub-process Build, Test, Implement and Assistance.
This activity provides the following information:
- A detailed definition of implementation instructions
- A detailed definition of test procedures and documents
- Support during implementation
- Approval of the implementation
Within the change plan the order and time line of actions need to be described. Testing documentation must address the test design and ensure the effectiveness of the test.
The Test has to be executed before the live Change takes place and is split up into two main test areas:
- 1. Test of the implementation – „Does the provided document describe the right implementation actions in the right implementation order?“
- 2. Test the functionality of the new service in the test-system – „Does the system perform the functions defined in Change?“. This test is performed according to the defined testing documentation. The result has to be documented an the Change Management has to be informed.
Implementation activities are fulfilled and lead by Change Management. Security Management only assists and supports with regards to the security aspects and functions.
Activity Specific Rules
- support creation of the implementation plan including fallback plan
- support creation of the test plan
- support test of the implementation plan including fallback plan
- support implementation
- document activities and Test results
- coordinate work with Change Management
- go to control activity „assisted“
Evaluation and Closure Assistance
In coordination with the Post Implementation Review of the Change, Security Managment helps to test the implementation from the security point of view. In cases of a failed tests, the Change Management has to decide if the fallback plan has to be executed or the implementation can be accepted despite any issues in testing.
Activity Specific Rules
- support Post Implementation Review and tests
- consult Change Managment about Fallback Execution
- support fallback implementation if nessecary
- document Activities and Security Test results & Fallback Implementation
- go to control activity „assisted – closed“
Security Verification
This activity is performed by the Security Manager. The target of the activity is to verify, if implemented, that security optimization fulfills the planned results – Verification uses the „Four-Eye Principle“.
If actions do not provide the results planned, the status can be set to re-designed. Planning activity needs to be started again. If it is decided that a security improvement action is not approved, then the status should be set to cancelled. If the Security Management approved that decision, the status is being set to OK. In the perspective of Security Management, these actions are approved and can be implemented once the Change Management has authorized the actions.
High Level Process Flow Chart
This chart illustrates the Security Management Verification process and its activities
Performance Indicators (KPI)
- Number of security incidents per audit by breach level
- Number of external security audits
- Number of internal security audits
- Top Ten services with the most security incidents
Process Trigger
Event Trigger
- Any request for a Security Audit
- from any Process Manager or Process Owner
- from any Service Owner
- from Senior Management
- from Customer and Customer Owner (Account Manager)
Time Trigger
- Security Audits are often time triggered and processed on regular base. Regular Security Audits are defined in
- Security Policy
- the Process Description
- the Service Description
- Servie Level Agreements (SLA)
- Operational Level Agreements (OLA)
- Underpinning Contracts
Process Specific Rules
Process Activities
Planning of Verification Activities
This activity plans the audit activities. Issues to be addressed by the planning:
- Which services need to be audited regrading security issues?
This depends on the number of security incidents and the severity of security incidents per service as well as the importance of a service.
- What is the scope of the audit?
What is the extend of the audit: full audit or just the check of few indicators?
- Auditing method?
Audit to be fulfilled by checks, real life tests or just an questionnaire?
- How often is the audit needed?
This depends on the number of security incidents and the severity of security incidents per service as well as the importance of a service and how exposed a service is to external and internal threads.
- Who is performing the audits?
Auditors need to be alternated often to assure that the auditor is independent, not influenced by options or customer relationship and by the will to keep the auditing contract.
Result of this activity is a audit plan, that need to be communicated.
Activity Specific Rules
- set Security Verification Agent to member of IT Security Management Staff
- set Security Verification Owner to Security Manager
- set Security Verification Requester
- create Security Verification Description
- select Security Verification Auditor according to the Security Policy
- document Service affected by the Security Audit
- document Configuration Items affected by the Security Audit
- document Customer affected by the Security Audit
- document User affected by the Security Audit
- document Expert/Specialists affected by the Security Audit
- create audit plan
- go to control activity „planed“
Performing Verification Activities
Based on an audit plan, the audit is performed by the Security Verification Auditor
Activity Specific Rules
- set Security Verification Agent to Security Verification Auditor
- set Security Verification Owner to Security Manager
- documet result in Security Verification Record
- go to control activity „performed“
Review of Verification Results
Results of the audit need to be checked. If Security incidents occur these need to be classified in severity breach levels and handled by the Process Manager. In case of minor changes the Change Management is addressed, in case of major changes, the process is started with a redesign of new design of e Security Package.
Activity Specific Rules
- set Security Verification Agent to Security Verification Auditor
- evaluation & classification of each Security Incident
- trigger Incident, Problem or Change Management where necessary
- document result in Security Verification Record
- go to control activity „reviewed“