IBM Replication

IBM Global Technology Services
Infrastructure Services
Middleware and Database Build
Procedure
Document Owner: Maurizio Biffa
Author: Barb Neale
Revision Date: 30 June 2017
Effective Date: 01 November 2017

Revision 1.0 Middleware and Database Build Procedure
Effective Date: 2017-Nov-01 Asset ID: CDFF230D-AD4B-CD37-3E36-89FA4C0B6184
Table of Contents
1 Document Control ............................................................................................................................... 3
1.1 Summary of Changes ................................................................................................................... 3
1.2 Document Approvers .................................................................................................................... 3
1.3 Document Review Plans ............................................................................................................... 3
1.4 How to Find the Latest Revision of this Document ....................................................................... 3
1.5 Document Distribution and Notification ......................................................................................... 3
2 Description........................................................................................................................................... 4
3 Scope .................................................................................................................................................... 4
3.1 Environment and Audience. .......................................................................................................... 5
4 Details ................................................................................................................................................... 6
4.1 GSDCat (Delivery Catalog). .......................................................................................................... 6
4.2 Controls ......................................................................................................................................... 6
4.3 Workflow........................................................................................................................................ 8
4.4 Build Procedure Workflow ............................................................................................................. 9
4.5 Build Procedure Narrative ........................................................................................................... 10
5 Business Rules ................................................................................................................................. 17
5.1 Policies ........................................................................................................................................ 17
5.2 Control Points .............................................................................................................................. 17
5.3 Key Metrics.................................................................................................................................. 18
6 Related Assets................................................................................................................................... 19
6.1 Related Processes or Service Flows .......................................................................................... 19
6.2 Referenced Procedures .............................................................................................................. 19
6.3 Referenced Supporting Documents and Work Instructions ........................................................ 19
7 Appendix ............................................................................................................................................ 20
7.1 Screenshots ................................................................................................................................ 20
7.2 Other Details ............................................................................................................................... 20
7.3 Glossary ...................................................................................................................................... 20
End of Document ...................................................................................................................................... 20
© IBM Corporation, 2017 Page 2 of 20

1 Document Control
1.1 Summary of Changes
Revision
Number Revision Date Author or Editor Nature of Change
1.0 Barb Neale Initial Release
1.2 Document Approvers

Document approval is maintained in the repository and can be found at:
https://www-950.ibm.com/ram/oslc/assets/CDFF230D-AD4B-CD37-3E36-89FA4C0B6184/1.0
Title or Role Approver Name
Configuration Item Build & Decommission Maurizio Biffa

Global Process Owner
Configuration Item Build & Decommission – Catherine Solarski
Process Security Architect
Configuration Item Build & Decommission – Subodh Karpe
Measurements & Compliance Focal
Middleware and Database Service Owner Marcos Cimmino
1.3 Document Review Plans

Necessary reviews and updates to this document are defined below:
 According to a regularly scheduled review cycle
 As required to correct or enhance information content
1.4 How to Find the Latest Revision of this Document

The latest revision of this document may be obtained from pRAM:
https://www-950.ibm.com/ram/oslc/assets/CDFF230D-AD4B-CD37-3E36-89FA4C0B6184/1.0
1.5 Document Distribution and Notification

 Printed copies are for reference only and are not controlled.
 The user is responsible to work only from the current document revision.

2 Description
This procedure provides the required steps for building (installing) middleware and database products in
accordance with IBM and client requirements.
This procedure is called from Server Build & Decommission or Mainframe Build & Decommission Service
Flows when middleware or database products are being installed along with an operating system; or can
be used as a standalone procedure when a middleware or database product is being installed in isolation
(i.e. on an existing system).
The business objectives of the procedure are to:
 Provide a consistent approach that ensures configuration items under GTS Infrastructure
Services management are built according to client and IBM requirements.
 Establish effective and appropriate controls over configuration items being entered into
production by GTS Infrastructure Services.
 Provide a means for retaining evidence generated during build in support of compliance
