The Standard

Third party integration model

The description of the ESARIS Third Party Integration Model is organized along the five elements shown in Figure 2.

• Organizing security measures,
• Selecting security measures,
• Agreeing security measures,
• Organizing interaction of participants.

Organizing security measures

The ESARIS Security Taxonomy shown in the middle of Figure 3 is used to organize all security measures. This section only summarizes information from Release 1 which is important for managing supplier networks.[2]

The ESARIS Security Taxonomy supports the decomposition of the IT service and security standards/measures. The Taxonomy has several characteristics. There are three characteristics which are most important in our context: (1) The Taxonomy and the Hierarchy of Security Standards support the modular definition of security. Modularity is required since the division of labor in the IT industry shall be taken into account and supported. The division of labor varies and is different for various businesses and depends on the parties involved. (2) The Taxonomy shall be used as a means to manage information security in a supplier-customer relationship, i.e., between parties in a supplier network and even between different specialized organizations of a large organization. The Taxonomy is introduced in order to organize possibly hundreds of security measures in a way that they can easily be assigned to a supplier. The term “supplier” refers to a department or team in a larger corporation and to a company acting as a supplier in a supplier network. (3) Each area in the Taxonomy represents a typical service or component (deliverable for the next in the supply chain) or a collection thereof that suit each other. The separation reflects technical aspects of IT (“stack” and architecture) as well as the organization of the IT service management services (in development, integration and operations; that is, ITIL in case of this Taxonomy).

Figure 3: Supplier-network management and division of labor

Figure 3 shows how the ESARIS Security Taxonomy comes into play. (1) It helps to understand and to consider all possible security aspects including technical and procedural ones. The IT service provider requires this comprehensive view when combining products and services to a composite IT service and to verify if necessary security requirements from the market are met. (2) The ESARIS Security Taxonomy helps to identify those security aspects and measures which are relevant for the product or service from the third party. In the example, supplier 1 provides workplace and LAN technology. The relevant security measures are easy to identify if the functions and services are clear which are provided by the third party product. The other example shows that supplier 2 provides computing and data center technology. (3) The IT service provider combines the third party products with his own products/services. The composite IT service must meet all relevant security requirements.

Selecting security measures: Provider Scope of Control

Provider Scope of Control describes a method for selecting the right and relevant information for a customer, an individual service or a specific deal. The principle is shown in Figure 4. It works with every set of security standards organized along the ESARIS Security Taxonomy [3] in which all security measures are specified according rules.

The process of selecting the relevant security measures comprises the following steps:

• Step A yields areas with security measures if hardware or software is delivered: The process starts with selecting the technological elements and the related ICT Security Standards that are associated with the delivered IT service. The IT elements are identified by inspecting the offering or IT service being delivered or planned to be delivered to the consuming party. In this step, the focus is on IT services and their functionality. The functionality and technology behind the IT service or product determine the relevant areas from the lower half of the ESARIS Security Taxonomy. Refer to A in the figure.
• Step B yields areas with security measures if the supplier shall observe procedural guidelines during development, implementation or operations: Especially IT service management activities during operations and the division of labor between the consuming party and the supplying party are considered, and specifically, services are selected with the related ICT Security Standards. The associated IT management services are identified by inspecting the offering or service being delivered or planned to be delivered. In this step, the focus is on operations and maintenance and the division of labor with respect to IT service management activities.[4] Refer to B in the figure.

The following two steps remove or modify individual security measures which were selected in the previous steps. (It may also happen that single security measures are added.)

• Specific responsibilities are checked which provides additional filters. This comprises checking parameters such as ownership of equipment. This means that it is analyzed if the supplying party is actually responsible for the corresponding security elements. Similarly, activities and whole processes or process chains are inspected. The consideration of the service model and of the whole process landscape may provide details that result in removal or addition of security measures. The main sources for this selection process are statements of work (SoW) and product or service specifications. Refer to C in the figure.
• A further step may be necessary in order to take contractual details into account. The contract may e.g. include or exclude specific services and define further rules that determine the selection of standards or of security measures within these standards. Rights, warranty and the like may result in removal or addition of security measures. Constraints for their application may also be defined. The main sources for this selection or adjustment are contractual conditions and practices. Refer to D in the figure

