SP7: Ensure security

 

Process name: Ensure security - Part of: Supporting processes

Previous process: Manage projects

Next process: Ensure continuity

 

Process description

The security management process in YaSM (fig. 1) ensures the security of the service provider's range of services and aligns the security needs of the service provider with those of its customers. This includes ensuring that systems and data are protected from intrusion and only accessed by authorized parties.

Fig. 1: 'Ensure security':
YaSM security management process SP7.

Ensuring security starts with the compilation of a security risk register which lists the identified security risks and their properties, as well as suitable risk responses (security controls or other risk mitigation measures).

The YaSM processes provide a number of ways for the security manager to exert influence. Most importantly, the security manager will be involved in the service design and build stages to ensure the security of new or updated services. Once it has been established during service design which security controls and mechanisms are required for a new service, these can be put in place, notably

• Through the service build process, by adding suitable security features to the service infrastructure that is to be created or updated
• Through the security process, by updating security policies as well as security mechanisms and controls which are operated under the responsibility of the security manager.

The security manager is also involved in service or process improvement initiatives if security is affected.

If new security threats emerge or if the security controls need to be upgraded for other reasons, the security process is able to start security improvement initiatives on its own account. Such initiatives are managed through the security improvement plan.

Finally, the security manager will also ensure security by defining rules and providing information, for example in the form of underpinning security policies, incident and service request models, as well as security alerts.

Note: YaSM does not provide a detailed explanation of all aspects of security management, as there are dedicated and more detailed sources available (see, for example, ISO 27001). Rather, YaSM highlights the most important security management activities and describes the interfaces with other YaSM processes.

 

Compatibility: The YaSM security management process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, section 8.7), and it corresponds to the practices of 'ITIL 4 information security management' and 'ITIL 4 risk management'.

Sub-processes

YaSM's security management process has the following sub-processes:

SP7.1: Assess security risks

Process objective: To identify the security risks which need to be managed by the service provider, and to define appropriate risk responses.

SP7.2: Define security improvements

Process objective: To define the objectives of security improvement initiatives and the approach for their implementation. This includes creating business cases for the initiatives.

SP7.3: Start up security improvement initiatives

Process objective: To launch security improvement initiatives. This includes obtaining authorization by requesting a budget and submitting a request for change.

SP7.4: Implement security controls

Process objective: To implement, test and deploy new or improved security controls and mechanisms.

SP7.5: Operate the security controls

Process objective: To arrange adequate security training for the service provider's staff and customers, and to ensure regular maintenance and testing of the security mechanisms and controls.

SP7.6: Review the security controls

Process objective: To submit the security controls and mechanisms to regular reviews, in order to identify potentials for improvement to be addressed by security improvement initiatives.

Process outputs

This section lists the documents and records produced by 'security management'. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.

Budget request

A budget request is typically issued to obtain funding for setting up, improving or operating a service or process. An approved budget request means that the required financial resources have been allocated by the financial manager. [*]

Change record

A change record contains all details of a change, documenting the lifecycle of a single change. In its initial state, a change record describes a request for change (RFC) which is to be assessed and authorized prior to implementing the change. Further information is added as the change progresses through its lifecycle. [*]

Change status information

Current status information related to the implementation of a change. This information is sent to the change manager from the various processes that implement authorized changes. It is used by the change manager to keep the change records and the change schedule up-to-date.

CI record

Configuration information is maintained in CI records for all configuration items (CIs) under the control of the configuration manager. In this context, CIs can be of various types: Applications, systems and other infrastructure components are treated as CIs, but often also services, policies, project documentation, employees, suppliers, etc. Configuration information is stored in the configuration management system (CMS). [*]

Data for project plan update

Current information related to project progress and resource consumption. This information is sent from various service management processes to the project manager as input for project control.

Incident model

An incident model contains the pre-defined steps that should be taken for dealing with a particular type of incident. The aim of providing incident models is to ensure that recurring incidents are handled efficiently and effectively. [*]

Purchase request

A request to procure goods or services from an external supplier. Purchasing requests are typically sent to the supplier manager, for example if applications, systems or other infrastructure components are needed for setting up a new service, or if standard infrastructure components and consumables are required for service operation.

Register of security risks

The register of security risks is a tool used by the security manager to keep an overview of all security risks to be managed. The register of security risks also specifies the responses to the identified risks, in particular security controls and mechanisms to mitigate the risks. [*]

Request to assess compliance implications

A request to assess which compliance requirements are relevant for a new or changed service, typically issued during service design.

Request to assess continuity risks

A request to assess risks associated with critical events, typically issued during service design if new or changed service continuity arrangements are likely to be needed for a new or improved service.

Security alert

A security alert is typically issued by the security manager when outbreaks of security threats are foreseeable or already under way. Security alerts aim to ensure that users and staff are able to identify any attacks and take appropriate precautions.

Security improvement plan

Items in the security improvement plan are used by the security manager to record and manage security improvement initiatives throughout their lifecycle. Initiatives in the security improvement plan may aim to implement proactive measures to enhance security or to put mechanisms in place which allow responding effectively to any security breaches. [*]

Security operation manual

The security operation manual specifies the activities required for the operation of the security controls and mechanisms operated under the responsibility of the security manager. Some instructions related to the operation of particular security systems may be documented in separate technical manuals or 'standard operating procedures (SOPs)'. [*]

Security review report

A security review report records the details and findings from a security review. This report is an important input for the definition of security improvement initiatives. [*]

Service request model

Service request models contain the pre-defined steps that should be taken for dealing with a particular type of service request. The aim of providing service request models is to ensure that routinely occurring requests are handled efficiently and effectively. [*]

Suggested process modification

A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.

Suggested security improvement

A suggestion for improving service security. Suggestions for security improvements may originate from anywhere within the organization.

Suggested service modification

A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.

Test report

A test report provides a detailed account of testing activities. A test report is created for example during tests of new or changed service components, or during tests of security or service continuity mechanisms. [*]

Test script

A test script specifies a set of test cases including their expected outcomes. The nature of the test cases will vary depending on what is to be tested. [*]

Underpinning security policy

Underpinning security policies are specific policies complementing the main security policy by setting binding rules, for example for the use of systems and information or the use and delivery of services. [*]

 

---

Notes:

[*] "YaSM data objects" are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see example) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see example).

"Other objects" are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.

Process metrics

Process metrics are used, for example, to assess if the service management processes are running according to expectations.

For suggestions of suitable metrics, please refer to the list of metrics for the YaSM security process.

Roles and responsibilities

Process owner: Security manager

• The security manager is responsible for the service provider's and its customers' security. This includes responsibility for the security of information and data being processed by the service provider.

 

Responsibility matrix: "SP7: Ensure security"

YaSM role / sub-process		Compli. mgr.	Oper.	Proc. owner	Secur. mgr.	Serv. contin. mgr.	Serv. owner	Techn. domain expert
SP7.1	Assess security risks	-	-	R	AR	-	R	-
SP7.2	Define security improve­ments	R	-	-	AR	R	-	-
SP7.3	Start up security improvement initiatives	-	-	-	AR	-	-	-
SP7.4	Implement security controls	-	R	-	AR	-	-	R
SP7.5	Operate the security controls	-	R	-	AR	-	-	-
SP7.6	Review the security controls	-	-	-	AR	-	-	-

 

Notes

Is based on: The security management process from the YaSM Process Map.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

 

Process description  › Sub-processes  › Process outputs  › Metrics  › Roles