requirements.
3 Scope
The Middleware and Database Build Procedure applies to configuration items where IBM is responsible
for maintaining security controls on the configuration item in accordance with client requirements.
The Middleware and Database Build Procedure is further defined by the following inclusions and
exclusions, and applies in the specified environment and has the intended audience as specified below:
 Middleware and Database products include all products supported by the Middleware and
Database Service Area teams within GTS Infrastructure Services, and specifically exclude tooling
products typically used in the monitoring or management of systems. Products supported by the
Middleware and Database Service Area teams include the following categories of products:
o Big Data Analytics
o Integrated Systems and Appliances
o Distributed Database Products
o Mainframe Database Products and DB/DC
o Application Integration Middleware
o Business Applications Services Middleware
o Email & Collaboration
o Mobile Enterprise Services
Note: Product listings can be found https://w3-connections.ibm.com/wikis/home?lang=en-
us#!/wiki/Wd533af36fa72_4fa7_b17c_8696d9232fcd/page/Service%20Components but are not
limited to these products.
 This procedure provides the primary guidance for execution teams. However, the customer
security policy may document additional requirements and specific contractual obligations.
 Consult governing policy and/or customer requirements from Client Management for
consideration of local regulatory and customer specific requirements on privacy restrictions
including, additional approval requirements for access to sensitive personal information (SPI) and

for obtaining required credentials, such as certifications and/or security clearance, on-boarding
restrictions, access restrictions, etc.
 Configuration items not under GTS Infrastructure Services managed services control are not
covered by this procedure. This includes situations where GTS Infrastructure Services teams are
building configuration items for handover to a client where no ongoing management by GTS IS in
steady state will occur. These situations are handled as projects and will be governed by the
client requirements for completion.
 End user configuration items (e.g. personal computers and mobile devices) are not included in
the scope of this procedure.
3.1 Environment and Audience.

Attributes Details
Environment This procedure is applicable to any GTS Infrastructure Services Delivery

organization and applies to all configuration items where GTS Infrastructure
Services teams are responsible for maintaining the security settings.
The procedure is only applicable for Infrastructure Services Delivery accounts in
steady-state (i.e. not applicable for new logo accounts in Transition/Transformation)
where IBM team is responsible to manage the device/service under the client's
security policy and under the client's contract.
System Applies to Middleware & Database products supported by the Middleware and
Database Service Area teams, as defined above.

4 Details
4.1 GSDCat (Delivery Catalog).
Activity Key Not Applicable
Sub-Activity Key Not Applicable
4.2 Controls
Attributes Details
Inputs 1. Build Request from Account Authorized Requester and corresponding change
record following change management process
2. Supporting Account Information
 Customer Security Policy
Task(s) Perform a build of a Middleware or Database Product
Role(s) Account Authorized Requester:

Role is responsible for the specific contract and agreement with the client and is
authorized to request the build of configuration items for the specific account they
support. This individual represents the account team throughout the build activities
and will be engaged as such to support successful completion of the build
requirements where account team or client input or action is required.
Specific responsibilities include:
 Performs:
◦ Submission of Build Request
◦ Engages Support Teams to Prepare for Steady State
◦ Acts on behalf of Account Team throughout the Procedure
Middleware/Database Administrator:
This role is responsible for performing the steps required to build or decommission
a middleware or database product in accordance with client and IBM requirements.
 Performs:
◦ Pre-Build Review
◦ The technical steps required to build or decommission a middleware or
database product, including triggering and execution of interdependent
processes used in the course of the build or decommission activity.
 Responsible For:
◦ Build of a middleware or database product in accordance with client and

IBM requirements
◦ Decommission of a middleware or database product in accordance with
client and IBM requirements
◦ Creation of artifacts generated in the course of build or decommission to
evidence compliance with client and IBM requirements.
Account Security Focal
Role is responsible for execution of Risk & Compliance owned global processes
triggered in support of a build or decommission. This role represents a functional
part of the organization and could be filled by multiple individuals based on the
roles and responsibilities of the respective global processes being followed.
 Drives the evaluation of whether a Technical Specification is required when