Figure 4: Provider Scope of Control

Now the security measures are known which are relevant for the IT service or product. The next step is to bring them into a form that can be agreed between the two parties.

Agreeing security measures: Product Requirement Document (PRD)

Role

The consuming party and the supplying party must agree upon security when the customer purchases an IT service or product from the supplier. There are many ways for coming to such an agreement: The supplying party can specify the security characteristics of the IT service or product whereas the consuming party takes this as the basis for its buying decision. In more complex environments, both parties may influence the agreement. In case of a traditional IT outsourcing situation, it is up to the supplying party to primarily meet the security requirements of the consuming party and to implement the necessary security measures. The details are not important here.

The Product Requirement Document (PRD) is considered as the result of such negotiations which primarily specifies the security characteristics of the IT service or product regardless of whom has defined what part of it. The PRD is required in any case. The supplying party requires a specification in order to know what to implement/deliver. The consuming party requires a specification in order to know what he has to add in terms of security and what he can promise in terms of security to the next in the supply chain.

Content

The minimum content of such a Product Requirement Document (PRD) comprises:

• Description of IT service or product including
  • functionality and
  • related IT service management activities
    (similar as in IT service catalogs or product fact sheets).
• Identification of relevant security measures:
  • areas (and subareas) from the ESARIS Security Taxonomy,
  • detailed security measures on the level of detail of the ESARIS Orchestration Layer, (refer to the definition in Release 1 and to below).
• Assignment of responsibility for each security measure
  • to the supplying party (deliverable),
  • to the consuming party (duty to cooperate),
  • to both (division of labor and mode of cooperation needs to be specified).
• Guidance required by the consuming party (for administrators or privileged users as well as for other users) plus other constraints for the use (if any).
• Role and use of this product requirement document.

A PRD can also be used to document if a security measure is met, partly met, not met or if compensating measures are put in place.

Level of detail

The level of detail is important and needs to be defined in advance. If the level of detail is low (security measures are general), the supplying party has much freedom but the consuming party may be provided with too little information for its own risk management and for promising security features to the next party in the supply chain. If the level of detail is high (security measures are detailed), the supplying party has little freedom for the implementation, technical progress requires updating the contract with the PRD, and a PRD cannot be used for products, components and service from different sources. These examples clearly show that it is necessary and advantageous to define a level of detail or abstraction for the definition of security measures in a PRD.

The description of the security measures should meet the requirements defined for the Orchestration Layer. These requirements were the basis for the development of the ESARIS Security Taxonomy.[5] The requirements are: Security measures are expressed with different level of detail. Each one is necessary for serving its purpose. That’s why the Hierarchy of Security Standards should be maintained. One level in the “middle” of this hierarchy is called the Orchestration Layer and organized along the ESARIS Security Taxonomy. The security measures in this level of the hierarchy shall:

• respond to customers’ questions and concerns and provide clear and understandable answers,
• provide directions / guidance to the supplying party (company or department) for the implementation of security measures
  • in a way that is concrete enough to avoid errors,
  • but flexible enough to allow for technical progress and improvements, also regarding security,
  • allow the implementation and maintenance in accordance with the supplying company’s internal organization, processes and practices (such as the organization into different specialized production departments),
• be suitable for any ICT service designed for being delivered to a user organization (end of the supply chain) and thereby align with the service portfolio offering of a company supplying such a market,
• be comprehensive and complete as a set on secure ICT service provisioning.