one is not available for the configuration item being built, and if required,
drives the creation of the Technical Specification and corresponding update
to the Customer Security Document.
 Drives the IT Risk Management process, when determined necessary, to
assess risk related to the use of unsupported hardware or software for new
builds.
 Creation of new Technical Specifications and Customer Security Policy

updates
 Documented Risks, including Customer Acceptance

CAR Coordinator: An Account level role responsible for
 Creating and maintaining CAR Profiles (templates) for an account. The
Coordinator works with the security SMEs and Account Team to define the
profiles.
 Providing CAR Request procedure and tool first level support to resources
supporting the Account
 Single point of contact for DPE on management issues related to CAR.
 Responsible for account level reporting of global and local metrics.
The CAR Coordinator must be aligned with an account and managed by the
Account Team.
Skills Not Applicable
Complexity Not Applicable

Segmentation

4.3 Workflow
Activities (Tasks, Steps) Events (Start, End, Connectors)
Notates the start of a workflow

Notates activities
Activity
and tasks
Notates intermediate events
including on-page references
Activity with Notates an activity with Notates the end of a workflow

Task Flow associated task flow
Notates a call FROM an off-page
Notates an activity or workflow which does not return
Activity with task with an associated Notates a call TO an off-page
Business Rule business rule – KPI, workflow which does not return
control point, or policy
Notates a call to an
external workflow, which Sequence
Call Activity
executes, then returns Lines
and continues to the
next activity Notate the execution
order of activities
Gateway (Decision Box)
Splits the flow and Swimlane

follows only one of
Notates responsibility
Role
two or three paths

for activities and tasks

4.4 Build Procedure Workflow

Middleware & Database Build Procedure
Procedure Work Flow
Authorized
Requester
15.0
Account
1.0 6.0 14.0 16.0

Request Removal of 17.0
Submit Manage Engage Support Request
Start Access for Build Team & Build End
Build Completion of Pre- Teams to Prepare Update to
Shared ID Ownership Closure
Request Requisite Changes for Steady State Configuration Item
Change
Administrator
Middleware /
Database
5.0 7.0 8.0 13.0

2.0 3.0
Submit Request Install Software & Request 10.0 11.0 12.0 Inform Account
Perform Engage
for Pre-Requisites Perform Middleware / Registration in Validate / Achieve Initiate Initial Identity & Access Authorized
Pre-Build Account
to Account Authorized Database IBM Management Code Currency Compliance Management Requester of
Review Security Focal
Requester for Handling Configuration Systems Validation System Status
Account Security
4.0
Focal
Handle Security
Policy Pre-Build
Requirements
CAR Performer
9.0
Create Configuration
Item Artifact Repository
(CAR) Request

4.5 Build Procedure Narrative

Pr Job Role Se Prd Instructions
ID q
1.0 Account Authorized 1 Submit Build Request

Requester
The Build task flow is triggered when an individual
authorized to request the build (install) of a new
middleware or database product for an account submits a
request to the relevant support team following appropriate
methods for the account and type of configuration item.
Build requests are typically the result of a Request for
Service (RFS) managed at the account level. As part of
fulfilling an RFS, build requests will be initiated via change
management processes. A build request must be
documented using appropriate change management
processes so that an approved change ticket exists that
corresponds to the build.
There are a number of pre-requisites and/or dependencies
prior to a support team being able to begin the logical build
of a system (i.e. design, licensing, physical build). It is
expected that these requirements are managed by the
Account Authorized Requestor (on behalf of the account)
as part of the RFS or other relevant process.
2.0 Middleware/Database 2 1.0 Perform Pre-Build Review