Sources for defining such security measures include numerous ISO standards[6] and best practice catalogs.[7] The methodology described in this paper does not prescribe any of those. It only defines an appropriate level of detail or abstraction and it proposes to organize the security measures along the ESARIS Security Taxonomy.

Organizing interaction of participants: Systems Acquisition and Contracting (SAC)

There is one area in the ESARIS Security Taxonomy called “Systems Acquisition and Contracting” which is defined as follows (refer to Release 1):

Service Management		Life-cycle issues and general aspects of operations security
IT Security Standard	Abbr.	IT components and major areas
Systems Acquisition and Contracting	SAC	Choosing the right supplier is critical when purchasing IT systems and components (or services) that are reliable, secure, and so forth. Properties and other characteristics, the possibility for making corrections and the process for achieving them are all examples of crucial areas that need to be stipulated in a contract. Otherwise, difficulties may arise on having these operations conducted.

The ICT Security Standard – Systems Acquisition and Contracting (SAC) defines security measures for the consuming party. This covers own activities as well as the interaction between the consuming and the supplying party. The standard is used whenever products and services are purchased or otherwise obtained from any third party with the goal to use them to provide IT services for customers.

• The security measures described in this standard are independent from the service, system or product being procured. They comprise
  • Preparatory, continuous activities such as market research that includes investigations of demands, technologies, products, and vendors,
  • Activities of supplier management which help to evaluate, select and develop vendors. The latter may include partner programs set-up to develop and intensify the co-operation between the consuming party and its vendors in order to improve the gain from such a relationship,
  • Activities around contracting which includes the preparatory tasks as well as the initiation and the conclusion of contracts. The business relationship is maintained through its life-cycle here,
  • Activities of quality inspection, in particular in the form of acceptance testing.

Refer to A in Figure 5.

Figure 5: Systems Acquisition and Contracting (SAC) and the PRD

The details and the actual approach in the ICT Security Standard – Systems Acquisition and Contracting (SAC) may be company specific. This means that the content varies between IT companies. However, it is expected that such a standard defines the necessity to define a Product requirement Document (PRD) and its role and use. This is depicted in the following.

The security measure B that demands using a PRD is denoted as SAC‑QST in Figure 5. The Product Requirement Document (PRD) contains the security measures which are relevant for the IT service or product purchased by the consuming party (and provided by the supplying party). The security measures are defined in other ICT Security Standards C organized along the ESARIS Security Taxonomy. As mentioned above, it is not recommended to use material from lower levels D (implementation layer). The relevant areas from the ESARIS Security Taxonomy E and from them the relevant security measures F are selected depending on the provided functions and services.

In this way, the Product Requirements Document (PRD) is built. It states the functions and services (and actions) covered by the product, component or service being provided. See Figure 5. More important with respect to security, it states the security measures selected using the method described.

Note that the security standard (called SAC in the Figure 5) shall also define the necessity of performing other activities such as market analysis, management of procurement and acceptance testing. The use of a Product Requirements Document (PRD) is only one Element.

[2] ESARIS Security Taxonomy – Synopsis, Scope and Content; Zero Outage Industry Standard, Release 1 about Security, February 2017, zero-outage.com/security [2] [3] ESARIS Security Taxonomy – Synopsis, Scope and Content; Zero Outage Industry Standard, Release 1 about Security, February 2017, zero-outage.com/security [2] [4] E.g. see ISO/IEC 20000 – Information technology – Service management – Part 1: Service management system requirements, Part 2: Guidance on the application of service management systems [5] [5] Eberhard von Faber and Wolfgang Behnsen: Secure ICT Service Provisioning for Cloud, Mobile and Beyond, ESARIS: The Answer to the Demands of Industrialized IT Production Balancing Between Buyers and Providers, 2017, ISBN- 978-3-658-16481-2 [1] [6] E.g. ISO/IEC 27002 – Information technology – Security techniques – Code of practice for information security management [3] [7] E.g. The Standard of Good Practice for Information Security; Information Security Forum, 2016 [4]