Administrator
The objective of the Pre-Build Review is to evaluate if there
is additional work that must be done before the
Middleware/Database build can begin.
There are three items that must be evaluated that may
require the support of an Account Security Focal:
1. If a Technical Specification has not yet been
created to provide the client’s documented security
setting requirements. (Related CAR-A Question
#1)
2. If unsupported hardware or software is being asked
to be included in the build. (Related CAR-A
Question #89)
3. If the build request is not aligned with customer
policy and a security exception is required.
(Related CAR-A Question #1)
If any of the situations above exist, an Account Security

Focal must be engaged for support prior to the build
occurring.
Additionally, if the middleware/database product is being
installed on an existing system (i.e. standalone request),

the Middleware/Database Administrator must determine if

additional technical changes are required (e.g. patching at
the operating system level) prior to the installation of the
middleware/database product.
The following pre-requisites should be considered:
 OS patched to necessary level
 Storage – available and correct type
 Required Backup & Restore agents installed
 Middleware/Database Administrator has required

logical access to perform installation and configuration
3.0 Middleware/Database 3 2.0 Engage Account Security Focal (optional, if required)

Administrator
The Middleware/Database Administrator must engage the
appropriate Account Security Focal if determined required
during the pre-build validation.
4.0 Account Security 4 3.0 Handle Security Policy Pre-Build Requirements

Focal (optional, if required)
The Account Security Focal performs the following steps,

as required, to handle the Security Policy pre-build
requirements.
 Determine if a technical specification for the
configuration item being built will be created OR if one
is not required. This determination must be made
before the build can proceed.
 Evaluate the risk of building a configuration item with
unsupported versions of software and/or hardware.
 If the middleware/database build request will result in
a build that does not comply with the customer
security policy, determine if a security exception is
required.
5.0 Middleware/Database 3 2.0 Submit Request for Pre-Requisites to Account

Administrator Authorized Requester for Handling (optional, if
required)
If changes are required to the existing system (e.g.

operating system, storage or network requirements) in
order to support the middleware or database installation,
the changes must be requested to the Account Authorized
Requester for handling.
6.0 Account Authorized 4 5.0 Manage Completion of Pre-Requisite Changes

Requester (optional, if required)
Any changes required to the existing system (e.g. operating
system, storage or network requirements) in order to
support the middleware or database installation, must be

submitted via normal Change Management process prior to

the middleware/database product installation beginning.
7.0 Middleware/Database 5 3.0, Install Software & Perform Middleware/Database

Administrator 5.0 Configuration
The objective of this step is to install the required software
product and/or configure the configuration item according
to the appropriate specifications for the configuration item
and account.
Any agents or tools that are required to be installed in order
to manage the configuration item will also be completed
during this step.
This activity may require the involvement of several
different technical teams depending on the software
components that must be installed and configured. This
step is not complete until all required system components
have been installed and configured according to client and
IBM requirements.
Note: When installing software, ensure you are only
installing products with approved licenses (see Software
Licensing During Build Policy).
NOTE: Steps 7.0, 8.0 & 9.0 can all happen in parallel. The
only dependency is that the install date is required to be
known when opening a CAR Request (step 9.0).
Policies
 Use of Cloning During Configuration Item Build
 Software Licensing During Build
8.0 Middleware/Database 5 3.0, Request Registration in IBM Management Systems

Administrator 5.0
The objective of this step is to ensure all new configuration
items are registered to the required IBM Management
Systems used by the account.
 Invoke Security Inventory Management to request

adding the configuration item being built to the
Security Inventory. Required details to support the
request should be provided from the Build
Request. Follow account procedures for
requesting the addition to Security Inventory.
known when opening a CAR Request (step 9.0).
Related CAR-A Question #116

Policies
 Scope Alignment Between Security Inventory and
Configuration Item Build & Decommission Global
Processes
Controls & Measurements

 CP-MD-4 – Inventory Registration
9.0 CAR Performer 5 3.0, Create Configuration Item Artifact Repository (CAR)
5.0 Request
The objective of this step is to create a request in the CAR
tool in order to store artifacts from the build activity for the
purposes of evidencing compliance.
Invoke Configuration Item Artifact Repository Request
Procedure.
known when opening a CAR Request.

 CP-MD-9 – CAR Request Record
10.0 Middleware/Database 6 7.0 Validate/Achieve Code Currency

Administrator
The objective of this step is to ensure the configuration item
meets the required currency level for the particular
platform. This includes both security and non-security
related code, firmware or patches, depending on the
configuration item being built.
Security Patches/Code: Invoke Security Patch
Management – CIB&D Invoked Initial Patching Procedure
to bring the configuration item to the required level for
security patches. Build Request details are used as input
to this procedure to determine the required currency level.
Non-Security Patches/Code: Once security
patches/firmware are applied, any outstanding non-security
related patches/firmware must be applied to meet the
requirements as defined in the build request.

 CP-MD-2 – Code Currency
11.0 Middleware/Database 7 10.0 Initiate Initial Compliance Validation

Administrator
The objective of this step is to initiate an Initial Compliance
Validation against the full technical specification (baseline
and health check settings).
Invoke Security Management – Global Security Health
Check – Initial Compliance Validation (CIB&D Invoked)
Procedure to perform the Initial Compliance Validation.
The Middleware/Database Administrator acts as the Build
Team (BT) in the Initial Compliance Validation procedure of
the Security Management/Global Security Health Check
Process.


 CP-MD-1 – Initial Compliance Validation
12.0 Middleware/Database 8 11.0 Identity & Access Management

Administrator
The objective of this step is for the build administrator to
perform actions required in preparation for handing the
configuration item over to the team that will provide ID
administration secondary controls support during steady
state.
1. Register (or request registration of) all of the Shared
User IDs and Passwords of Last Resort for this
configuration item in the authorized shared ID
inventory and password management tool (e.g. UAT,
ITIM, ISIM, Cyberark). (Related CAR-A Question
#144). Global IAM Process/Global IAM Primary
Controls Modify User ID or Access Procedure is
invoked by the Build Administrator OR the IAM team
as a result of receiving the request from the Build
Administrator.
2. Change all of the default passwords set for this
device as directed by the platform technical
specification (Related CAR-A Questions #121).
Governing Security Policy should be referenced for
guidelines on password requirements.
3. Ensure all IDs are properly labelled to allow owner
identification, where technically feasible.
4. Establish/grant access necessary (e.g. for the IAM
organization) for ID administration to be performed
during steady state.
5. Where required, send the MEF extraction file(s)
containing local IDs, along with valid authorizations
for any IDs to the Steady State team responsible for
ID administration secondary controls. (Related CAR-
A Questions #19, 195, 196).

 CP-MD-3 – ID Management
 CP-MD-7 – Shared IDs
 CP-MD-8 – Default Passwords
13.0 Middleware/Database 9 12.0 Inform Account Authorized Requester of System

Administrator Status
At this point, all required steps to be performed by the
Middleware/Database Administrator are complete. Once
the Middleware/Database Administrator confirms that the
configuration item has been built according to the build
request, the Middleware/Database Administrator informs
the Account Authorized Requester of the system status so
that the required steady state support teams can take the
necessary actions to establish their support.

14.0 Account Authorized 10 13.0 Engage Support Teams to Prepare for Steady State
Requester
Once the required software, agents and tooling are
installed on the configuration item, the engagement of
steady state support teams to activate support must be
performed. Examples of steady state support teams
include Monitoring and Backup & Restore teams.
The Account Authorized Requester will take the required

actions to engage the appropriate support teams for the
account. The Middleware/Database Administrator will
provide support, as requested, if there are technical issues
with access or communication to the configuration item.
15.0 Account Authorized 11 14.0 Request Removal of Access for Build Team & Shared
Requester ID Ownership Change (optional, if required)
If the build team is not the team that will be providing
steady state support, the IDs used to perform the build
activities must be removed from the system.
In addition, the Shared IDs ownership must be updated to
reflect the steady state support team.
 Invoke Global IAM Process/Global IAM Primary
Controls Delete User ID or Access Procedure for the
deletion of IDs, as required.
 Invoke Global IAM Process/Global IAM Primary
Controls Modify User ID or Access Procedure to
update ownership of Shared IDs, as required.
16.0 Account Authorized 12 15.0 Request Update to Configuration Item

Requester
The objective of this step is to request an update to the
Configuration Item record in the Security Inventory in order
to reflect production status.
When the configuration item inventory record is updated to
a production status, appropriate compliance triggers should
also be set to support execution of steady state compliance
activities. Compliance trigger flags include those used for
Security Patch Management, Security Health Checking,
and ID Administration Secondary Controls activities.
Invoke Security Inventory Management to update the
configuration item in the Security Inventory.
17.0 Account Authorized 13 16.0 Build Closure

Requester
At this point, all build activities are complete and the
configuration item has been put into production.

4.5.1 Procedure Exit

Attributes Details
Outputs Completed Build Request

Closed Change Ticket (or change ticket update if the build is part of a larger build
activity, i.e. along with server or mainframe build, managed as a single change record.)
Completed CAR Request
Exit Criteria Completed Build Request

Closed Change Ticket (or change ticket update if the build is part of a larger build
activity, i.e. along with server or mainframe build, managed as a single change record.)
Completed CAR Request

5 Business Rules
5.1 Policies
Policy Name Description
Use of Cloning The build of a configuration item using a cloning method must follow the
During Configuration Configuration Item Build & Decommission service flows and execute all
Item Build required controls.
Special attention must be paid to the protection of customer data during use of
a cloning method when building a configuration item.
Scope Alignment The scope of configuration items that (1) must be recorded in the
Between Security geography/account appropriate Security Inventory system, and (2) must follow
Inventory and the Configuration Item Build & Decommission (CIB&D) Global Process is
Configuration Item EXACTLY THE SAME.
Build &
Decommission
Global Processes
Software Licensing Appropriate Licenses Required for all Software Installed During Build
During Build
5.2 Control Points

CP ID CP Name Description Control Type
and Category
CP- Initial Compliance Risk: Configuration Item not built as per the Compliance,
MD-1 Validation Technical specifications agreed with the customer Preventative
Description: An Initial Configuration Validation must
be performed and a compliant output obtained
confirming the configuration item has been
hardened as per the technical specifications.
(CAR-A Question #102)
CP- Code Currency Risk: Configuration Item not at the required account Compliance,
MD-2 baseline for currency Preventative
Description: Configuration Item must be brought to
required account baseline for patches and/or
firmware before being entered into production.
CP- ID Management Risk: Unauthorized users accessing the Compliance,
MD-3 configuration item in Production Preventative
Description: ID’s must be created on configuration
item only after receiving appropriate authorization.
(CAR-A Question #195/196)
CP- Inventory Risk: Configuration Item will not be managed in Compliance,

CP ID CP Name Description Control Type

and Category
MD-4 Registration steady state. Preventative
Description: The configuration item must be
registered in the logical inventory tool.
CP- Shared IDs Risk: Access to the system without individual Compliance,
MD-7 accountability. Preventative
Description: All Shared IDs must be registered in
the authorized Shared ID inventory and password
management tool
CP- Default Passwords Risk: Unauthorized access to the system using well- Compliance,
MD-8 known/default credentials Preventative
Description: All default passwords for Administrator
and system installed IDs must be changed
CP- CAR Request Risk: Artifacts demonstrating compliance with IBM Compliance,
MD-9 Record and client requirements have not been retained. Preventative
Description: A record that can be associated with
this build or decommission must be created in the
Configuration Item Artifact Repository.
5.3 Key Metrics

Metric Name Description
None

6 Related Assets
6.1 Related Processes or Service Flows
Process Name Relationship with this procedure
Configuration Item Build & Configuration Item Build & Decommission Service Flows
Decommission Service Flows trigger use of this procedure in support of build activities
6.2 Referenced Procedures

Document Name Relationship with this procedure
Configuration Item Called during build to capture evidence that controls are met
Artifact Repository
(CAR) Request
Procedure
6.3 Referenced Supporting Documents and Work

Instructions
Document Name Relationship with this procedure
None

7 Appendix
7.1 Screenshots
7.2 Other Details
7.3 Glossary
Term Definition
Build Build is defined as the installation and configuration of a new configuration item
into a production environment.
CSD The documentation that is created for each customer as a result of the Security
Policy Management activity is referred to as Customer Security Document (CSD)
Database Databases refers to the datafiles / tables / schemas used by customer. CAR
checklist should be used to add/modify configuration items within inventory.
Database Database Instance refers to the software component and the in memory processes
Instance use to run a database
Decommission The removal of a configuration item from production and/or IBM managed services
responsibility.
GSD331 Security Controls for Strategic Outsourcing Customers
ITCS104 Information Technology Security Standards. IBM internal Security standards and
guidelines that provides end-to-end security for applications and information
across multiple hardware and software platforms and networks.
ISEC Security Controls for Strategic Outsourcing Customers (Replaces GSD331 for new
customers)
Middleware Middleware refers to Middleware product software beyond what is normally
available within OS. This software used to service customer applications. This
does not include IBM support products such as Tivoli.
End of Document

IBM Replication

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Replication

Uploaded by

Copyright:

Available Formats

IBM Global Technology Services

Document Owner: Maurizio Biffa

Author: Barb Neale

Revision Date: 30 June 2017

Effective Date: 01 November 2017

© IBM Corporation, 2017 Page 2 of 20

1.0 Barb Neale Initial Release

1.2 Document Approvers

Configuration Item Build & Decommission Maurizio Biffa

1.3 Document Review Plans

1.4 How to Find the Latest Revision of this Document

1.5 Document Distribution and Notification

© IBM Corporation, 2017 Page 3 of 20

© IBM Corporation, 2017 Page 4 of 20

3.1 Environment and Audience.

Environment This procedure is applicable to any GTS Infrastructure Services Delivery

© IBM Corporation, 2017 Page 5 of 20

2. Supporting Account Information

 Customer Security Policy

Task(s) Perform a build of a Middleware or Database Product

Role(s) Account Authorized Requester:

◦ Submission of Build Request

◦ Engages Support Teams to Prepare for Steady State

◦ Acts on behalf of Account Team throughout the Procedure

© IBM Corporation, 2017 Page 6 of 20

 Creation of new Technical Specifications and Customer Security Policy

 Documented Risks, including Customer Acceptance

Skills Not Applicable

Complexity Not Applicable

© IBM Corporation, 2017 Page 7 of 20

Activities (Tasks, Steps) Events (Start, End, Connectors)

Notates the start of a workflow

Activity with Notates an activity with Notates the end of a workflow

Gateway (Decision Box)

Splits the flow and Swimlane

two or three paths

© IBM Corporation, 2017 Page 8 of 20

4.4 Build Procedure Workflow

1.0 6.0 14.0 16.0

5.0 7.0 8.0 13.0

© IBM Corporation, 2017 Page 9 of 20

4.5 Build Procedure Narrative

1.0 Account Authorized 1 Submit Build Request

2.0 Middleware/Database 2 1.0 Perform Pre-Build Review

If any of the situations above exist, an Account Security

© IBM Corporation, 2017 Page 10 of 20

the Middleware/Database Administrator must determine if

The following pre-requisites should be considered:

 OS patched to necessary level

 Storage – available and correct type

 Required Backup & Restore agents installed

 Middleware/Database Administrator has required

3.0 Middleware/Database 3 2.0 Engage Account Security Focal (optional, if required)

4.0 Account Security 4 3.0 Handle Security Policy Pre-Build Requirements

The Account Security Focal performs the following steps,

5.0 Middleware/Database 3 2.0 Submit Request for Pre-Requisites to Account

If changes are required to the existing system (e.g.

6.0 Account Authorized 4 5.0 Manage Completion of Pre-Requisite Changes

© IBM Corporation, 2017 Page 11 of 20

submitted via normal Change Management process prior to

7.0 Middleware/Database 5 3.0, Install Software & Perform Middleware/Database

8.0 Middleware/Database 5 3.0, Request Registration in IBM Management Systems

 Invoke Security Inventory Management to request